Stop committing junk: ignore everything in Git by default
.gitignore Everything by Default
Tired of accidentally committing .DS_Store, node_modules, or stray AI-generated files like CLAUDE.md? Flip your .gitignore strategy: ignore everything by default, then whitelist only what matters. With a few lines—`*` followed by `!` exceptions—you keep your repo clean and history tidy. It's not for every project, but it's a refreshing alternative to the bloated 200-line .gitignore files seen in big repos like typescript-go.
What if we flipped this approach entirely? Instead of allowing everything by default and selectively ignoring files, what if we ignored everything by default and only allowed specific files?
- rcfox
This seems like bad advice. I've very rarely committed extra files by accident, but I would 100% forget to unignore files I meant to commit.
If you're doing an initial setup step to gitignore everything, why not just do an initial setup step to gitignore the usual files? Make a template that you copy into all of your repos.
- Brajeshwar
It is weird that quite a few developers comes up with advices where they seem to come from a world where they work alone, have not work with enough people, or with enough projects.
In this case, a `.gitignore_global` takes care of the usual suspects that he mentioned `.DS_Store files, IDE config, compressed files, etc.`. Even if something goes wrong, it is usually caught during the initial scaffold before critical files goes in.
If one is working with new, young, rookie developers, give them the typical lesson on the global gitignore, local, config, and to have dotfiles, etc. Give yours for inspiration or something to start with.
Edit: I know that mine is not the best of the dotfiles on the internet but this has helped me switch multiple devices, multiple identities (work, projects, personal, etc) easily. I recently cleaned it up and added automation, test, etc with Claude Code. https://github.com/brajeshwar/dot
- isityettime
How about just learning to use `git add` correctly? Are you so committed to just slamming `git add -A` all the time? It's not hard to have uncommitted files sitting in your working tree without messing with .gitignore at all.
- caseyw
I don’t ignore by default, but only stage the items I explicitly want.
I can’t tell you how many times I’ve been pairing with someone when they just say “git add .”, I’m always confused by that choice.
I get it, but I’ve seen more problems arise from adding all than being consistently selective. To each their own.
- flexagoon
> other junk (CLAUDE.md for example) that shouldn’t be in your repository
How is CLAUDE.md/AGENTS.md "junk that shouldn't be in your repository"? If you're using agents for a project and have some project-specific rules for them, why would you want other people using agents in your repository to not have access to those rules and produce worse code?
- yipinwong
Very security engineer minded approach.
I block every port for VPS, then open one by one.
Same approach here with files.
The only downside I see here is, knowing which one to allow. For ports, it's easy, but files can have many different extensions.
Apps/CLIs, etc create files with extensions you never encountered before, which can cause issues.
Other than that, I like the apporach
- matthewmc3
I'm not convinced about ignoring everything, but one of the best changes I ever made to my git workflow was ignoring all dotfiles by default by adding `.*` to ~/.config/git/ignore.
My projects do now have to have a boiler plate of unignoring the common ones (!.gitignore, !.gitattributes, !.github, !.editorconfig, etc), but then I'm free at any point to throw .foo.lang files, or .tmp/.cache dirs, or Claude helpers like .code_analysis.md, or .todos.txt, or whatever in my project without managing the fallout of forgetting to manage the .gitignore. I'm surprised more people don't go this route.
- ryanbrunner
The problem with this approach (that their first example already demonstrates), is that you'll almost immediately start with a "this type of file is OK" solution, and whether something should go in git doesn't really have a super strong correlation with file type.
It hobbles `git status` and essentially forces you to keep track of what you've changed yourself (since ignored files won't show up there), and it can instill a false sense of security that `git add .` is safe when it might not be.