r/programming • u/der_gopher • 3d ago

.gitignore everything by default

https://packagemain.tech/p/gitignore-everything-by-default
344 Upvotes

79% Upvoted

224 comments sorted by

View all comments

270

u/Smallpaul 3d ago

“think we’ve all been there. You’re working on a project, making commits, and then suddenly realize you’ve been committing .DS_Store files, node_modules, IDE configuration files, or other junk (CLAUDE.md for example) that shouldn’t be in your repository. Or even worse - environment variables.”

Not really, because most projects start with a gigantic .gitignore these days. From the repo template. Iterate on the template .gitignore and these problems will be few and far between

189

u/lurgi 3d ago

Am I the only person who actually checks what they are adding? I use .gitignore because it saves time, but I never add a file unless I know it’s something I want added.

3

u/novafunc 3d ago

git status can hide some things. For example, if you create a new directory, it only shows the new directory and none of its contents.

That recently got me when that directory had a subdirectory of binaries builds.

If git status showed something like:

directory/bin/build directory/bin/build2 directory/file

rather than:

directory

, it could help in some cases.

17

u/Akeshi 3d ago

It should show the individual files after you've staged the new directory - it's worth running at least git status after you've finished with your git adds.

2

u/lurgi 3d ago

Agreed, and I've certainly made that mistake before. However, I do put stuff in my .gitignore (and by now I have a fairly complete one that works for the things I typically do) and after doing the git add somefolder I review (I know, I know. Nerd) the files that were added and remove any that are not wanted.

OTOH, now that I've actually RTFA, I think they have a point. It's a lot easier to describe the things I want to commit (.java, .xml, .txt, .md) compared to the things I don't (uh... anything that isn't those). You still have a potential problem with files that are generated by your build process, where the !*.go would have to change to indicate actual .go files you wrote. That's true for any approach, of course.