Categories
Best Practices

Git Tricks: git commit –amend + git force –push

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:

  • 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)

Recommended Git books on Amazon: