Developers often find themselves in a situation where a commit message was misspelled because they were in a hurry to deliver a new feature.
While this is not any kind of a serious problem, it is nice to keep your commits history clean and understandable.
In this article, we will learn two ways to change a commit message in Git.
The last commit message can be changed with the git commit --amend -m "<New message>"
command.
This command overwrites an existing commit with a completely new one with a different hash.
Let's take a look at this in action:
As you noticed, the commit hash has changed, which basically means that the old commit has been deleted and a new one has been created.
If your commit only exists locally, everything is fine and you can push your branch to Github (git push origin main).
But what if you have already pushed a commit that contains a mistake and changed it with an amend command?
You can force push it (git push origin main -f) and it will be overwritten, but be careful with force pushes.
If someone depends on your branch, they would need to fix their history.
If it is necessary to change the commit message for an old commit or a set of commits, then an interactive rebase can be used:
git rebase -i HEAD~n
Where n is the number of commits to display.
Let's add 3 commits and try to change the messages:
Click "Enter" and you will land on the following screen:
Read the notes under the last commit and note the following:
# r, reword <commit> = use commit, but edit the commit message
Replace pick with reword for every commit you want to change message for:
Save and close this file.
After that, you will see a commit file for each changed commit.
Change the message, save and close each of them:
And you're done. Check the terminal for a success message:
When you're done with the changes, force-push them to Github over the old commits.
Before moving on to the next section to find out the differences between interactive rebase and amend, let's check the commit hashes:
Before rebase:
After rebase:
Obviously all are changed, although only the ones that were edited should be changed (Commit 1 and Commit 2).
So, why did this happen?
Modifying commits with both "Interactive Rebase" and "Amend" will cause old commits to be deleted and new ones to be created with new hashes.
However, there is an important difference.
With an interactive rebase, each commit that follows the modified commit receives a new hash, since each commit contains the ID of its parent.
In the previous section, Commit 3 follows the changed Commit 2, so its hash has also been updated.
In summary, changing the commit is the thing that developers do frequently, so knowing the appropriate commands can save you a lot of time you could spend googling the solution.
It's important to understand the difference between the two options and the consequences of using them.
Remember that when a branch is pushed (made public) on Github, it's risky to change commits and do a force push, as other developers might rely on it.