Changing git commit message after push (given that no one pulled from remote)

To edit a commit other than the most recent:

Step1: git rebase -i HEAD~n to do interactive rebase for the last n commits affected. (i.e. if you want to change a commit message 3 commits back, do git rebase -i HEAD~3)

git will pop up an editor to handle those commits, notice this command:

#  r, reword = use commit, but edit the commit message

that is exactly we need!

Step2: Change pick to r for those commits that you want to update the message. Don't bother changing the commit message here, it will be ignored. You'll do that on the next step. Save and close the editor.

Note that if you edit your rebase 'plan' yet it doesn't begin the process of letting you rename the files, run:

git rebase --continue

If you want to change the text editor used for the interactive session (e.g. from the default vi to nano), run:

GIT_EDITOR=nano git rebase -i HEAD~n

Step3: Git will pop up another editor for every revision you put r before. Update the commit msg as you like, then save and close the editor.

Step4: After all commits msgs are updated. you might want to do git push -f to update the remote.

Changing history

If it is the most recent commit, you can simply do this:

git commit --amend

This brings up the editor with the last commit message and lets you edit the message. (You can use -m if you want to wipe out the old message and use a new one.)

Pushing

And then when you push, do this:

git push --force-with-lease <repository> <branch>

Or you can use "+":

git push <repository> +<branch>

Or you can use --force:

git push --force <repository> <branch>

Be careful when using these commands.

• If someone else pushed changes to the same branch, you probably want to avoid destroying those changes. The --force-with-lease option is the safest, because it will abort if there are any upstream changes (

• If you don't specify the branch explicitly, Git will use the default push settings. If your default push setting is "matching", then you may destroy changes on several branches at the same time.

Pulling / fetching afterwards

Anyone who already pulled will now get an error message, and they will need to update (assuming they aren't making any changes themselves) by doing something like this:

git fetch origin
git reset --hard origin/master # Loses local commits

Be careful when using reset --hard. If you have changes to the branch, those changes will be destroyed.

A note about modifying history

The destroyed data is really just the old commit message, but --force doesn't know that, and will happily delete other data too. So think of --force as "I want to destroy data, and I know for sure what data is being destroyed." But when the destroyed data is committed, you can often recover old commits from the reflog—the data is actually orphaned instead of destroyed (although orphaned commits are periodically deleted).

If you don't think you're destroying data, then stay away from --force... bad things might happen.

This is why --force-with-lease is somewhat safer.

Use these two steps in console:

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

and then

git push -f

Done :)

Just say:

git commit --amend -m "New commit message"

and then

git push --force