Accidentally pushed commit: change git commit message

Question

In my local repo I have one commit with an incorrect commit message.

I've already published the incorrect commit message with git push.

Now the remote repo (which is GitHub-hosted) has the incorrect commit message, too.

I've already tried git commit --amend, but found that it will not work for me in this situation because I've made additional commits since the incorrect one.

How would you fix this situation?

Solution 1

Easiest solution (but please read this whole answer before doing this):

1. git rebase -i <hash-of-commit-preceding-the-incorrect-one>
2. In the editor that opens, change pick to reword on the line for the incorrect commit.
3. Save the file and close the editor.
4. The editor will open again with the incorrect commit message. Fix it.
5. Save the file and close the editor.
6. git push --force to update GitHub.

This will mean you will be publishing a modified version of a previously published repository. If anyone pulled or fetched from your repo between when you made the mistake with the incorrect commit message, and when you fixed it, then they will experience some difficulties later. So be sure you can accept this consequence before trying this.

Solution 2

Rather than go the whole rebase route for one commit:

git reset --soft head~
git commit -m "The message you wanted to use"
git push -f

You can see the options in the git-reset manpage.

For a project that only you are working on, the changed history shouldn't be a problem.

Solution 3

If you have to change an old commit message over multiple branches (i.e., the commit with the erroneous message is present in multiple branches) you might want to use

git filter-branch -f --msg-filter 'sed "s/<old message>/<new message>/g"' -- --all

to replace the commit message.

Git will create a temporary directory for rewriting and additionally backup old references in refs/original/.

-f will enforce the execution of the operation. This is necessary if the the temporary directory is already present or if there are already references stored under refs/original. If that is not the case, you can drop this flag.

-- separates filter-branch options from revision options

--all will make sure, that all branches and tags are rewritten.

Due to the backup of your old references, you can easily go back to the state before executing the command.

Say, you want to recover your master and access it in branch old_master:

git checkout -b old_master refs/original/refs/heads/master

After you are satisfied with your changes use git push -f to push the changes to your public repo.

Note that you should inform your collaborators about this since all the hashes of the commits starting with the first modified one have been changed.

Solution 4

If you're not pushed the code to your remote branch(Github/Bitbucket) you can change the commit message on the command line as below.

 git commit --amend -m "Your new message"

If you're working on a specific branch do this.

git commit --amend -m "BRANCH-NAME: new message"

If you've already pushed the code with wrong message then you need to be careful when changing the message. i.e after you change the commit message and try pushing it again you end up with having issues. To make it smooth follow these steps. Please read the entire answer before doing it

git commit --amend -m "BRANCH-NAME : your new message"

git push -f origin BRANCH-NAME                # Not a best practice. Read below why?

Important note: When you use the force push directly you might end up with code issues that other developers are working on the same branch. So to avoid that conflicts you need to pull the code from your branch before making the force push

 git commit --amend -m "BRANCH-NAME : your new message"
 git pull origin BRANCH-NAME
 git push -f origin BRANCH-NAME

This is the best practice when changing the commit message, if it was already pushed.

View more solutions

Comments

[jonny]

since this is my home project this will be an ok solution. Thanks!

[Abizern]

I'd disagree that this is the easiest method.

[Dan Moulding]

Doing this will lose all of the commit information (but not the content) of commits that were done after the "screwed" commit. All of those subsequent commits will be lumped together in one big commit.

[Abizern]

Ah. Didn't see the extra info provided in the OP's comment.

[jonny]

However this is stll handy just for one commit.

[Jeff Ferland]

Mentioning it is touched by only you would make a huge difference in replies ;)

[Tao]

This answer is helpful as far as it goes, but is there any way to get more detail on "If anyone pulled or fetched from your repo between when you made the mistake with the screwed commit message, and when you fixed it, then they will experience some (minor) difficulties later"? I can't seem to find any descriptions of the issues and solutions, just warnings...

[Dan Moulding]

@Tao: See progit.org/book/ch3-6.html#the_perils_of_rebasing for an example of the issues. There are no simple generalizable solutions, hence the warnings.

[Tao]

@DanMoulding: Thanks, that really helps! At a high level, could I summarise this as "Anyone who had commits/branches that depended on your changes will need to rebase all those branches to avoid creating duplicate/redundant histories in later merges"?

[Dan Moulding]

@Tao: Yes. But I'd also add that rebasing those branches on the changed ones can sometimes be tricky because during the second rebase Git already has a duplicate/redundant history that it needs to sort out, which it doesn't always do correctly.

[Matt McClure]

Agreed. Not a good solution for the question at hand, but extremely useful when you immediately realize you need to adjust your last commit. One word of caution, when pushing with -f like this make sure you either explicitly reference the target branch or that you don't have other branches that will break what's upstream.

[gen_Eric]

A little tip, you can do git rebase -i <hash-of-commit>^. Note the ^ character.

[Dan Dascalescu]

When running git reset --soft head~, I get "fatal: ambiguous argument 'head~': unknown revision or path not in the working tree."

[Dan Dascalescu]

@RocketHazmat: there is no ^ character in the answer.

[Abizern]

That's probably because you're near a merge. Get the sha of the commit you want to reset to and try git reset --soft <sha> instead.

[harsimranb]

Would the consequences apply to the upstream branch, once I make a pull request?

[Abizern]

Reverting an edit. I work on a Mac which is not case sensitive about head/HEAD.

[Rezwan Azfar Haleem]

My noob status in dealing with VIM lead me to not solve my problem with this answer.

[Rezwan Azfar Haleem]

Worked perfectly for me since I was dealing with my last commit (with humiliating spelling errors)