Time has come to share useful git tricks and commands like
git commit --amend +
git force --push. We’ll show how using them helps us to keep
git history stable.
If you later find this article useful take a look at the disclaimer for information on how to thank me.
We have already explored git merge –squash as a way to remove redundant commits from git history. While this may be a nice trick, it may not always be a good choice. Mostly because, the commits have to be as small as possible. Whereas, git merge –squash may cause a single very large commit. While it may solve messed up history, this commit might be very hard to understand because of its size. There’s a better strategy which we’ll explore today.
git commit –amend + git push –force theory
In short, correct git usage implies making shortest possible commits. In case debugging of a single commit is required, a combination of
git commit --amend and
git push --force will be used. This will allow us to perform debug and testing cycles till the change in the commit will be confirmed as successfully working. Of course, this strategy assumes you test the code from a remote branch. For example, if you debug some Jenkins pipeline from a development branch. If you debug and test locally, use only
git commit --amend.
git commit --amend + git push --force demo
- clone sample repo from my github and
- we are on main branch:
$ git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean
- let’s create and checkout new
$ git checkout -b amendpush Switched to a new branch 'amendpush'
- let’s make sample change, commit and push it:
$ echo "b" >> a $ git commit -am 'b' $ git push
- now, after testing, we see that the change in the commit doesn’t work. What can we do? We can add a fix, commit it on top of an existing unstable commit, push it and test again. What if it still doesn’t work? The same cycle again? NO! Don’t do that. This way the history will be derailed and spoiled with unstable commits. No one can neither safely revert to them, nor understand the changes there which are unstable. It’s better to make the change in a completely new commit which replaces the latest unstable commit. For that we’ll use below commands:
$ echo "bb" >> a # the fix to the previous commit $ git commit -a --amend --no-edit $ git push --force
- So, what happened here? We replaced the latest (unstable) commit with the new one by using
--amend. We added
--no-editbecause the previous commit message doesn’t change if we described the change properly. We force push the change to replace the remote latest commit with a new one. Then, if testing still fails, do a new change and replace the latest commit. Continue doing so until the change in the commit passes testing. This way the change will be in a single tested commit. And each new future change should be in such a commit.
That’s it about
git commit --amend + git push --force. As always, feel free to share and comment.
If you found this article useful, take a look at the disclaimer for information on how to thank me.
You may find below articles useful as well:
- Messed up your git history? Use git merge squash to clean it.
- Git Repository in Another Git RepositoryGit Repository in Another Git Repository
- GitLab Self-Hosted Runners Demo
- Bonus: Recommended Git courses on Pluralsight I learned from.
Sign up using this link to get exclusive discounts like 50% off your first month or 15% off an annual subscription)