Stop Using git add .

I want you to stop using git add .
It sets you up for failure. Use git add -p or git commit -p instead.

---

[SXsoft]

let's be serious when you work on a feature branch, until you merge it you will add all the things you modified in 95% of cases

[walterlol]

That's why I git add . when I finish a specific task before starting something else. This is more an unorganized approach to working on files.

[benloud]

Probably not a good habbit to get in to. By only partially commiting your working directory, the state of the head of your branch is not something thats ever been run. You could easily get the branch in a state where it doesn't work. I prefer to test what i have then commit exactly that, so my branch is always good.

[lhxperimental]

I do code reviews, I always prefer clean merge requests. Many times developers will touch many files and make whitespace or formatting changes. This increases the time it takes to review and half of my time is spent in trying to figure out if something is a formatting chage or have they actually made a material change. When I commit, I always do a diff in my IDE and only push the material changes.

[daleryanaldover]

Been a dev for almost 4 years now and this is the first time I heard about patch adding. I think this is what vscode does with their stage selected changes only feature with git which I do a lot since I discovered it. Before that I have branches and stashes and it can get messy real quick.

[blessdarah]

The reason for patch is so that you can select what to commit and stash or discard the rest. Otherwise if your git ignore file is fine, then the git add . is just perfect. Don’t see a problem with that.

[banjohead]

This is the first time I've seen this used. It's pretty slick! What I love most is how utterly intentional and deliberate it is -- it takes a lot of the "oh, whatever" out of the process.

[boomvroomshroom]

This popped up on my recommended. So helpful! I missed using Vim-Fugitive (not able to use Vim at work) because it let you stage changes in chunks, so this will be super handy!

[armandoleon]

Nice!!! Saves me time. I usually manually added all the files one by one to the stage and cross referenced with git status and removed any ones I accidentally added by doing git checkout — <filename>. This saves time!! Ty!!! 😊

[harleyspeedthrust]

this is cool, I didn't know about this. my usual workflow when committing is to review the diff for all the changed files that i want to commit. this helps me catch extra garbage that i might have left in there, like a logging statement, some messy code i intended to clean up later, etc.

[Kagrath]

Welcome back! I'll give patch adding a try in the future. My usual method is just adding files individually or directories of files I know are ready to go, do people often just shoot from the hip with "add ."? Scary!

[phanirithvij]

I think so too but for a different reason, my preference is to use a tui called lazygit which is far more efficient (it does breakdown for huge monorepos but worked 100% of time on all my repos)

[MrVoidfull]

Awesome to see that there's a proper terminal way to do this. I've been doing basically this from the IDE's changes viewer, basically checking all of my changes line by line before adding and commiting. Even though I usually don't have any code which I do not wish to commit laying around, it's always good to check for useless white spaces, bad indents and forgotten console.log("entered method"); :D

[Redyf]

I can't believe I had no idea about that command. Thanks for sharing Chael

[romankyrnis]

Great! Nice tip, thank you! Waiting for a lot more

[Outfrost]

This is a really neat explanation! Patch adding, but also patch checkout, has been incredibly useful in everything I do that's versioned.

[frustratedalien]

This maybe a dumb question, but how do you know which changes worked and which ones didn't if they are all in your working directory? The way I work, and the way I've seen others work, is that I'll be solving a problem or trying to get a test case to pass and when that works, everything that's not ignored through .gitignore are things I want to add/commit, or else my CI pipeline will fail. At the moment that my tests passed locally, I want all of those changes to be committed, if that makes sense. If I pick and choose this way, there's a good chance my CI pipeline will fail when I push and I won't know about it for at least 20 minutes 😅
git add . can still cause problems, so I am not advocating for that and I can understand where git add -p might be useful, but I don't get git commit -p
It probably doesn't fit my workflow because I like to squash my commits into one at the end of the day and that interactive rebase is where I handle fixing (or squashing) commit messages and stuff like that.

[lidinzx]

woww, never really knew some feature like this was in git, really helpful to know!! thanks

[checkerist]

I do the same thing with JetBrains IDE. Happy to know that there is a Git-native way for everybody!

[Marfig]

I'll keep using git add . But thanks for the advise.