Putting a stop to git add .
To be fair, there’s absolutely nothing wrong with taking this approach (legally), but that doesn’t mean it’s the best practice for all projects (or any project).
This command essentially stages all files with changes into the commit without even a second glance. This can be extremely dangerous.—especially in cases where .gitignore is poorly defined or, worse yet, nonexistent.
You could inadvertently stage and commit build artifacts, environment variables, configs, temp files, etc.
This would be especially problematic in enterprise scenarios. You’re gonna look really bad to the people above you if you’re having to explain accidentally pushing up a .env file or the ever-so-compact and lightweight node_modules folder.
It’s always best practice to compare the changes you’re making. It shouldn’t matter if the project is large or small. I’ve heard people say “Well, I’m just working on a small app on my own, Aron.”
My reply? If it’s that trivial, then there’s no reason to skip comparing the diffs. Takes little time. I mean, why would you want to avoid building good habits? Is it that hard to scan over your changes before staging them? Come on, man.
If you’re just working on a single file, then just manually stage it.
git add your-file
This eliminates any whoopsies. But this can become tedious if you’re working with multiple files.
git commit -av
This approach takes the same path as git add . but it then produces a diff for you to manually review the changes made and write out your commit message; which brings me to my next point.
Get into the habit of reading diffs and examining your changes, confirm them, and only then should you push.
git add -u
Here’s a nifty one. This command will only stage tracked files that have updates to them. This will avoid pushing files that haven’t been changed. I still would rather employ the previous command, however, as I’ve seen situations where a library like Prettier did a mass beautification of the entire src directory and the Junior didn’t compare the diff before sending up the changes.
No harm done, really, but it just proves that a window exists where even unintended changes occur and you may inadvertently push them to the repo. In fact, I should take some time to talk about incremental staging, but that’s an entirely different conversation.
Whichever method you employ, be sure to put yourself into building the healthy habit of examining your changes and ensuring you’re verifying every modification being done to the codebase before pushing.