7 ms·

.gitignore Everything by Default

186 points by der_gopher 12d ago

msalihb 12d ago
I liked .gitcare This deserves think on it
- der_gopher 12d ago
  or .gitallow
mitianovikov 6d ago
[dead]
not-so-darkstar 12d ago
Use ~/.config/git/ignore to ignore files in all repositories
matthewmc3 12d ago
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.
- der_gopher 12d ago
  I do the same
- GranPC 12d ago
  Couldn't you put !.gitignore et al in your global config file?
- flexagoon 12d ago
  I have `playground/` in my ignore config, that way I can just create a playground directory for any project and do stuff in there
  - zzril 12d ago
    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.
- hansvm 12d ago
  I normally go with `.*/` -- I find that hidden files are much more likely than hidden directories to be useful.
caseyw 12d ago
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.
- etbebl 12d ago
  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.
  - noir_lord 12d ago
    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.
    - skydhash 12d ago
      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.
  - eszed 12d ago
    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.
  - jameshart 12d ago
    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.
Lindby 12d ago
`git add -p` is your friend to avoid adding unintended files/changes.
- eterm 12d ago
  What does that do, add already tracked files only?
  - jdpage 12d ago
    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.
    - eterm 12d ago
      Oh, that's neat. The -p presumably stands for pInteractive with a silent p :)
      - airstrike 12d ago
        LOL it might stand for "prompt before"
      - oarmstrong 12d ago
        Ha! It’s actually patch (as in select parts of the patch) though I remember it as partial.
      - dxdm 12d ago
        There's -i for interactive, lets you add, patch and reset (unstage).
    - zelphirkalt 12d ago
      Ah, that's what magit does by default.
  - matijs 12d ago
flexagoon 12d ago
> 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?
- deleted 12d ago
  [deleted]
- hansvm 12d ago
  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.
  - 12d ago
outloudvi 12d ago
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...
- deleted 12d ago
  [deleted]
- zelphirkalt 12d ago
  For a non-golang-user, what have they done to the language in that regard?
rcfox 12d ago
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.
- gruez 12d ago
  >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.
  - efilife 12d ago
    I do this. What's wrong with this approach and how should it be done correctly?
    - JimDabell 11d ago
      Pay attention to what you are staging. Generally this means `git add -p` or similar. Pay attention to what you are committing. Generally this means looking at what you have staged before writing your commit log message. Pay attention to what is in your pull request. Generally this means looking at your commits / draft pull request before you ask for code review. If anybody other than you sees crap in your pull request that should obviously have been ignored, it means you have failed to pay attention to what you are doing three separate times.
      - efilife 11d ago
        I do all of these three. I guess there's nothing wrong in this approach after all. It just boils down to "not push shitty commits"
        JimDabell 11d ago
vehemenz 12d ago
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).
queezey 12d ago
This approach is actually ideal for Docker ignore files to reduce bloat of your Docker images.
- jdpage 12d ago
  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).
internet101010 12d ago
Put gates in place to block all .freeadvertising folders except for the ones that the project relies on.
monster_truck 12d ago
I'm so sick of these articles telling me what to do with meaningless subjective justifications
- taikahessu 12d ago
  Subscribe, like and comment if you want to see more!
ryanbrunner 12d ago
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.
- aleqs 12d ago
  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 https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths/ https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
MatthiasPortzel 12d ago
You should have editor specific and platform specific files in your global gitignore. https://codeberg.org/ziglang/zig/src/branch/master/.gitignore#L2 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?
- jmholla 12d ago
  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.
laruss5 12d ago
[flagged]
vivzkestrel 12d ago
- 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 https://github.com/github/gitignore - funny how I did not see a single comment talk about this
- piker 12d ago
  Because it's insufficient? https://github.com/github/gitignore/blob/main/Rust.gitignore https://github.com/github/gitignore/blob/main/Rust.gitignore for example still falls victim to basically all of the issues specifically called out.
  - aleqs 12d ago
    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 https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths/ https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
- zarlss43 12d ago
  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.
  - adammarples 12d ago
    Just have a global, personal gitignore in your home folder to cover them
  - bloomers 12d ago
    It's a good practice to ignore OS specific files in user level gitignore but I think that putting it (redundantly for some of us) in repo is a good practice. Some people don't maintain their own user ignores and might accidentally commit to shared repository. It's clearly fault of commiter and reviewer but let's just save ourselves stress and put those records in the .gitignore of the repo.
jedschmidt 12d ago
i do the same for Content Security Policy: `default-src 'none'` by default, then add what i need when i need it.
bob1029 12d ago
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.
datsci_est_2015 12d ago
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?
morkalork 12d ago
People still aren't committing CLAUDE.md?
Brajeshwar 12d ago
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 https://github.com/brajeshwar/dot
- DarmokTanagra 12d ago
  [dead]
- wafflemaker 12d ago
  Wow, thanks so much for . gitignore_global. Finally can have Emacs files ignored automatically in all projects. <3
  - xtajv 12d ago
    Emacs can be configured to dump its litter into specific directories instead of in-situ with the files being edited. Please do.
- Waterluvian 12d ago
  > 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. What is weird about it?
  - deleted 12d ago
    [deleted]
chrismorgan 12d ago
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?
aleqs 12d ago
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 https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths/ https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
yipinwong 12d ago
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
- der_gopher 12d ago
  I like the analogy with ports, I also do the same - ufw deny all :)
- JackSlateur 11d ago
  Port numbers are convention A "security engineer minded approach" would be: own what is executed on the box;
skrrtww 12d ago
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.
IAmLiterallyAB 12d ago
Use the -u flag instead of -a. Doesn't add new files, just existing ones.
zahrevsky 12d ago
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.
bizcalclab 12d ago
[flagged]
isityettime 12d ago
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.
getnormality 12d ago
This is a great technique if your workplace is fussy about what's allowed on GitHub. We have used it for many years.
temphaaa 12d ago
i am not sure why this has been upvoted this is such a bad advice...
mohamedkoubaa 12d ago
"Works on my machine" accelerationism
dxjxjdjsssb 12d ago
I use this strategy on my home directory for tracking dotfiles.
Boxxed 12d ago
I do this with docker. Insane that the default is to recursively ship all of PWD.
globular-toast 12d ago
Git already works like this. It won't commit anything unless you explicitly stage it first.
- der_gopher 12d ago
  Yes, but people miss often what is committed, especially if the change is big.
  - globular-toast 12d ago
    Eh? You explicitly have to add files to the stage before git will commit anything.
edukite 12d ago
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.
singpolyma3 12d ago
Better would be to ban both git add . And git commit -a
- matijs 12d ago
  Ban `git add .` for sure, but what’s so bad about `git commit -a`? It only adds/removes what was already under version control.
  - singpolyma3 12d ago
    Makes it easy to commit things you didn't expect without having reviewed them
    - matijs 11d ago
      Ah fair enough, I've got commit.verbose set to true for that.
quantivaia 12d ago
[flagged]
nevalainen 12d ago
I have a ignore file in my home directory that takes care of most of those problems :)
ltbarcly3 12d ago
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:.
agile-gift0262 12d ago
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
serbuvlad 12d ago
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.
- Alifatisk 11d ago
  Interesting!
michalc 12d ago
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
coneonthefloor 12d ago
Seems like they want a .gitallow
kazinator 12d ago
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.
mikenikles 12d ago
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.
Kuyawa 12d ago
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
anthovallee 12d ago
I use this trick with Dockerfiles, as you typically don't want to pull everything in the context.
orielhaim 12d ago
[dead]
b5n 12d ago
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" }
jxndnendn 12d ago
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
bastawhiz 12d ago
I can hardly remember to commit my untracked files. A better solution here would be to somehow disallow `git add .`
senorrib 12d ago
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.
vanyle 11d ago
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.
Alifatisk 11d ago
Just use gitignore.io , enter your keywords and get all necessary entries to ignore. I’ve used it for years. Its a blessing.
booster-rooster 10d ago
[flagged]

186 points by der_gopher 12d ago

msalihb 12d ago

I liked .gitcare This deserves think on it

der_gopher 12d ago
or .gitallow

mitianovikov 6d ago

[dead]

not-so-darkstar 12d ago

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

matthewmc3 12d ago

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.

der_gopher 12d ago
I do the same
GranPC 12d ago
Couldn't you put !.gitignore et al in your global config file?
flexagoon 12d ago
I have `playground/` in my ignore config, that way I can just create a playground directory for any project and do stuff in there
- zzril 12d ago
  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.
hansvm 12d ago
I normally go with `.*/` -- I find that hidden files are much more likely than hidden directories to be useful.

caseyw 12d ago

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.

etbebl 12d ago
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.
- noir_lord 12d ago
  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.
  - skydhash 12d ago
    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.
- eszed 12d ago
  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.
- jameshart 12d ago
  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.

Lindby 12d ago

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

eterm 12d ago
What does that do, add already tracked files only?
- jdpage 12d ago
  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.
  - eterm 12d ago
    Oh, that's neat. The -p presumably stands for pInteractive with a silent p :)
    - airstrike 12d ago
      LOL it might stand for "prompt before"
    - oarmstrong 12d ago
      Ha! It’s actually patch (as in select parts of the patch) though I remember it as partial.
    - dxdm 12d ago
      There's -i for interactive, lets you add, patch and reset (unstage).
  - zelphirkalt 12d ago
    Ah, that's what magit does by default.
- matijs 12d ago

flexagoon 12d ago

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

deleted 12d ago
[deleted]
hansvm 12d ago
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.
- 12d ago

outloudvi 12d ago

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

deleted 12d ago
[deleted]
zelphirkalt 12d ago
For a non-golang-user, what have they done to the language in that regard?

rcfox 12d ago

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.

gruez 12d ago
>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.
- efilife 12d ago
  I do this. What's wrong with this approach and how should it be done correctly?
  - JimDabell 11d ago
    Pay attention to what you are staging. Generally this means `git add -p` or similar. Pay attention to what you are committing. Generally this means looking at what you have staged before writing your commit log message. Pay attention to what is in your pull request. Generally this means looking at your commits / draft pull request before you ask for code review. If anybody other than you sees crap in your pull request that should obviously have been ignored, it means you have failed to pay attention to what you are doing three separate times.
    - efilife 11d ago
      I do all of these three. I guess there's nothing wrong in this approach after all. It just boils down to "not push shitty commits"
      - JimDabell 11d ago

vehemenz 12d ago

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

queezey 12d ago

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

jdpage 12d ago
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).

internet101010 12d ago

Put gates in place to block all .freeadvertising folders except for the ones that the project relies on.

monster_truck 12d ago

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

taikahessu 12d ago
Subscribe, like and comment if you want to see more!

ryanbrunner 12d ago

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.

aleqs 12d ago
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 https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths/ https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...

MatthiasPortzel 12d ago

You should have editor specific and platform specific files in your global gitignore. https://codeberg.org/ziglang/zig/src/branch/master/.gitignore#L2 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?

jmholla 12d ago
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.

laruss5 12d ago

[flagged]

vivzkestrel 12d ago

- 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 https://github.com/github/gitignore - funny how I did not see a single comment talk about this

piker 12d ago
Because it's insufficient? https://github.com/github/gitignore/blob/main/Rust.gitignore https://github.com/github/gitignore/blob/main/Rust.gitignore for example still falls victim to basically all of the issues specifically called out.
- aleqs 12d ago
  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 https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths/ https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
zarlss43 12d ago
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.
- adammarples 12d ago
  Just have a global, personal gitignore in your home folder to cover them
- bloomers 12d ago
  It's a good practice to ignore OS specific files in user level gitignore but I think that putting it (redundantly for some of us) in repo is a good practice. Some people don't maintain their own user ignores and might accidentally commit to shared repository. It's clearly fault of commiter and reviewer but let's just save ourselves stress and put those records in the .gitignore of the repo.

jedschmidt 12d ago

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

bob1029 12d ago

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.

datsci_est_2015 12d ago

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?

morkalork 12d ago

People still aren't committing CLAUDE.md?

Brajeshwar 12d ago

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 https://github.com/brajeshwar/dot

DarmokTanagra 12d ago
[dead]
wafflemaker 12d ago
Wow, thanks so much for . gitignore_global. Finally can have Emacs files ignored automatically in all projects. <3
- xtajv 12d ago
  Emacs can be configured to dump its litter into specific directories instead of in-situ with the files being edited. Please do.
Waterluvian 12d ago
> 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. What is weird about it?
- deleted 12d ago
  [deleted]

chrismorgan 12d ago

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?

aleqs 12d ago

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 https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths/ https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...

yipinwong 12d ago

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

der_gopher 12d ago
I like the analogy with ports, I also do the same - ufw deny all :)
JackSlateur 11d ago
Port numbers are convention A "security engineer minded approach" would be: own what is executed on the box;

skrrtww 12d ago

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.

IAmLiterallyAB 12d ago

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

zahrevsky 12d ago

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.

bizcalclab 12d ago

[flagged]

isityettime 12d ago

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.

getnormality 12d ago

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

temphaaa 12d ago

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

mohamedkoubaa 12d ago

"Works on my machine" accelerationism

dxjxjdjsssb 12d ago

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

Boxxed 12d ago

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

globular-toast 12d ago

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

der_gopher 12d ago
Yes, but people miss often what is committed, especially if the change is big.
- globular-toast 12d ago
  Eh? You explicitly have to add files to the stage before git will commit anything.

edukite 12d ago

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.

singpolyma3 12d ago

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

matijs 12d ago
Ban `git add .` for sure, but what’s so bad about `git commit -a`? It only adds/removes what was already under version control.
- singpolyma3 12d ago
  Makes it easy to commit things you didn't expect without having reviewed them
  - matijs 11d ago
    Ah fair enough, I've got commit.verbose set to true for that.

quantivaia 12d ago

[flagged]

nevalainen 12d ago

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

ltbarcly3 12d ago

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

agile-gift0262 12d ago

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

serbuvlad 12d ago

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.

Alifatisk 11d ago
Interesting!

michalc 12d ago

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

coneonthefloor 12d ago

Seems like they want a .gitallow

kazinator 12d ago

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.

mikenikles 12d ago

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.

Kuyawa 12d ago

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

anthovallee 12d ago

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

orielhaim 12d ago

[dead]

b5n 12d ago

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" }

jxndnendn 12d ago

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

bastawhiz 12d ago

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

senorrib 12d ago

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.

vanyle 11d ago

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.

Alifatisk 11d ago

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

booster-rooster 10d ago

[flagged]