this post was submitted on 15 Sep 2025
25 points (93.1% liked)
Linux
9427 readers
586 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It isn't part of the project/code.
How is it not part of the project?
It just isn't. It has nothing to do neither with code nor with compiling. The same tier of "partness" as /etc/fstab or something.
So everyone who contributes to the project should make their own gitignore on every development machine they use to prevent committing build files, secrets ect?
I don't understand why you say it has nothing to do with the code when it literally has nothing to do with anything BUT the code.
What is the downside you see to committing the gitignore?
You commit with add -A? Well, ok.
Usually
git add .It's much faster, easier and less error prone to go with the blacklist approach of the gitignore file IMO.
How do you ensure your teammates don't start committing their own IDE settings or committing "secrets.json" files or helper scripts or log files?
You never want build artifacts to be committed. You don't want to have everyone working on your project to need to setup their own gitignore for every project. So it makes sense to have a common commited gitignore for files the project produces that should never be tracked by git.
I dislike when people put in editor files in the gitignore though. People should setup global ones for their local tooling.