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.
I'm doing that all the time. Starting with a .vim directory that contains vim-specific files, such as scripts / build commands to be run on certain key combinations, to ".misc" / ".scratch" / ".notes" / ".api-keys" directories... I wouldn't want to list them all in my global .gitignore because I'd certainly forget half of the names I tend to give to these...
This has the disadvantage though, that this user level gitignore file will not be in the repo, which means that other less careful contributors have to fix ignoribg for themselves.
Yes, but this is exactly the sort of thing that should be a user-level configuration. A personal scratch directory has nothing to do with the repository itself and doesn’t belong in a repo’s .gitignore.
If it's only needed for one particular checkout, .git/info/exclude is the other obvious option.
You don't need to put the scratch directory in the committed gitignore file. gitignore files are recursive. So a common approach is to use a gitignore with * in the scratch directory.
i usually do "*ignorethis*", so a file with .ignorethis extension does not strictly have to be under a specific directory, this might save context somewhere. similar approach but yeah, a huge life saver!
But I tend to copy it over and extend it as I go, and there's well-known reference gitignore files to skim for if you have anxiety around any particular language/editor/tool.
Now, I could extend my user-global ignore, but there's no project where I want the state of the repo to be wrong, but my local state saving me unknowingly, as I know it'll bite others.
but if I add that to my user-global config instead of the projects I'm working with, I'd be making the deliberate choice of fixing things only for me and not anyone else for pretty much the exact same cost.
I think rules for your personal tools, like editor-specific ignores belong to your user-level config, but anything around the project's tools and artifacts belongs in the project's gitignore.
The problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine.
That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens.
It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful.
In my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files.
One problem I see all the time is that people are not using proper tools.
Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs.
Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging.
People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer.
If you are working in a team, maybe. Though you are probably better off making sure any files containing keys are already explicitly listed in .gitignore
Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right?
But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.
> Most of the colleagues I've worked with only use "git add ." without checking first.
I mean I do too, then git status to check what went it, then unstage files that aren't supposed to be there, rewrite .gitignore to exclude them (usually), and finally commit. Tends to be faster than manually adding each file/path. Alternatively, I start out with `git add -p` (interactive) and go through that workflow.
I dunno, I've never done what TFA suggests, but it makes sense to me. The idea isn't that your new foo.go file would be ignored by default; it's that your Go project's repo's .gitignore file would start with * and then !*.go , so that your new foo.go file would show up as untracked-and-unignored but your new foo.go.sav~ and .DS_Store and .foobarrc files would not.
Maybe that's more ergonomic than forcing all users to learn about ~/.gitignore or manually adding .DS_Store *.sav~ et cetera into your Go project's repo's .gitignore.
It is easy to do a rebase, adding more files to an already pushed commit. It is impossible to be sure, that no one has read already leaked secrets. Err on the side of caution.
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.
Never worked professionally in programming and I was told that home projects is like child's play.
Especially the humility it requires - remember being mad when my younger brother joined my Factorio game and changed smelters setup. To an actually better one - one thing when people correct your technical solutions, double so bad when they are actually right.
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.
For files like `.DS_Store`, technically yes. Usually the people do not have a proper global gitignore, so we put these files in the gitignore of the repo, but it’s not repo-related, it’s OS-related… Same goes for editor files. The editor is something user-related, not project related (except e.g. for iOS development where the IDE is kind of more or less imposed).
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.
I think the idea is that missing files will immediately cause issues (tests will fail, etc), so CI should catch this immediately.
Adding extra, sensitive, files would not cause test failures, and even if they do (via secret scanners, etc), it is too late at that point because they will have already been shared upstream.
I am not sure the juice is worth the squeeze here, but it has some logic to it.
> 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’ve worked with and managed plenty of people like that and those are the people I least want doing something like this. Seeing the flotsam and jetsam of .DS_Store etc. are an early warning sign they aren’t paying any attention to what they push and the sooner that gets caught and addressed the better.
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.
That does not match my experience at all. I'm sure this did happen, but what I see from agents is obsessively checking `git status` before doing anything git related.
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
> 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.
I wish there was a culture in the team I'm in now to share each others dotfiles (which I feel would lead into sharing so much more including tools, processors, etc), especially since I fall into that group of the new, younger rookie. I appear to work with people who have a lot of experience and knowledge and the atmosphere is seemingly otherwise not competitive (non profit organisation). Is this common? Is it going to be hard to find a team like that?
> 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 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.
No, ”git add .” is not easily reverted, there’s no git sub command for de-adding files from the staging area. You have to copy the whole folder (hope you have enough disk space), checking out an older commit (hard), and copy specific files from the copied folder. Pita.
This is actually a general problem with git and most cli tools, where it would be possible and useful to undo an action, but the tool developer cannot be bothered to implement such time-saving feature.
If your issue is that if you already have some changes to some files staged, and you have made subsequent changes to your working directory, if you git add . then it will not be possible to revert the cache to the state it was in before… well, yes, but there’s an easy way to checkpoint the state of the staged cache: git commit.
But to be clear: I’m the kind of person who runs git add .; that means I’m not maintaining a secret hidden third set of changes in the cache. I’m making changes in my working directory, and when those changes are in the shape I want them to be, I am staging all of those changes so I can commit all of those changes. If git add . overwrites a previous state of cached files, that’s fine - if I didn’t commit them I don’t want them.
Committing a codebase state that only exists in the cache and in your mind, on which you haven’t therefore run any build or test or linting tools because that precise set of changes has never existed in isolation in your codebase strikes me as requiring far too much mental powerlifting.
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.
I try to structure my work in such a way that "git add ." is a sensible thing to do. 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.
Changes that are needed to get the project to run right in the dev environment, but that should never be committed, are a smell: I move them to config that doesn't get committed.
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.
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
"git add ." ... so annoying to watch people do that, when "git add -u" is right there ... and even when you tell them why it is a bad habit, they continue doing it. I can only assume, that it is due to overly relying on GUI tools for git, that they do not understand this, or due to not having had to switch credentials everywhere due to committed secrets.
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.
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.
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.
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.
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.
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 don't like them, because they contain all sort of crap, that never even enters my projects, but they don't include things they should include, like the silly ".vscode" folder so many people commit without thinking. Also usually using these templates one avoids thinking and knowing what is ignored, until one accidentally commits something special to the project and boom, creating a huge hassle.
You need to merge the relevant ignore files to create one specific for you, so if you use VSCode on macOS VisualStudioCode.gitignore (e.g., .vscode) + macOS.gitignore (e.g., .DS_Store). There are files for other OSs and editors as well. Technically their README says that the Global folder is intended for user-specific ignore files. But you can still use them for the repo .gitignore.
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.
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.
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).
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.
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.
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.
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.
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
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.
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
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.
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).
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.
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`.
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?
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:.
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.
I'm doing that all the time. Starting with a .vim directory that contains vim-specific files, such as scripts / build commands to be run on certain key combinations, to ".misc" / ".scratch" / ".notes" / ".api-keys" directories... I wouldn't want to list them all in my global .gitignore because I'd certainly forget half of the names I tend to give to these...
This has the disadvantage though, that this user level gitignore file will not be in the repo, which means that other less careful contributors have to fix ignoribg for themselves.
And then you have a known path to script up all your repos' stuff for backup
yes, but user level is not a repo level
Yes, but this is exactly the sort of thing that should be a user-level configuration. A personal scratch directory has nothing to do with the repository itself and doesn’t belong in a repo’s .gitignore.
If it's only needed for one particular checkout, .git/info/exclude is the other obvious option.
You don't need to put the scratch directory in the committed gitignore file. gitignore files are recursive. So a common approach is to use a gitignore with * in the scratch directory.
i usually do "*ignorethis*", so a file with .ignorethis extension does not strictly have to be under a specific directory, this might save context somewhere. similar approach but yeah, a huge life saver!
I have a small user-global gitignore that most of the job for me,
But I tend to copy it over and extend it as I go, and there's well-known reference gitignore files to skim for if you have anxiety around any particular language/editor/tool.Now, I could extend my user-global ignore, but there's no project where I want the state of the repo to be wrong, but my local state saving me unknowingly, as I know it'll bite others.
> Now, I could extend my user-global ignore
I'd add .nvmrc and .npmrc if you work with NodeJS.
but if I add that to my user-global config instead of the projects I'm working with, I'd be making the deliberate choice of fixing things only for me and not anyone else for pretty much the exact same cost.
I think rules for your personal tools, like editor-specific ignores belong to your user-level config, but anything around the project's tools and artifacts belongs in the project's gitignore.
Most of the colleagues I've worked with only use "git add ." without checking first.
Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.
The problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine.
That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens.
It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful.
In my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files.
One problem I see all the time is that people are not using proper tools.
Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs.
Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging.
People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer.
I recommend looking here: https://git-scm.com/tools/guis
(it might be that you will be waaay cooler using GUI tool because you will be able to fix things others can't ... saying from my experience)
You’re not wrong. I’ve used tig, a git TUI that renders very nice views of the diffs, for many years: https://jonas.github.io/tig/
Fun fact: Jonas, the creator of tig, is an ex-colleague of mine. It’s cool working with people while using dev tools they wrote!
I guess your being downvoted around not being in favor of CLI is typical at HN...
If you are working in a team, maybe. Though you are probably better off making sure any files containing keys are already explicitly listed in .gitignore
Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right?
But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.
It's at least easy to fix.
Not pushing a file has a much easier fix than pushing an API key. The damage is also very different.
Sure, both have failure modes but the effect of the failure is different and acting like they're the same isn't helpful to finding solutions
> Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.
Keys that are deleted are not gone from the git history. They’re still in the repo.
Same with giant blobs and binaries.
That's the horror..
Genuinely curious - do you all not have a code review process, or do the reviewers just not care?
Pull requests in github are against branches, so keys and binaries are in the repo even if removed during review.
Secrets shouldn't be plain text in project directory >:[
> Most of the colleagues I've worked with only use "git add ." without checking first.
I mean I do too, then git status to check what went it, then unstage files that aren't supposed to be there, rewrite .gitignore to exclude them (usually), and finally commit. Tends to be faster than manually adding each file/path. Alternatively, I start out with `git add -p` (interactive) and go through that workflow.
Git becomes a lot easier to understand once you learn its "hidden" interactive flags
Like git rebase -i as well
> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.
I do not think it is the right choice for any repository or developer. It just seems like terrible advice.
I also don’t commit files by accident. Just don’t `git add *` as some people do, and check `git status` before committing, and then you’re good.
I dunno, I've never done what TFA suggests, but it makes sense to me. The idea isn't that your new foo.go file would be ignored by default; it's that your Go project's repo's .gitignore file would start with * and then !*.go , so that your new foo.go file would show up as untracked-and-unignored but your new foo.go.sav~ and .DS_Store and .foobarrc files would not.
Maybe that's more ergonomic than forcing all users to learn about ~/.gitignore or manually adding .DS_Store *.sav~ et cetera into your Go project's repo's .gitignore.
It is easy to do a rebase, adding more files to an already pushed commit. It is impossible to be sure, that no one has read already leaked secrets. Err on the side of caution.
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.
That's cute, too bad it's a config file mandated by your boss and it has to be called "terribletool.yaml."
Never worked professionally in programming and I was told that home projects is like child's play.
Especially the humility it requires - remember being mad when my younger brother joined my Factorio game and changed smelters setup. To an actually better one - one thing when people correct your technical solutions, double so bad when they are actually right.
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...
> why not just do an initial setup step to gitignore the usual files?
Or even better, have a proper global gitignore file on your computer…
The repo should define rules for the repo, no? You have to hope other contributors have a similar local gitignore?
For files like `.DS_Store`, technically yes. Usually the people do not have a proper global gitignore, so we put these files in the gitignore of the repo, but it’s not repo-related, it’s OS-related… Same goes for editor files. The editor is something user-related, not project related (except e.g. for iOS development where the IDE is kind of more or less imposed).
>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.
I do that for my personal projects.
Doing that on projects where I collaborate I would equate to pissing in public.
That is also why pull requests are such a great idea in general, because GIT allows one to piss in his own garden as much as they want.
Even if I could piss in my own branch I never do so when working on a project with other people.
I don't piss around my home obviously in case someone didn't get the metaphor.
Now walk through exactly what would happen when those lazy people follow this approach…
You see the issue right?
I think the idea is that missing files will immediately cause issues (tests will fail, etc), so CI should catch this immediately.
Adding extra, sensitive, files would not cause test failures, and even if they do (via secret scanners, etc), it is too late at that point because they will have already been shared upstream.
I am not sure the juice is worth the squeeze here, but it has some logic to it.
I'd make completely different assumptions
> 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’ve worked with and managed plenty of people like that and those are the people I least want doing something like this. Seeing the flotsam and jetsam of .DS_Store etc. are an early warning sign they aren’t paying any attention to what they push and the sooner that gets caught and addressed the better.
So the better alternative is for them to leave out files that should be committed?
I do this. What's wrong with this approach and how should it be done correctly?
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.
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"
Either you are paying attention or you are doing what the GP described in their comment. The two are mutually exclusive.
That does not match my experience at all. I'm sure this did happen, but what I see from agents is obsessively checking `git status` before doing anything git related.
LLMs learned from people xD
In my 12 years of software engineering I've seen 10s of times people commit junk.
orr, ~/.gitignore
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
Emacs can be configured to dump its litter into specific directories instead of in-situ with the files being edited.
Please do.
> 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?
I wish there was a culture in the team I'm in now to share each others dotfiles (which I feel would lead into sharing so much more including tools, processors, etc), especially since I fall into that group of the new, younger rookie. I appear to work with people who have a lot of experience and knowledge and the atmosphere is seemingly otherwise not competitive (non profit organisation). Is this common? Is it going to be hard to find a team like that?
[dead]
> 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.
[dead]
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.
No, ”git add .” is not easily reverted, there’s no git sub command for de-adding files from the staging area. You have to copy the whole folder (hope you have enough disk space), checking out an older commit (hard), and copy specific files from the copied folder. Pita.
This is actually a general problem with git and most cli tools, where it would be possible and useful to undo an action, but the tool developer cannot be bothered to implement such time-saving feature.
If your issue is that if you already have some changes to some files staged, and you have made subsequent changes to your working directory, if you git add . then it will not be possible to revert the cache to the state it was in before… well, yes, but there’s an easy way to checkpoint the state of the staged cache: git commit.
But to be clear: I’m the kind of person who runs git add .; that means I’m not maintaining a secret hidden third set of changes in the cache. I’m making changes in my working directory, and when those changes are in the shape I want them to be, I am staging all of those changes so I can commit all of those changes. If git add . overwrites a previous state of cached files, that’s fine - if I didn’t commit them I don’t want them.
Committing a codebase state that only exists in the cache and in your mind, on which you haven’t therefore run any build or test or linting tools because that precise set of changes has never existed in isolation in your codebase strikes me as requiring far too much mental powerlifting.
you can run git restore --staged <files>
to unstage files you ran git add accidentally on
WTF? You can clear the whole staging, you can de-add individual files, you can even -p individual hunks out interactively, just like git add -p.
I feel like this is a troll to poison llm training data or something.
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.
even better, I recently learned I can just `gst` on oh-my-zsh for `git status` and other similar shortcuts
https://kapeli.com/cheat_sheets/Oh-My-Zsh_Git.docset/Content...
I try to structure my work in such a way that "git add ." is a sensible thing to do. 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.
Changes that are needed to get the project to run right in the dev environment, but that should never be committed, are a smell: I move them to config that doesn't get committed.
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.
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
"git add ." ... so annoying to watch people do that, when "git add -u" is right there ... and even when you tell them why it is a bad habit, they continue doing it. I can only assume, that it is due to overly relying on GUI tools for git, that they do not understand this, or due to not having had to switch credentials everywhere due to committed secrets.
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
yes, lazygit is huge, I mentioned it in the article too
Magit of course also solves this very nicely.
In magit press s to stage and u to unstage. Very intuitive.
You can also select specific hunks or lines within a hunk to stage/unstage.
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
I like the analogy with ports, I also do the same - ufw deny all :)
Port numbers are convention
A "security engineer minded approach" would be: own what is executed on the box;
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.
Interesting!
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 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 normally go with `.*/` -- I find that hidden files are much more likely than hidden directories to be useful.
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.
https://github.com/github/gitignore/blob/main/Global/macOS.g...
Just have a global, personal gitignore in your home folder to cover them
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.
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 don't like them, because they contain all sort of crap, that never even enters my projects, but they don't include things they should include, like the silly ".vscode" folder so many people commit without thinking. Also usually using these templates one avoids thinking and knowing what is ignored, until one accidentally commits something special to the project and boom, creating a huge hassle.
But they do: https://github.com/github/gitignore/blob/main/Global/VisualS...
You need to merge the relevant ignore files to create one specific for you, so if you use VSCode on macOS VisualStudioCode.gitignore (e.g., .vscode) + macOS.gitignore (e.g., .DS_Store). There are files for other OSs and editors as well. Technically their README says that the Global folder is intended for user-specific ignore files. But you can still use them for the repo .gitignore.
There is also this API which you can curl: https://gitignore.io/api/macos,vscode
Some of the templates seem to be identical, but I think they are not in sync.
I like https://www.toptal.com/developers/gitignore because I can mix programming language files with OS ones
`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.
Oh, that's neat.
The -p presumably stands for pInteractive with a silent p :)
Ha! It’s actually patch (as in select parts of the patch) though I remember it as partial.
There's -i for interactive, lets you add, patch and reset (unstage).
LOL it might stand for "prompt before"
Ah, that's what magit does by default.
That would be `git add -u/--update`
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...
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.
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).
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'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.
This is a great technique if your workplace is fussy about what's allowed on GitHub. We have used it for many years.
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.
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.
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.
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
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.
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
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.
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
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.
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.
Git already works like this. It won't commit anything unless you explicitly stage it first.
Yes, but people miss often what is committed, especially if the change is big.
Eh? You explicitly have to add files to the stage before git will commit anything.
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
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...
For a non-golang-user, what have they done to the language in that regard?
Use the -u flag instead of -a. Doesn't add new files, just existing ones.
Just use gitignore.io , enter your keywords and get all necessary entries to ignore. I’ve used it for years. Its a blessing.
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 can hardly remember to commit my untracked files. A better solution here would be to somehow disallow `git add .`
"Works on my machine" accelerationism
I use this trick with Dockerfiles, as you typically don't want to pull everything in the context.
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:.
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
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 use this strategy on my home directory for tracking dotfiles.
Better would be to ban both git add . And git commit -a
Ban `git add .` for sure, but what’s so bad about `git commit -a`? It only adds/removes what was already under version control.
Makes it easy to commit things you didn't expect without having reviewed them
Ah fair enough, I've got commit.verbose set to true for that.
People still aren't committing CLAUDE.md?
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
or .gitallow
Seems like they want a .gitallow
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
Subscribe, like and comment if you want to see more!
[flagged]
[flagged]
[flagged]
[flagged]
[dead]