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.
Motivation
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
cd
into it. - 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
dev
branch:
$ 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-edit
because 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.
Summary
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)