Changing git commit message after push (given that no one pulled from remote)
Solution 1
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.
Solution 2
Just say:
git commit --amend -m "New commit message"
and then
git push --force
Solution 3
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.
Solution 4
Use these two steps in console:
git commit --amend -m "new commit message"
and then
git push -f
Done :)
Solution 5
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).
K_U
Updated on August 05, 2022Comments
-
K_U almost 2 years
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?
-
Andrew Marshall over 12 yearsBe 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).
-
user693960 about 11 yearsyou probably want to specify the branch name when you push --force, otherwise you may push more than you expected.
-
Dietrich Epp about 11 years@user693960: Git will only push what you configure it to push.
-
Dietrich Epp over 10 years@Leniel Macaferi: Using
-m
here doesn't let you edit the old message, it only lets you specify the new message. -
Leniel Maccaferri over 10 years@DietrichEpp yes... just experimenting with this right now. Thanks for the heads up! :)
-
Ustaman Sangat over 10 yearsAnd 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"?
-
ahnbizcad about 10 yearsSimply
git push --force
without <repository> and <branch> options works too, if you have your upstream set up. -
Andrew Wright over 8 yearsThis 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 -
Dietrich Epp over 8 years@AndrewWright: Are you saying that
git push --force <repository> <branch>
pushes to all branches? That's simply false. It only pushes to the branch you specify. -
Manish Shrivastava over 8 yearsIt should work @ahnbizcad, you might have some other
remote
name, well (y)!! -
SMBiggs over 7 yearsI 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. -
mfaani over 7 years@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)
-
Dietrich Epp over 7 years@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. -
peterh over 7 yearsVery important note.
-
pesho hristov over 7 yearsIt doesn't work because - as the
QUESTION
says - the commit is alreadyPUSHED
. Amend works for un-pushed commits. -
nurettin over 6 yearsnone 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.
-
Devner over 6 yearsFYI, 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.
-
xZero over 6 yearsThis 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!
-
henk about 6 yearsChoose n=3 for the last 3 commits:
git rebase -i HEAD~3
-
Michael Innes about 6 yearsAfter 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)` -
John almost 6 yearsI 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 stackoverflow.com/a/32267118/1423345 to "unprotect" the branch, and you can "protect" it again after done amending the commit message :)
-
Jim almost 6 yearsrob, this looks promising. can you show the commands needed to do an "errata commit". only this post shows up in google on these terms.
-
rob_7cc almost 6 yearsAn “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 almost 6 years...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.
-
Jim almost 6 yearsrob, 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!
-
MikeSchinkel almost 6 yearsCan you give an example of
<repository>
? Is itorigin
?org/repo
? Or justrepo
? -
Dietrich Epp almost 6 years@MikeSchinkel: It is the remote name, for example,
origin
. -
Jamie Birch over 5 yearsIf 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 defaultvi
tonano
), runGIT_EDITOR=nano git rebase -i HEAD~n
. -
Fr0zenFyr about 5 yearsIs 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 usedgit commit --amend
followed bygit push --force-with-lease origin my-branch
-
Gaurav Khare almost 5 yearsFor 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
-
rob_7cc almost 5 yearsI'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
-
Kip over 4 yearsI 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.
-
Notts90 supports Monica over 4 yearsI've made a suggested edit to put the useful comment from @JamieBirch into the answer, might want to review.
-
Adit choudhary over 4 yearsworks fine for me. 1. git commit --amend -m "New commit message" 2. git push --force remoteName branchName in my case remoteName is origin
-
brita_ almost 4 yearsIf the commit to be reworded is the very first one, use
git rebase -i --root
-
user3071284 about 3 yearsThis created additional commit with the corrected commit message.
-
joanis almost 3 yearsThat'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.
-
Yohanim over 2 yearsi'd love how simplicity this answer
-
Adam over 2 yearscomand
git push --force
remove all colleg commits, be careful with it. -
ogostos over 2 yearsadding this instructions for editing file in vim stackoverflow.com/a/45550363/6423716
-
Michael Felt over 2 yearsInteresting 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.
-
questionto42standswithUkraine about 2 years
git checkout main
-->git pull
-->git rebase -i [hash of the 5th last commit]
orgit 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 vimwq
--> 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 thengit push -f
? Is it now needed to force push when checked out in "main" to see the changed old commit message online? -
questionto42standswithUkraine about 2 years@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.