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.

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

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.

> 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?

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.

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

People need to learn to use .git/info/exclude WAYYY more!

You use Cursor which creates .cursor? Cool! Put it in .git/info/exclude. No need to pollute the project .gitignore with that. .gitignore is for artifacts that arise from the natural building and testing of the software, as well as any scripts in the repo.

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.

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.

- 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

`git add -p` is your friend to avoid adding unintended files/changes.

I think the issue comes from the practice of always running "git add ." from the cli. As a git gui user [1], I see exactly what files I stage, so this is a non-issue.

Also, the .gitignore file can document what files you are supposed to have in your project and where they come from

[1]: I'm currently a happy Fork user after having tried Sublime Merge, Git Kraken and lazygit.

New files are unstaged by default in git. If you’re doing git add -A, that’s on you. There’s nothing wrong with the tool.

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...

This approach is actually ideal for Docker ignore files to reduce bloat of your Docker images.

This is a great technique if your workplace is fussy about what's allowed on GitHub. We have used it for many years.

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.

I set something similar up in a project and it's been surprisingly good. In my case I ignored all top-level except for specific files and dirs such as Dockerfile, src or tests. Juniors rarely (never?) need to add new files or dirs at top-level, and seniors tend to (always?) realise they need to explicitly stage that new dir/file. Other prejects that have the usual exhaustive .gitignore generating from mixing and matching multiple templates ended up with random .claude or .zed once people started using new tools that weren't around when the initial gitignore was created

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.

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?

In 2016 I joined C project initially created in 1999. This project had ~7k lines in gitignore and I learned this only because one of my commit created 2h of email exchange why my code does not compile. Turns out filename was forbidden by one rule.

This one file was more sophisticated than any other file in the project.

It contained "good practices", editors/IDE files of applications dead for more than 10y, personal. /tmp directories in various names, files versioning using suffixes and comments for sections v of rules starting about in half of the file.

This project learned my to keep your own shit in local global gitignore not in project.

  strict_ignore() {
    [[ -n "$1" ]] || exit 1
    local repo="${1%/}/"
    local ignore
    ignore=$(find "$repo" -path "$repo".git -prune -o -print \
               | sed "s|$repo||g; /^$/d" \
               | awk '{print "!"$0}' \
               | sort)
    printf "*\n%s\n" "$ignore"
  }

Didn't read the article, but based on the title, I think it's a spelling mistake...

The author likely meant .dockerignore everything, that is the way to go.

Just use gitignore.io , enter your keywords and get all necessary entries to ignore. I’ve used it for years. Its a blessing.

Create a /src and a /wrk folder in the root of your project. Put all the code in src, all the stupid files in wrk, like todo.txt, code snippets, downloaded media for design, references, notes, etc then just add DS_store and wrk to gitignore

The habit of putting everything in /wrk folder will grow on you. Sometimes wrk folder is bigger than src

You use tooling or workflows that blindly do "git add" of everything for you under the hood, so of course you advocate .gitignoring everything. The unifying theme is, operate on everything and sort it out somehow.

I've worked on projects with years-old local repos full of untracked junk, yet never needed .gitignore and never added and published anything by accident.

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 been liking keeping sensitive config outside of the repo directory altogether, and instead putting it into a dotted folder in my home directory, so something like

~/.project-name/local.env

And then referring to that location in the repo, say from a docker compose file.

Works well so far

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...

Use the -u flag instead of -a. Doesn't add new files, just existing ones.

Who would you commit files like DS_ or node_modules by error? You have to add _and then commit_ without looking at the index O_o

I can hardly remember to commit my untracked files. A better solution here would be to somehow disallow `git add .`

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?

I have a ignore file in my home directory that takes care of most of those problems :)

I do this with docker. Insane that the default is to recursively ship all of PWD.

Use ~/.config/git/ignore to ignore files in all repositories

I use this strategy on my home directory for tracking dotfiles.

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?

Better would be to ban both git add . And git commit -a

I use this trick with Dockerfiles, as you typically don't want to pull everything in the context.

i do the same for Content Security Policy: `default-src 'none'` by default, then add what i need when i need it.

I liked .gitcare This deserves think on it

Seems like they want a .gitallow

Git already works like this. It won't commit anything unless you explicitly stage it first.

"Works on my machine" accelerationism

i am not sure why this has been upvoted this is such a bad advice...

I'm so sick of these articles telling me what to do with meaningless subjective justifications

People still aren't committing CLAUDE.md?

This is going to be annoying to live with. It makes `git status` unable to remind you that you forgot to add a file you created. Those files will hang around when you change branches. If you have CI you'll see that it is failing and if you are lucky you'll immediately realize without spending 10 minutes on debugging why, and then have to go backtrack, change the branch back, add the file (without the benefit of copy pasting the path from git status) etc etc.

Just look at git status before you commit :eyeroll:.