Keeping the Git History clean is not just for aesthetics. I'm aware of that, but I've seen beginners making big mistakes while trying to achieve the perfect track.
I've been there too, and I would recommend making several small commits instead, even if it contains reverts and other fixing. That's still far better than some approaches I consider unrealistic.
What? You like messy history?
Absolutely no. I'm not saying you should write whatever you want in the history just to get the job done.
However, rewriting history with commands such as reset or rebase can be dangerous, especially if you need to pass a git push --force at the end.
Don't get me wrong. I like rebase -i, as it allows reorganizing commits and having a more meaningful history.
Theoretically, you should always use it BEFORE you push anything to the remote repository. This way, you might appear as a mastermind who never commits useless or buggy stuff.
It's not actually that complicated. The problem is people tend to use it after pushing their work, which forces them to use the --force flag.
It is a very bad practice when it's the main or the master branch, but also in other branches, especially when there are several committers on the same branch, which is not rare.
What can go wrong?
You can make serious damages in search of the "Holy Git History", for example:
- losing code and value
- wasting precious time debugging regressions
- messing with others' work
I know what you're thinking. There are several ways to mitigate such bad outcomes:
- restoring the remote repository from another machine
- regular backups
- branch rules that protect against
push --force - PR (Pull Requests) and reviews
- pre-commit rules on major platforms, like GitLab
While it does help, it's still possible to modify these rules, and not all teams have them. Besides, backups may still not contain the latest version of the project.
It's necessary but not sufficient. You should definitely use that, but your approach of committing is critical.
What to do then?
Instead of trying some fancy rebase/reset commands that will ultimately override the Git history, why not use simple small commits?
If you don't want your name to be associated with commits like "revert xxx" or "fix commit xxx," please consider that messing with the Git history is worse, for sure.
To make your life easier, you can also use resources like Husky that leverage pre-commit hooks.
It means that you can define some rules, even apply a custom sh script before any commit, which can prevent lots of nasty bugs and other syntax errors.
Indeed, making small simple commits should reduce those errors, but it's still possible.
Husky is not the only solution available, but it's one of the most robust and popular.
I want to do it without NPM
I would not recommend the "DIY" approach, especially to beginners, but if you're curious about git hooks, you can look into the .git/hooks folder of your project:
./applypatch-msg.sample
./commit-msg.sample
./fsmonitor-watchman.sample
./post-update.sample
./pre-applypatch.sample
./pre-commit.sample
./pre-merge-commit.sample
./pre-push.sample
./pre-rebase.sample
./pre-receive.sample
./prepare-commit-msg.sample
./push-to-checkout.sample
./update.sample
Then, you may rename the file you want to use (remove the .sample extension), for example:
cp -n pre-commit.sample pre-commit
If you don't use NPM, you can leverage another package manager like pip (Python):
pip install pre-commit
You can learn more here: pre-commit.com
Wrap up
Don't think the Git History is the ultimate achievement. It IS important, but not at all costs.
The word "clean" can be confusing. Readability is more useful for you and your team. If your teammates can easily read your commits, then it's easy to review, which should be a priority for you, IMHO.
Top comments (0)