1515

I have made a git commit and subsequent push. I would like to change the commit message. If I understand correctly, this is not advisable because someone might have pulled from the remote repository before I make such changes. What if I know that no one has pulled?

Is there a way to do this?

k0pernikus
  • 60,309
  • 67
  • 216
  • 347
K_U
  • 15,832
  • 8
  • 26
  • 29
  • What have you tried? Assuming you know how to change the commit message already, and then try and push, Git will tell you what you need to do to make it happen. – Andrew Marshall Jan 24 '12 at 01:59
  • 2
    See answer to question "How do I edit an incorrect commit message in git (I've pushed)?" http://stackoverflow.com/a/457396/444639 – Rylander Mar 14 '13 at 15:08
  • 2
    https://help.github.com/articles/changing-a-commit-message/ – Mukesh May 17 '16 at 10:47
  • If you amend the HEAD commit and push usually (without --force) then surprisingly it does not fail. HEAD commit message is updated with the changed commit Id. It means other commit IDs except HEAD remains intact. I noticed this behavior with git 2.8.1 version. – irsis Sep 13 '17 at 09:00
  • Simple and easy for all commits, not only most recent: https://stackoverflow.com/a/5032614/7705712 – Edward D. Wilson Feb 25 '19 at 06:02
  • https://www.educative.io/edpresso/how-to-change-a-git-commit-message-after-a-push refer this. clearly explained. – pjk Nov 13 '20 at 11:18
  • For `rebase` solutions: if you want to **keep the original commit date** and prevent it from being overwritten, [use `--committer-date-is-author-date` when you rebase](https://stackoverflow.com/questions/2973996/git-rebase-without-changing-commit-timestamps/2976598#2976598) – ᴍᴇʜᴏᴠ Nov 07 '22 at 18:03

20 Answers20

1887

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.

Community
  • 1
  • 1
Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • 18
    Be careful with that "fix", as if they have any local, unpushed commits they will be "lost" (*lost* truly meaning *orphaned*, but recovering them is non-obvious). – Andrew Marshall Jan 24 '12 at 02:07
  • 2
    you probably want to specify the branch name when you push --force, otherwise you may push more than you expected. – user693960 Mar 12 '13 at 00:25
  • 1
    @user693960: Git will only push what you configure it to push. – Dietrich Epp Mar 12 '13 at 02:37
  • @Leniel Macaferi: Using `-m` here doesn't let you edit the old message, it only lets you specify the new message. – Dietrich Epp Oct 29 '13 at 00:38
  • @DietrichEpp yes... just experimenting with this right now. Thanks for the heads up! :) – Leniel Maccaferri Oct 29 '13 at 00:43
  • And if I were to commit the penultimate commit? Could I do "git rebase HEAD^^ -i" and then edit the first commit and then "git push HEAD^^ --force"? – Ustaman Sangat Oct 29 '13 at 03:44
  • 15
    Simply `git push --force` without and options works too, if you have your upstream set up. – ahnbizcad Apr 29 '14 at 09:16
  • This answer should really include @SteveBenner 's note that it pushes ALL branches, and you should use `git push --force origin +master` (or whatever your branch name is) or you risk deleting data on other branches that you may have but aren't in sync – Andrew Wright Feb 10 '16 at 19:48
  • @AndrewWright: Are you saying that `git push --force ` pushes to all branches? That's simply false. It only pushes to the branch you specify. – Dietrich Epp Feb 10 '16 at 20:26
  • 1
    I simply used `git push --force-with-lease` as the repositories and branches I am currently using are the defaults. Should work with most people in this situation. – SMBiggs Sep 27 '16 at 22:23
  • @why isn't your answer as simple as Manish's or is it because of the possibility of someone else modified the same branch and we need to take a safe approach?(Though re-re-reading it now I realize my downvote was unnecessary. sorry) – mfaani Dec 21 '16 at 21:28
  • @Honey: You have to be careful when you use `--force`, ideally you understand what data is getting overwritten / destroyed when you use it. A force push also has some consequences if (unlike the OP) someone has already pulled. – Dietrich Epp Dec 21 '16 at 21:38
  • 12
    Can you give an example of ``? Is it `origin`? `org/repo`? Or just `repo`? – MikeSchinkel Aug 30 '18 at 03:49
  • 3
    @MikeSchinkel: It is the remote name, for example, `origin`. – Dietrich Epp Aug 30 '18 at 04:07
  • Is it normal that commit log on my **_gitlab server_** shows both commits (and I can open old/new commits and see the changed files and old/new commit messages respectively on each)? Though my local `git log` doesn't show the old commit (with incorrect message), just the way I'd expected! I had used `git commit --amend` followed by `git push --force-with-lease origin my-branch` – Fr0zenFyr May 14 '19 at 11:52
  • comand `git push --force` remove all colleg commits, be careful with it. – Adam Oct 13 '21 at 15:49
  • @Adam I found out what was the problem in my case. My branch was already merged. That is why I could not and should not change anything in the past anymore. I therefore put the non-truncated commit message to the documentation and leave it as it is. – questionto42 Apr 07 '22 at 16:27
743

Just say:

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

and then

git push --force
Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Manish Shrivastava
  • 30,617
  • 13
  • 97
  • 101
  • 8
    It doesn't work because - as the `QUESTION` says - the commit is already `PUSHED`. Amend works for un-pushed commits. – pesho hristov Feb 08 '17 at 09:32
  • FYI, if we need to change the commit message of an already pushed commit, we can do it as per the solution provided by @ManishShrivastava. But please do note that it will create a new Commit ID, for each commit amended. So for example, if the commit is amended 3 times and pushed 3 times, 3 different commit IDs will be generated. – Devner Nov 01 '17 at 17:41
  • 1
    After trying this, I get this error: `remote: To prevent you from losing history, non-fast-forward updates were rejected.` `remote: Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note` `remote: about fast-forwards' section of 'git push --help' for details.` ` [remote rejected] master -> master (pre-receive hook declined)` – Michael Innes May 08 '18 at 00:23
  • 6
    I successfully applied these command only after temporarily "unprotect" my branch, which happened on my GitLab-hosted project. If you have this issue, before applying these commands, please refer to this https://stackoverflow.com/a/32267118/1423345 to "unprotect" the branch, and you can "protect" it again after done amending the commit message :) – Dan Jul 03 '18 at 14:33
  • For some reason in my case change got pushed to three branches including the intended one. Thankfully my change was small so I could get over it other otherwise it would have been a nightmare for me. Bottomline - Think thousand times before doing git push --force – Gaurav Khare Jun 06 '19 at 13:15
  • 3
    works fine for me. 1. git commit --amend -m "New commit message" 2. git push --force remoteName branchName in my case remoteName is origin – Adit choudhary Jan 29 '20 at 10:20
  • i'd love how simplicity this answer – Yohanim Oct 04 '21 at 10:24
  • After typing the above answer and you find yourself in VIM, you can type 'i' to enter insert mode and after you're done, press ESC and them ':wq' to save and exit. Goodluck! – aghwotu Oct 05 '22 at 22:46
  • 2
    worked fine for me – Denise Ignatova Nov 10 '22 at 10:05
588

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.

Notts90
  • 254
  • 2
  • 20
Jinsong Li
  • 6,347
  • 1
  • 23
  • 20
  • 83
    This should be accepted answer as it gives possibility to change other commits than most recent commit, unlike accepted answer. You saved my day. Thank you! – xZero Dec 03 '17 at 17:10
  • 6
    Choose n=3 for the last 3 commits: `git rebase -i HEAD~3` – henk Mar 08 '18 at 15:10
  • 1
    If you edit your rebase 'plan' yet it doesn't begin the process of letting you rename the files, run `git rebase --continue`. And 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`. – Jamie Birch Nov 20 '18 at 16:39
  • 4
    I edited this to add a little more info. Please take a look. This was the answer for what I wanted to do, but I scrolled by it because it didn't have the header. – Kip Oct 09 '19 at 19:56
  • I've made a suggested edit to put the useful comment from @JamieBirch into the answer, might want to review. – Notts90 Nov 25 '19 at 16:32
  • If the commit to be reworded is the very first one, use `git rebase -i --root` – brita_ Aug 22 '20 at 10:17
  • 4
    This created additional commit with the corrected commit message. – user3071284 Mar 09 '21 at 18:36
  • adding this instructions for editing file in vim https://stackoverflow.com/a/45550363/6423716 – ogostos Feb 04 '22 at 15:34
  • 1
    `git checkout main` --> `git pull` --> `git rebase -i [hash of the 5th last commit]` or `git rebase HEAD~4` both show the last 4 commits in the interactive editor --> change first line (4th last commit) from "pick" to "reword" --> in vim: `wq` --> edit the commit message --> in vim `wq` --> I get back to the main branch. Now, I do not see the changed commit message online, but when I rebase again, the changes are done. Being in "main" again, should I then `git push -f`? Is it now needed to force push when checked out in "main" to see the changed old commit message online? – questionto42 Apr 06 '22 at 19:01
  • Thank you for the step by step. I can't push on step 4 from phpstorm terminal : it says in french `"fatal: Vous n'êtes actuellement sur aucune branche. Pour pousser l'historique menant à l'état actuel (HEAD détachée)"` This means I'm not on a branch, and it tells me to push current state with a full `git push origin HEAD:` – Nicolas Thery Sep 13 '22 at 06:50
  • For step 4, I actually had to do: `git push --force ` – Sahil Jain Oct 06 '22 at 15:51
80

Use these two steps in console:

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

and then

git push -f

Done :)

nCardot
  • 5,992
  • 6
  • 47
  • 83
Abdul Rizwan
  • 3,904
  • 32
  • 31
22

It should be noted that if you use push --force with mutiple refs, they will ALL be modified as a result. Make sure to pay attention to where your git repo is configured to push to. Fortunately there is a way to safeguard the process slightly, by specifying a single branch to update. Read from the git man pages:

Note that --force applies to all the refs that are pushed, hence using it with push.default set to matching or with multiple push destinations configured with remote.*.push may overwrite refs other than the current branch (including local refs that are strictly behind their remote counterpart). To force a push to only one branch, use a + in front of the refspec to push (e.g git push origin +master to force a push to the master branch).

Steve Benner
  • 1,679
  • 22
  • 26
  • 3
    *Very* important note. – peterh Jan 19 '17 at 16:14
  • none of the force answers work for me, because I don't have ForcePush permissions on the server. Instead, I want to perform a commit which changes a previous commit message. I could write "commit message changed" to that commit's comment section. – nurettin Sep 12 '17 at 06:20
16

Command 1.

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

Then,

Command 2.

git push origin --force
pRaNaY
  • 24,642
  • 24
  • 96
  • 146
Teo Choong Ping
  • 12,512
  • 18
  • 64
  • 91
15
git commit --amend

then edit and change the message in the current window. After that do

git push --force-with-lease
Beu
  • 1,370
  • 10
  • 23
14

To make sure you are making changes on the right branch

git checkout 

#to make sure you are making changes on the right branch just to be sure:

git checkout branchname

Then

git commit --amend -m "new message"

Then push

git push --force
Denzel Akwany
  • 137
  • 1
  • 3
11

If you want to modify an older commit, not the last one, you will need to use rebase command as explained in here,Github help page , on the Amending the message of older or multiple commit messages section

Carlos
  • 480
  • 1
  • 5
  • 10
10

Case 1 : Not pushed + most recent commit: Refer this

Case 2 : Already pushed + most recent commit: Refer this

Case 3 : Not pushed + old commit: Refer this

Case 4 : Already pushed + old commit: Refer this

Jay Teli
  • 530
  • 1
  • 11
  • 19
9

Simply use this 2 commands to change the commit message of your last push

  1. -$ git commit --amend -m "New commit message."
  2. -$ git push --force-with-lease
rNkL
  • 376
  • 3
  • 11
7

Another option is to create an additional "errata commit" (and push) which references the commit object that contains the error -- the new errata commit also provides the correction. An errata commit is a commit with no substantive code changes but an important commit message -- for example, add one space character to your readme file and commit that change with the important commit message, or use the git option --allow-empty. It's certainly easier and safer than rebasing, it doesn't modify true history, and it keeps the branch tree clean (using amend is also a good choice if you are correcting the most recent commit, but an errata commit may be a good choice for older commits). This type of thing so rarely happens that simply documenting the mistake is good enough. In the future, if you need to search through a git log for a feature keyword, the original (erroneous) commit may not appear because the wrong keyword was used in that original commit (the original typo) -- however, the keyword will appear in the errata commit which will then point you to the original commit that had the typo. Here's an example:

$ git log
commit 0c28141c68adae276840f17ccd4766542c33cf1d
Author: First Last 
Date:   Wed Aug 8 15:55:52 2018 -0600

    Errata commit:
    This commit has no substantive code change.
    This commit is provided only to document a correction to a previous commit message.
    This pertains to commit object e083a7abd8deb5776cb304fa13731a4182a24be1
    Original incorrect commit message:
        Changed background color to red
    Correction (*change highlighted*):
        Changed background color to *blue*

commit 032d0ff0601bff79bdef3c6f0a02ebfa061c4ad4
Author: First Last 
Date:   Wed Aug 8 15:43:16 2018 -0600

    Some interim commit message

commit e083a7abd8deb5776cb304fa13731a4182a24be1
Author: First Last 
Date:   Wed Aug 8 13:31:32 2018 -0600

    Changed background color to red
rob_7cc
  • 797
  • 6
  • 16
  • rob, this looks promising. can you show the commands needed to do an "errata commit". only this post shows up in google on these terms. – Jim Aug 10 '18 at 13:05
  • 1
    An “errata commit” is simply a normal commit with a message that references the previous erroneous commit, documenting and providing a correction for the previous mistake. `git commit -m “fixed feature A”` (Let’s assume git gives this a commit ID of e3ab7312... ... (later you realize your message was incorrect so now make an inconsequential change to a file like adding a space to the readme file, or use the `—allow-empty` git option) ... `git commit -m “Errata commit for previous commit e3ab7312... original message should have been ‘fixed feature *B*’` ‘’’ – rob_7cc Aug 11 '18 at 22:58
  • 2
    ...if you later need to search the git log for references to “feature B”, the errata commit will show up, but the errata commit message contains a reference to the original commit ID which provides full traceability. BTW the term “errata commit” is nothing special (there is no “errata” command nor option in git)...it is just my terminology for a normal commit that provides a correction to a previous commit that had an error/typo. – rob_7cc Aug 11 '18 at 23:02
  • 1
    rob, that worked great. I was able to add a new empty commit with the correct description, that points to the original commit, by using the SHA. now, both are shown in my 'git chain' for the modules. thanks! – Jim Aug 13 '18 at 12:48
  • I'm glad that worked for you. I use the same technique to correct mistakes in commit messages. As an alternative, I just recently discovered `git notes` This would serve the same purpose as an "errata commit". Simply add a note to a previous commit to annotate or correct any errors in the commit message: `https://git-scm.com/docs/git-notes` – rob_7cc Aug 29 '19 at 17:17
  • Good idea for not rewriting established history. – qwr Aug 06 '22 at 08:13
4
  • Command 1

    You need to change your commit message use the Below command

    git commit --amend -m "New and correct message"
    
  • Command 2

    After the add a new message and then below command execute

    git push -f origin <your_branch_name>
    
Syscall
  • 19,327
  • 10
  • 37
  • 52
3

Event if you commit worng message with -S parameter following would work:

 git checkout branch

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

at this point do not forget that you added a change and your remote is different, this why you need to do:

 git push --force

If you are in VSCode you will see the difference, with --force parameter you ignore git pull and you push your changed message to the same commit.

Denise Ignatova
  • 465
  • 4
  • 7
3

FWIW in the simplest case, the checked answer is correct. I just wanted to share a recent experience.

This worked.

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

git push --force origin

And the tester was able to checkout the branch for the first time and has only the amended message.

So in the simplest case (single developer and/or known that no one has fetch/pulled or checked out the branch) that is sufficient.

evernoob
  • 103
  • 7
2

I'm a little bit new to Git, but I just wanna add my experience.

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

This worked great but the next was the problem for me. I already pushed the commit before changing the commit message. Finally, when I tried to push to the remote, it git threw an exception. So I should have pull down again before updating the remote branch.

git pull origin branch-name

git push origin branch-name

Hope my minor experience helps you. Thanks.

unicorn
  • 111
  • 1
  • 3
  • That's not a great solution, because now you're going to have that commit twice, once with the old message, once with the corrected message, merged together. – joanis Jun 14 '21 at 19:42
1
git commit --amend

edit commit message with type keyboard

git push --force
Anupam Maurya
  • 1,927
  • 22
  • 26
0

This works for me pretty fine,

git checkout origin/branchname

if you're already in branch then it's better to do pull or rebase

git pull

or

git -c core.quotepath=false fetch origin --progress --prune

Later you can simply use

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

or if you like to open text-editor then use

git commit --amend

I will prefer using text-editor if you have many comments. You can set your preferred text-editor with command

git config --global core.editor your_preffered_editor_here

Anyway, when your are done changing the commit message, save it and exit

and then run

git push --force

And you're done

Hasasn
  • 810
  • 8
  • 9
  • Interesting idea to modify a configuration setting - but what am I actually changing, and why are you recommending it? Without that, yours is merely an answer given years later. – Michael Felt Feb 24 '22 at 10:50
0

additional information for same problem if you are using bitbucket pipeline

edit your message

git commit --amend

push to the sever

git push --force <repository> <branch>

then add --force to your push command on the pipeline

git ftp push --force

This will delete your previous commit(s) and push your current one.

remove the --force after first push

i tried it on bitbucket pipeline and its working fine

0

I did my first attempt at renaming about 6 old commit messages that were already pushed and I had since done further commits.

So it's the nastiest case 'Case 4 : Already pushed + old commit'.

I'm a Vim (Nvim now) user and a mega fan of Vim's Fugitive. So this is how I did it with that.

This is the general help that you have around rebasing in Fugitive:

Rebase maps ~

ri                      Perform an interactive rebase.  Uses ancestor of
u                       commit under cursor as upstream if available.

rf                      Perform an autosquash rebase without editing the todo
                        list.  Uses ancestor of commit under cursor as
                        upstream if available.

ru                      Perform an interactive rebase against @{upstream}.

rp                      Perform an interactive rebase against @{push}.

rr                      Continue the current rebase.

rs                      Skip the current commit and continue the current
                        rebase.

ra                      Abort the current rebase.

re                      Edit the current rebase todo list.

rw                      Perform an interactive rebase with the commit under
                        the cursor set to `reword`.

rm                      Perform an interactive rebase with the commit under
                        the cursor set to `edit`.

rd                      Perform an interactive rebase with the commit under
                        the cursor set to `drop`.

r<Space>                Populate command line with ":Git rebase ".

r?                      Show this help.

  1. Get a list of commits.

    :Git log --oneline enter image description here

  2. I want to fix the commit message on line 12 (4d43a1b build(MPL-402): editorconfig fix for messges.json), because its not in the proper Conventional Commit format.

  3. I put my cursor over the commit hash 4d43a1b and type rw

    This will "Perform an interactive rebase with the commit under the cursor set to reword.". Note how nice this is compared to git rebase -i HEAD~X - knowing what that X is is not so simple. enter image description here

  4. This should now give you the correct git rebase command. So write and quit that buffer with :wq

  5. Then follow the steps through as git/fugitive guides you. I got a merge conflict for one of my commits which I fixed through my normal fugitve merge conflict process.

Hopefully that's enough to get you over the first "I've never done a rebase before, what the hell am I supposed to do?" hurdle. Leave me a comment if you want help with the later steps.

icc97
  • 11,395
  • 8
  • 76
  • 90