How to change commit message in git

Rewriting History

In this section, you’ll see how to accomplish these tasks so that you can make your commit history look the way you want before you share it with others.

One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world.

Changing the Last Commit

Changing your most recent commit is probably the most common rewriting of history that you’ll do. You’ll often want to do two basic things to your last commit: simply change the commit message, or change the actual content of the commit by adding, removing and modifying files.

If you simply want to modify your last commit message, that’s easy:

The command above loads the previous commit message into an editor session, where you can make changes to the message, save those changes and exit. When you save and close the editor, the editor writes a new commit containing that updated commit message and makes it your new last commit.

You need to be careful with this technique because amending changes the SHA-1 of the commit. It’s like a very small rebase — don’t amend your last commit if you’ve already pushed it.

When you amend a commit, you have the opportunity to change both the commit message and the content of the commit. If you amend the content of the commit substantially, you should almost certainly update the commit message to reflect that amended content.

On the other hand, if your amendments are suitably trivial (fixing a silly typo or adding a file you forgot to stage) such that the earlier commit message is just fine, you can simply make the changes, stage them, and avoid the unnecessary editor session entirely with:

Changing Multiple Commit Messages

3 because you’re trying to edit the last three commits, but keep in mind that you’re actually designating four commits ago, the parent of the last commit you want to edit:

Remember again that this is a rebasing command — every commit in the range HEAD

3..HEAD with a changed message and all of its descendants will be rewritten. Don’t include any commit you’ve already pushed to a central server — doing so will confuse other developers by providing an alternate version of the same change.

Running this command gives you a list of commits in your text editor that looks something like this:

Notice the reverse order. The interactive rebase gives you a script that it’s going to run. It will start at the commit you specify on the command line ( HEAD

3 ) and replay the changes introduced in each of these commits from top to bottom. It lists the oldest at the top, rather than the newest, because that’s the first one it will replay.

You need to edit the script so that it stops at the commit you want to edit. To do so, change the word “pick” to the word “edit” for each of the commits you want the script to stop after. For example, to modify only the third commit message, you change the file to look like this:

When you save and exit the editor, Git rewinds you back to the last commit in that list and drops you on the command line with the following message:

These instructions tell you exactly what to do. Type:

Change the commit message, and exit the editor. Then, run:

This command will apply the other two commits automatically, and then you’re done. If you change pick to edit on more lines, you can repeat these steps for each commit you change to edit. Each time, Git will stop, let you amend the commit, and continue when you’re finished.

Reordering Commits

You can also use interactive rebases to reorder or remove commits entirely. If you want to remove the “Add cat-file” commit and change the order in which the other two commits are introduced, you can change the rebase script from this:

Squashing Commits

It’s also possible to take a series of commits and squash them down into a single commit with the interactive rebasing tool. The script puts helpful instructions in the rebase message:

If, instead of “pick” or “edit”, you specify “squash”, Git applies both that change and the change directly before it and makes you merge the commit messages together. So, if you want to make a single commit from these three commits, you make the script look like this:

When you save and exit the editor, Git applies all three changes and then puts you back into the editor to merge the three commit messages:

When you save that, you have a single commit that introduces the changes of all three previous commits.

Splitting a Commit

Git applies the last commit ( a5f4a0d ) in the script, and your history looks like this:

This changes the SHA-1s of the three most recent commits in your list, so make sure no changed commit shows up in that list that you’ve already pushed to a shared repository. Notice that the last commit ( f7f3f6d ) in the list is unchanged. Despite this commit being shown in the script, because it was marked as “pick” and was applied prior to any rebase changes, Git leaves the commit unmodified.

Deleting a commit

Because of the way Git builds commit objects, deleting or altering a commit will cause the rewriting of all the commits that follow it. The further back in your repo’s history you go, the more commits will need to be recreated. This can cause lots of merge conflicts if you have many commits later in the sequence that depend on the one you just deleted.

If you finish a rebase and decide it’s not what you want, you can use git reflog to recover an earlier version of your branch. See Data Recovery for more information on the reflog command.

The Nuclear Option: filter-branch

Removing a File from Every Commit

Making a Subdirectory the New Root

Now your new project root is what was in the trunk subdirectory each time. Git will also automatically remove commits that did not affect the subdirectory.

Changing Email Addresses Globally

This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA-1 in your history, not just those that have the matching email address.

Changing a commit message

In this article

If a commit message contains unclear, incorrect, or sensitive information, you can amend it locally and push a new commit with a new message to GitHub. You can also change a commit message to add missing information.

Rewriting the most recent commit message

In Git, the text of the commit message is part of the commit. Changing the commit message will change the commit ID—i.e., the SHA1 checksum that names the commit. Effectively, you are creating a new commit that replaces the old one.

Commit has not been pushed online

On the command line, navigate to the repository that contains the commit you want to amend.

In your text editor, edit the commit message, and save the commit.

You can add a co-author by adding a trailer to the commit. For more information, see «Creating a commit with multiple authors.»

You can create commits on behalf of your organization by adding a trailer to the commit. For more information, see «Creating a commit on behalf of an organization»

The new commit and message will appear on GitHub.com the next time you push.

You can change the default text editor for Git by changing the core.editor setting. For more information, see «Basic Client Configuration» in the Git manual.

Amending older or multiple commit messages

If you have already pushed the commit to GitHub.com, you will have to force push a commit with an amended message.

We strongly discourage force pushing, since this changes the history of your repository. If you force push, people who have already cloned your repository will have to manually fix their local history. For more information, see «Recovering from upstream rebase» in the Git manual.

Changing the message of the most recently pushed commit

Changing the message of older or multiple commit messages

If you need to amend the message for multiple commits or an older commit, you can use interactive rebase, then force push to change the commit history.

On the command line, navigate to the repository that contains the commit you want to amend.

n command to display a list of the last n commits in your default text editor.

The list will look similar to the following:

Replace pick with reword before each commit message you want to change.

Save and close the commit list file.

In each resulting commit file, type the new commit message, save the file, and close it.

For more information on interactive rebase, see «Interactive mode» in the Git manual.

As before, amending the commit message will result in a new commit with a new ID. However, in this case, every commit that follows the amended commit will also get a new ID because each commit also contains the id of its parent.

If you have included sensitive information in a commit message, force pushing a commit with an amended commit may not remove the original commit from GitHub. The old commit will not be a part of a subsequent clone; however, it may still be cached on GitHub and accessible via the commit ID. You must contact GitHub Support with the old commit ID to have it purged from the remote repository.

How to Change Commit Message In Git

Many programmers underestimate the role of the commit message, while it is very important for managing the work. It helps other developers working on your project to understand the changes that you have made. So it must be as concrete, well-structured and clear as possible.

In this snippet, we will show you how to change your most recent commit message, as well as how to change any number of commit messages in the history.

Read on to see the options.

Changing the Most Recent Commit Message

Running this will overwrite not only your recent commit message but, also, the hash of the commit. Note, that it won’t change the date of the commit.

It will also allow you to add other changes that you forget to make using the git add command:

Check out Force Pushing Local Changes to Remote for more details on how to force push your changes.

Changing Multiple Commit Messages

In this section, we will show you the steps to follow if you want to change multiple commit messages in the history.

Run Git Rebase in Interactive Mode

Firstly, you should run the git rebase in the interactive mode:

Type «Reword»

After the first step, the editor window will show up the 10 most recent commits. It will offer you to input the command for each commit. All you need to do is typing «reword» at the beginning of each commit you want to change and save the file. After saving, a window will open for each selected commit for changing the commit message.

Enter a New Commit Message

After the second step, an editor will open for each commit. Type a new commit message and save the file.

Check out Force Pushing Local Changes to Remote for more details on how to force push your changes.

Force Pushing Local Changes to Remote

It is not recommended to change a commit that is already pushed because it may cause problems for people who worked on that repository.

Here is an alternative and safer way to amend the last commit:

The git add and git commit Commands

The git add command is used for adding changes in the working directory to the staging area. It instructs Git to add updates to a certain file in the next commit. But for recording changes the git commit command should also be run. The git add and git commit commands are the basis of Git workflow and used for recording project versions into the history of the repository. In combination with these two commands, the git status command is also needed to check the state of the working directory and the staging area.

The git push Command

The git push command is used to upload the content of the local repository to the remote repository. After making changes in the local repository, you can push to share the modification with other members of the team.

Yes, you CAN change commit message in git, here’s HOW!

Table of Contents

Quick cheat sheet to change commit message in git

You just did a commit then realized the message is not the intended one, or you want to git change commit message on multiple commits. Here is what you should do.

You can also git change commit messages on the HEAD using a soft reset.

Use the longer route by doing a soft reset followed by a mixed reset. Then commit the changes with a new message.

To edit multiple commit messages or specific commit message that is NOT the HEAD, interactively rebase the commit using any of these commands:

Specify the commit hash for one change.

Your default text editor opens up. You can then reword the message.

Edit multiple commit messages by selecting a bunch of commits from the HEAD to the target commit hash.

where N is the number of commits, from the top excluding the parent commit hash, whose message you want to edit.

As shown in the next sections of this tutorial, it would help to find a detailed explanation of the git commit message and practice git change commit message using relatable examples.

What is a git commit message? Do’s and Don’ts

A git commit message explains why a change occurred in a repository. It plays a significant role in marking software releases and bug fixes.

You will mostly apply git commit messages when collaborating on a project, enabling your teammates to figure out why you made a change on the branch you are working on. Editing commit messages lets you put more descriptive information or entirely overwrite the message.

Despite the excellent side of the git change commit message, you should use it cautiously. For instance, the change could be unconducive for pushed files because changing a commit message alters the SHA id.

Another reason to avoid git change commit message is that the operation automatically commits staged changes even if you had not decided to commit them.

Now that you know what can lead to editing a commit message and the drawbacks of git change commit message, let us see them in action.

Lab setup to practice git change commit message

Create a new repo

I am creating a remote repo called change_commit_message on GitHub.

After creating the repo, copy its URL and clone it on your preferred terminal or command line.

Configure the text editor

I am changing my git’s default text editor to Visual Studio Code.

Build a commit history

Let’s cd into the new repo and create a few commits in readiness for git change commit message examples.

Second commit

Third commit

Fourth commit

We have four commits.

We have some commits to play with. Let’s git change commit messages using relatable examples.

Scenario-1: Editing the last commit message

Example-1: Using the amend flag

Let’s recheck the history.

The commit message got edited!

Example-2: Doing a soft reset

The reset command for doing git change commit message is

1 with the caret symbol ^ to refer to the last commit, as shown below.

A soft reset undoes the commit HEAD changes. We can then rewrite the message.

Our last commit message changed from Add the fourth commit to Edit the fourth commit.

We can also go the longer route by unstaging the file.

Do a soft reset.

Unstage the last indexed file.

Then restage and recommit it using a new commit message

Recheck the history.

The last commit message changed from Edit the fourth commit to Change the fourth commit message entirely.

Scenario-2: Git change commit messages on specific file(s)

Running the command

asks for a commit message to change the commit before the specified hash by opening our text editor.

Let’s edit the commit message to Edit the third commit. That changes the commit message before the commit hash fc87791e0565c40d5fbdb38fead250e646fdddcd

Example-4: Interactively rebase a commit hash

Interactive rebase is one of the most familiar ways to git change commit messages. We can use it to edit one commit by rebasing our third last commit as follows

The text editor reopens, asking us for a new commit message for the target commit hash. Let’s edit the message from Edit the third commit to Change to fourth commit, close the text editor then check the history.

Scenario-3: Changing multiple commit messages

Example-5: Interactively rebase the HEAD

Replacing N with 3 in the command

opens our default text editor. This time around, let’s reword every commit message, close the editor and see what happens.

The editor reopens three times, asking for respective commit messages. I am replacing each Add or Edit with Track then logging the history to check the result of git change commit messages.

And that’s the fundamentals of git change commit message using the rebase commit.

Conclusion

Related Posts

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

How do I edit an incorrect commit message in git ( that I’ve pushed )?

I want to modify a commit message deeper in history and I’ve pushed many new commits.

How do I change the commit message? Is it possible?

7 Answers 7

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The message from Linus Torvalds may answer your question:

Short answer: you can not (if pushed).

extract (Linus refers to BitKeeper as BK):

Side note, just out of historical interest: in BK you could.

And if you’re used to it (like I was) it was really quite practical. I would apply a patch-bomb from Andrew, notice something was wrong, and just edit it before pushing it out.

I could have done the same with git. It would have been easy enough to make just the commit message not be part of the name, and still guarantee that the history was untouched, and allow the «fix up comments later» thing.

Part of it is purely «internal consistency». Git is simply a cleaner system thanks to everything being SHA1-protected, and all objects being treated the same, regardless of object type. Yeah, there are four different kinds of objects, and they are all really different, and they can’t be used in the same way, but at the same time, even if their encoding might be different on disk, conceptually they all work exactly the same.

But internal consistency isn’t really an excuse for being inflexible, and clearly it would be very flexible if we could just fix up mistakes after they happen. So that’s not a really strong argument.

The real reason git doesn’t allow you to change the commit message ends up being very simple: that way, you can trust the messages. If you allowed people to change them afterwards, the messages are inherently not very trustworthy.