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.
I only realized very recently that being able to specify .gitignore files in any part of a repo can be combined with wildcards to just put `.gitignore` with `*` in a arbitrary directories to make them get ignored without needing to modify any wider configuration.
You can also use something like alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it to run as a pre-commit hook or in CI.
I'm not convinced people acting on muscle memory would remember to unignore the files either. They're going to lose work or have giant "oops, I forgot to commit these files" commits.
It depends. I've lost hours of work after wiping and recreating a repo that had accidentally gitignored a file I was working on, and I didn't notice until too late.
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
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.
I use "git add ." (or rather -A), but I will always do a "git status" first to make sure I'm not doing something silly. Of course you still have to be careful about subdirectories, which is why I usually also do a "git status" again before committing.
git add . is nondestructive and reversible. I tend to do git add . and then run git status.
I’m far more interested in confirming my mental model of what I am about to commit if I git commit right now than my mental model of what will be added if I git add right now.
If I didn’t already have that muscle memory I might try to switch to git add -v . which would tell me what files it added. I’d argue that a sane git would just output git status after a git add operation.
But also a sane git would have a more logical command than git rm —cached to unstage a file. Like git unstage perhaps.
I'm with you, though I do it differently. I have a git-status plug-in in my editor that shows me what directories -> files have been changed, and then which lines when I open them. Scanning the sidebar is the same as running "git status" first, but I prefer the visual representation.
another `git status` then `git add .` folk here, it's a quick sanity check and then quicker and frankly it's just the habit I got into when I first started using git.
I've never managed to get on with any UI for basic git tasks, they always end up been slower.
I’ve been using magit lately, but I only do ‘git add .’ when it’s a very simple change. Especially in complex projects, I do some changes to isolate code or fix other issues in passing. So I stage by lines and hunks to isolate specific changes and commit them one by one. But magit is the vim of version control, so no speed issue there.
In a previous company I worked for my Tech Lead usually do git add -p <file> to be extra cautious with the modifications and do a good self review after when open the pull request
I try to structure my work in such a way that "git add ." I stashed or committed outstanding changes before starting on this feature, and I did exactly enough work for one commit since then. And the state of the project right now is what I've built and tested, so it's a good candidate to go into version control.
Increasingly with agents I'm likely working on multiple features in parallel (I haven't adopted git worktrees but I probably should). Even then I try to lay out code so concurrent changes touch disjoint parts of the codebase, so I can do "git add Widgets/FooWidget/" and the ten files modified under there will be the right things to commit.
Maybe 30% of the time I find I have done work that belongs in multiple commits and I need to break it up. Even then I often end up doing "git add -p ." to interactively pick the parts I want to add.
Lazygit[0] is ideal for quickly selecting files or lines you want to include in your commit. There are probably countless others. And `--patch` is also not that hard.
> 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?
IME people are usually shoving their personal preferences in CLAUDE.md, sometimes automatically as the agent updates the file with that developer's pet peeves.
- Right now at $WORK, CLAUDE.md has a line saying to put one-off scripts in some gitignored place. That's fine if they're not worth checking in (IMO, you should build the tooling which would have made the script easy and check that in, but whatever), but that AI rule doesn't really keep them from being checked in -- developers manually review every line of code and decide what to check in -- that's just somebody deciding they'd rather not have to think so hard when running git add. Which is fine, but it directly conflicts with my preference for all AI-generated files to be plainly visible as a diff or with git status or something. They have a different diffing strategy, which is also fine, but that's just a dev's personal preference encoded in a whole-team doc.
- Or, I have a prompt I use to encourage higher quality code before I have to manually inspect it. It basically says "delete $200 and 1hr." For somewhat obvious reasons, I don't run it on every piece of code the AI shits out. I make it available in the project for people who want to use it, but I don't even want it in my CLAUDE.md, much less the team's.
- Similarly with whether to use git for checkpointing. I prefer to check the AIs output at each step. A colleague prefers to have it save its progress using git in 30+ commits on a side branch and then check them all at once. One of those workflows was in CLAUDE.md and absolutely is not anymore -- it's quite appropriate for a single developer's AI settings, but not for the team as a whole.
Those settings files are a lot closer to .vscode directories or other dev-specific editor configuration. Project-specific information should be exposed differently.
Well CLAUDE.local.md exists specially for personal preferences. Include line to CLAUDE.md that "never edit CLAUDE.md. Write user preferences to CLAUDE.local.md".
CLAUDE.local.md is the one that should be in .gitignore.
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.
I have a shell alias to create a folder containing a `.gitignore` with just `*`, so I don't depend on my project never using a directory of a specific name.
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.
I use alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it run as a pre-commit hook or in CI.
- or you could stop scratching your head so hard and actually use the gitignore templates for every programming language officially recommended by github itself
I use alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it run as a pre-commit hook or in CI.
These do not include os generated files like his first example, .DS_Store. I do use the templates, but I have a gist that I add to every project of os generated files that may work themselves in.
In my experience these templates don't cover enough and are always faulty. Not only that, most real-world projects use many different programming languages and markup languages.
I think the article starts out correct, but as soon as it recommends letting through `*.go` it becomes mistaken.
I'd say the correct approach is to include all your top level files (i.e. CMakeLists.txt, .gitignore, etc.) but also your top-level *directories*, i.e. `/renderer`, `/UI`, `/tools`, whatever.
Then, crucially, your build system must also prohibit in-source builds and require a dedicated build directory.
This way, it's presumed that everything in your source tree is pristine and correct, and can host a variety of file types depending on your needs (realistically, source trees can contain lots of things; data, json, images, text, etc.) while you also shouldn't have to worry about polluting it accidentally.
Alternative: create a .ignore folder for stuff that doesn't belong to repo at all, like your personal notes. Of course, .env shouldn't be there, because it's expected by your code, put it in .gitignore as usual. And stuff like .DS_Store should be in your global gitignore via core.excludesfile config.
There, problem solved. This covers all cases I think.
I've done something like this to understand how a unity project would interact with git + LFS as a novice to the ecosystem.
I'd incrementally add files until the project would load successfully after a fresh clone. Handling of subsequent concerns like lightmap data and external services became a lot easier having had the experience built up from zero.
It interactively shows you each change that would be added and lets you decide whether it should be staged or not. Down to the hunk level, so you can partially stage a file if you so choose.
I use alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it run as a pre-commit hook or in CI.
That fixes the problem of every project enumerating the settings files for every editor.
Then, as others have said, you should commit only the files you intend to commit; and ignore the files that you don’t intend to commit. This shouldn’t be difficult if you’re reviewing what you’re committing anyways.
Listing new files is easy with git status, at which point you can decide to ignore them. If everything is ignored, how do you know what files are new in order to know to un-ignore them?
I do use this, but when I'm collaborating with others, especially a lot of people, I still duplicate it across projects. It pays to be defensive and you can't always get everyone on board with this strategy. Being defensive within your repository prevents issues before they happen.
Yeah, I don't see myself using this for Git (where it's very easy to see what you're adding, but not obvious and high-cost if you're missing something), but it's my standard approach for Docker images (where it's easy to tell that something is missing, and low-cost to fix it).
Not particularly well-considered opinion I’ve mulled over for a few years: Git on macOS should ignore .DS_Store and ._* by default. Would this cause any problems?
It's a neat approach for the current problem of untracked dotfile accumulation.
The real problem is that the entire reason to use git at this point is because of the conventions established around it. There are better VCSes and methods now, but they "break" the conventions of git (which honestly sucks, but it is what it is).
If people want to apply this mechanism, it shall be not much of a hassle for writers of most (modern) programming languages, as they mostly have some `src/` directory (maybe also some `tests/`) that contains all source codes for a quick `git add`.
Just use git add -p and review your code as you place it into staged-for-commit. Your colleagues will thank you for proofreading the slop before pushing it and opening a PR. Only add files after you’ve read them one-by-one as well. git add . is lazy and shows a lack of diligence.
…is what I would say if I had no filter. But it does make sense what I see in PRs sometimes - have you proofread any of this before pushing?
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.
For many years I've have a git-ignored ".not-committed" folder in all of my repos for throwing extra anything into. It's been a huge life saver!
You can just add it in a user-level gitignore instead of ignoring it in every repo. See: ~/.config/git/ignore
I only realized very recently that being able to specify .gitignore files in any part of a repo can be combined with wildcards to just put `.gitignore` with `*` in a arbitrary directories to make them get ignored without needing to modify any wider configuration.
> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.
You can also use something like alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it to run as a pre-commit hook or in CI.
(disclaimer - this is my own tool)
[0] https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
>This seems like bad advice. I've very rarely committed extra files by accident, [...]
You clearly haven't seen the people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time.
I'm not convinced people acting on muscle memory would remember to unignore the files either. They're going to lose work or have giant "oops, I forgot to commit these files" commits.
Now walk through exactly what would happen when those lazy people follow this approach…
You see the issue right?
Recovery from forgetting to add something is _much_ easier than recovery from adding some weird configuration file with plaintext private keys in it.
It depends. I've lost hours of work after wiping and recreating a repo that had accidentally gitignored a file I was working on, and I didn't notice until too late.
I usually have *secret in .gitignore and append .secret to any files with secrets.
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
Wow, thanks so much for . gitignore_global.
Finally can have Emacs files ignored automatically in all projects. <3
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.
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.
I use "git add ." (or rather -A), but I will always do a "git status" first to make sure I'm not doing something silly. Of course you still have to be careful about subdirectories, which is why I usually also do a "git status" again before committing.
git add . is nondestructive and reversible. I tend to do git add . and then run git status.
I’m far more interested in confirming my mental model of what I am about to commit if I git commit right now than my mental model of what will be added if I git add right now.
If I didn’t already have that muscle memory I might try to switch to git add -v . which would tell me what files it added. I’d argue that a sane git would just output git status after a git add operation.
But also a sane git would have a more logical command than git rm —cached to unstage a file. Like git unstage perhaps.
I'm with you, though I do it differently. I have a git-status plug-in in my editor that shows me what directories -> files have been changed, and then which lines when I open them. Scanning the sidebar is the same as running "git status" first, but I prefer the visual representation.
another `git status` then `git add .` folk here, it's a quick sanity check and then quicker and frankly it's just the habit I got into when I first started using git.
I've never managed to get on with any UI for basic git tasks, they always end up been slower.
I’ve been using magit lately, but I only do ‘git add .’ when it’s a very simple change. Especially in complex projects, I do some changes to isolate code or fix other issues in passing. So I stage by lines and hunks to isolate specific changes and commit them one by one. But magit is the vim of version control, so no speed issue there.
In a previous company I worked for my Tech Lead usually do git add -p <file> to be extra cautious with the modifications and do a good self review after when open the pull request
I try to structure my work in such a way that "git add ." I stashed or committed outstanding changes before starting on this feature, and I did exactly enough work for one commit since then. And the state of the project right now is what I've built and tested, so it's a good candidate to go into version control.
Increasingly with agents I'm likely working on multiple features in parallel (I haven't adopted git worktrees but I probably should). Even then I try to lay out code so concurrent changes touch disjoint parts of the codebase, so I can do "git add Widgets/FooWidget/" and the ten files modified under there will be the right things to commit.
Maybe 30% of the time I find I have done work that belongs in multiple commits and I need to break it up. Even then I often end up doing "git add -p ." to interactively pick the parts I want to add.
Lazygit[0] is ideal for quickly selecting files or lines you want to include in your commit. There are probably countless others. And `--patch` is also not that hard.
[0] https://github.com/jesseduffield/lazygit
> 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?
IME people are usually shoving their personal preferences in CLAUDE.md, sometimes automatically as the agent updates the file with that developer's pet peeves.
- Right now at $WORK, CLAUDE.md has a line saying to put one-off scripts in some gitignored place. That's fine if they're not worth checking in (IMO, you should build the tooling which would have made the script easy and check that in, but whatever), but that AI rule doesn't really keep them from being checked in -- developers manually review every line of code and decide what to check in -- that's just somebody deciding they'd rather not have to think so hard when running git add. Which is fine, but it directly conflicts with my preference for all AI-generated files to be plainly visible as a diff or with git status or something. They have a different diffing strategy, which is also fine, but that's just a dev's personal preference encoded in a whole-team doc.
- Or, I have a prompt I use to encourage higher quality code before I have to manually inspect it. It basically says "delete $200 and 1hr." For somewhat obvious reasons, I don't run it on every piece of code the AI shits out. I make it available in the project for people who want to use it, but I don't even want it in my CLAUDE.md, much less the team's.
- Similarly with whether to use git for checkpointing. I prefer to check the AIs output at each step. A colleague prefers to have it save its progress using git in 30+ commits on a side branch and then check them all at once. One of those workflows was in CLAUDE.md and absolutely is not anymore -- it's quite appropriate for a single developer's AI settings, but not for the team as a whole.
Those settings files are a lot closer to .vscode directories or other dev-specific editor configuration. Project-specific information should be exposed differently.
Well CLAUDE.local.md exists specially for personal preferences. Include line to CLAUDE.md that "never edit CLAUDE.md. Write user preferences to CLAUDE.local.md".
CLAUDE.local.md is the one that should be in .gitignore.
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
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.
Couldn't you put !.gitignore et al in your global config file?
I normally go with `.*/` -- I find that hidden files are much more likely than hidden directories to be useful.
I have `playground/` in my ignore config, that way I can just create a playground directory for any project and do stuff in there
I have a shell alias to create a folder containing a `.gitignore` with just `*`, so I don't depend on my project never using a directory of a specific name.
I do the same
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.
I use alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it run as a pre-commit hook or in CI.
(disclaimer - this is my own tool)
[0] https://github.com/asamarts/alint
[1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
- or you could stop scratching your head so hard and actually use the gitignore templates for every programming language officially recommended by github itself
- https://github.com/github/gitignore
- funny how I did not see a single comment talk about this
Because it's insufficient?
https://github.com/github/gitignore/blob/main/Rust.gitignore for example still falls victim to basically all of the issues specifically called out.
I use alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it run as a pre-commit hook or in CI.
(disclaimer - this is my own tool)
[0] https://github.com/asamarts/alint
[1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
These do not include os generated files like his first example, .DS_Store. I do use the templates, but I have a gist that I add to every project of os generated files that may work themselves in.
Just have a global, personal gitignore in your home folder to cover them
I like https://www.toptal.com/developers/gitignore because I can mix programming language files with OS ones
In my experience these templates don't cover enough and are always faulty. Not only that, most real-world projects use many different programming languages and markup languages.
I think the article starts out correct, but as soon as it recommends letting through `*.go` it becomes mistaken.
I'd say the correct approach is to include all your top level files (i.e. CMakeLists.txt, .gitignore, etc.) but also your top-level *directories*, i.e. `/renderer`, `/UI`, `/tools`, whatever.
Then, crucially, your build system must also prohibit in-source builds and require a dedicated build directory.
This way, it's presumed that everything in your source tree is pristine and correct, and can host a variety of file types depending on your needs (realistically, source trees can contain lots of things; data, json, images, text, etc.) while you also shouldn't have to worry about polluting it accidentally.
Alternative: create a .ignore folder for stuff that doesn't belong to repo at all, like your personal notes. Of course, .env shouldn't be there, because it's expected by your code, put it in .gitignore as usual. And stuff like .DS_Store should be in your global gitignore via core.excludesfile config.
There, problem solved. This covers all cases I think.
I've done something like this to understand how a unity project would interact with git + LFS as a novice to the ecosystem.
I'd incrementally add files until the project would load successfully after a fresh clone. Handling of subsequent concerns like lightmap data and external services became a lot easier having had the experience built up from zero.
`git add -p` is your friend to avoid adding unintended files/changes.
What does that do, add already tracked files only?
It interactively shows you each change that would be added and lets you decide whether it should be staged or not. Down to the hunk level, so you can partially stage a file if you so choose.
I use alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it run as a pre-commit hook or in CI.
(disclaimer - this is my own tool)
[0] https://github.com/asamarts/alint
[1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
Use ~/.config/git/ignore to ignore files in all repositories
You should have editor specific and platform specific files in your global gitignore.
https://codeberg.org/ziglang/zig/src/branch/master/.gitignor...
That fixes the problem of every project enumerating the settings files for every editor.
Then, as others have said, you should commit only the files you intend to commit; and ignore the files that you don’t intend to commit. This shouldn’t be difficult if you’re reviewing what you’re committing anyways.
Listing new files is easy with git status, at which point you can decide to ignore them. If everything is ignored, how do you know what files are new in order to know to un-ignore them?
I do use this, but when I'm collaborating with others, especially a lot of people, I still duplicate it across projects. It pays to be defensive and you can't always get everyone on board with this strategy. Being defensive within your repository prevents issues before they happen.
This approach is actually ideal for Docker ignore files to reduce bloat of your Docker images.
Yeah, I don't see myself using this for Git (where it's very easy to see what you're adding, but not obvious and high-cost if you're missing something), but it's my standard approach for Docker images (where it's easy to tell that something is missing, and low-cost to fix it).
Use the -u flag instead of -a. Doesn't add new files, just existing ones.
Not particularly well-considered opinion I’ve mulled over for a few years: Git on macOS should ignore .DS_Store and ._* by default. Would this cause any problems?
It's a neat approach for the current problem of untracked dotfile accumulation.
The real problem is that the entire reason to use git at this point is because of the conventions established around it. There are better VCSes and methods now, but they "break" the conventions of git (which honestly sucks, but it is what it is).
Put gates in place to block all .freeadvertising folders except for the ones that the project relies on.
If people want to apply this mechanism, it shall be not much of a hassle for writers of most (modern) programming languages, as they mostly have some `src/` directory (maybe also some `tests/`) that contains all source codes for a quick `git add`.
For Golang users, I dunno...
Just use git add -p and review your code as you place it into staged-for-commit. Your colleagues will thank you for proofreading the slop before pushing it and opening a PR. Only add files after you’ve read them one-by-one as well. git add . is lazy and shows a lack of diligence.
…is what I would say if I had no filter. But it does make sense what I see in PRs sometimes - have you proofread any of this before pushing?
I liked .gitcare This deserves think on it
i do the same for Content Security Policy: `default-src 'none'` by default, then add what i need when i need it.
People still aren't committing CLAUDE.md?
I'm so sick of these articles telling me what to do with meaningless subjective justifications
Subscribe, like and comment if you want to see more!