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.
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
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
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.
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
- 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.
Instead of trying some fancy
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 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 install pre-commit
You can learn more here: pre-commit.com
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.