I want to change the Git commit message for the previous commit

Question

I want to change a previous pushed commit message. Also, I have pushed other commits after that. If I change the commit message will older message be shown in Git commit history.

Answer 1

git checkout revision-to-correct
git commit --amend -m "corrected message"

Revisions that "were" on top if it, you can cherry-pick them and then move the original branches to the new location... then you could push --force:

git cherry-pick revision-to-correct..some-branch
git branch -f some-branch
git push origin --force some-branch

Update: After having learned a few more tricks, there is another very simple way:

git rebase -i HEAD~2
# rebase will open a list of revisions, on the first line, change pick for reword (or r, for short)
# save and exit.... git rebase will start running
# and it will stop right after the second to last revision is applied
# and you will be on the editor so that you can modify the message for the revision
# set the message, save and exit
# git rebase will finish running and you are done

Answer 2

So you have one answer that tells you how you would do it if the commit weren't pushed (ignoring that you specifically said it has been pushed). And you have a couple answers giving you procedures that you'll think worked great, until your coworkers start complaining. But nobody seems to want to tell you the real score.

The commit message is a fundamental part of the commit identity. That is why, in Edmundo's procedure, you end up having to do a bunch of nonsense cherry-picking and forced operations. (If you have the use the -f or --force options, then git is trying to warn you of something.)

So to clarify:

There is no mechanism for editing the message of a commit. You can replace a commit with a new commit that is identical except for having a new message, but if in doing so you remove a commit that has been pushed, every other user of the repo will have to recover because you have just performed an effective upstream rebase. (See "recovering from upstream rebase" in the git rebase documentation.)

This doesn't mean you can never do it; it means that you should have the agreement of everyone who uses the branch in question before you do it.

And in the case you specify - where not only the commit to be modified but also some subsequent commits have been pushed - those commits are going to need to be replaced as well. And every ref that points at any one of them will have to be rewritten. For example, if you have

x --- x --- A --- B --- C --- D <--(master)
                   \
                    E --- F <--(branch1)

and you want to rewrite the commit message for A. So you follow Edmundo's advice (which is, after all, closer to correct than anyone else's). You check out A and run the commit --amend, and now you have

x --- x --- A --- B --- C --- D <--(master)
       \           \
        \           E --- F <--(branch1)
         A'

Notice that your branches still "see" the original commit (with the original message) in their histories, which is why Edmundo says you'll then be doing some cherry-picking. Now if you really want to do this, cherry-picking is actually the hard way; you'd be better off at this point re-parenting B from A to A' using filter-branch.

Of course re-parenting is still history rewriting, so now what you get is

x --- x --- A --- B --- C --- D <--(origin/master)
       \           \
        \           E --- F <--(origin/branch1)
         \
          A' --- B' --- C' --- D' <--(master)
                  \
                   E' --- F' <--(branch1)

To fix that, you'll have to force-push both master and branch1. As soon as you do that, any work anyone else has added after D or F (either on the respective branch, or on a new branch) will have to be rebased onto your work as well.

If you haven't carefully coordinated with your coworkers, they'll find out about needing to rebase their work through a somewhat cryptic error message, and if they react to that the "wrong" way -- i.e. the way that causes them the last headache -- i.e. force push because it clears the error, just like you did -- then the history will once again have the original A with the original commit message you wanted to do away with.

So, if this somehow still sounds worth the trouble, the correct procedure is

1) Coordinate a cut-over with all other users of the repo 2) Follow a procedure similar to Edmundo's, but probably with the modifications I've suggested above

You might want to look at whether a different solution - like notes or annotated tags - would meet your needs instead.

Answer 3

To change the commit message when cherry-picking, use “git cherry-pick” with the “-e” option.

$ git cherry-pick -e <hash>

As illustrated in this example, your default editor will open and it will let you change the commit message.

When you are satisfied with the edits, save your file and your commit message should be saved successfully.