How to modify existing, unpushed commit messages?
Solution 1
Amending the most recent commit message
git commit --amend
will open your editor, allowing you to change the commit message of the most recent commit. Additionally, you can set the commit message directly in the command line with:
git commit --amend -m "New commit message"
…however, this can make multi-line commit messages or small corrections more cumbersome to enter.
Make sure you don't have any working copy changes staged before doing this or they will get committed too. (Unstaged changes will not get committed.)
Changing the message of a commit that you've already pushed to your remote branch
If you've already pushed your commit up to your remote branch, then - after amending your commit locally (as described above) - you'll also need to force push the commit with:
git push <remote> <branch> --force
# Or
git push <remote> <branch> -f
Warning: force-pushing will overwrite the remote branch with the state of your local one. If there are commits on the remote branch that you don't have in your local branch, you will lose those commits.
Warning: be cautious about amending commits that you have already shared with other people. Amending commits essentially rewrites them to have different SHA IDs, which poses a problem if other people have copies of the old commit that you've rewritten. Anyone who has a copy of the old commit will need to synchronize their work with your newly re-written commit, which can sometimes be difficult, so make sure you coordinate with others when attempting to rewrite shared commit history, or just avoid rewriting shared commits altogether.
Perform an interactive rebase
Another option is to use interactive rebase. This allows you to edit any message you want to update even if it's not the latest message.
In order to do a Git squash, follow these steps:
// n is the number of commits up to the last commit you want to be able to edit
git rebase -i HEAD~n
Once you squash your commits - choose the e/r
for editing the message:
Important note about interactive rebase
When you use git rebase -i HEAD~n
there can be more than n commits. Git will "collect" all the commits in the last n commits, and if there was a merge somewhere in between that range you will see all the commits as well, so the outcome will be n + .
Good tip:
If you have to do it for more than a single branch and you might face conflicts when amending the content, set up git rerere
and let Git resolve those conflicts automatically for you.
Documentation
Solution 2
git commit --amend -m "your new message"
Solution 3
If the commit you want to fix isn’t the most recent one:
-
git rebase --interactive $parent_of_flawed_commit
If you want to fix several flawed commits, pass the parent of the oldest one of them.
-
An editor will come up, with a list of all commits since the one you gave.
- Change
pick
toreword
(or on old versions of Git, toedit
) in front of any commits you want to fix. - Once you save, Git will replay the listed commits.
- Change
-
For each commit you want to reword, Git will drop you back into your editor. For each commit you want to edit, Git drops you into the shell. If you’re in the shell:
- Change the commit in any way you like.
git commit --amend
git rebase --continue
Most of this sequence will be explained to you by the output of the various commands as you go. It’s very easy; you don’t need to memorise it – just remember that git rebase --interactive
lets you correct commits no matter how long ago they were.
Note that you will not want to change commits that you have already pushed. Or maybe you do, but in that case you will have to take great care to communicate with everyone who may have pulled your commits and done work on top of them. How do I recover/resynchronise after someone pushes a rebase or a reset to a published branch?
Solution 4
To amend the previous commit, make the changes you want and stage those changes, and then run
git commit --amend
This will open a file in your text editor representing your new commit message. It starts out populated with the text from your old commit message. Change the commit message as you want, then save the file and quit your editor to finish.
To amend the previous commit and keep the same log message, run
git commit --amend -C HEAD
To fix the previous commit by removing it entirely, run
git reset --hard HEAD^
If you want to edit more than one commit message, run
git rebase -i HEAD~commit_count
(Replace commit_count with number of commits that you want to edit.) This command launches your editor. Mark the first commit (the one that you want to change) as “edit” instead of “pick”, then save and exit your editor. Make the change you want to commit and then run
git commit --amend
git rebase --continue
Note: You can also "Make the change you want" from the editor opened by git commit --amend
Solution 5
As already mentioned, git commit --amend
is the way to overwrite the last commit. One note: if you would like to also overwrite the files, the command would be
git commit -a --amend -m "My new commit message"
Laurie Young
PhD in Grid computing, and agile web developer working in London
Updated on July 20, 2022Comments
-
Laurie Young almost 2 years
I wrote the wrong thing in a commit message.
How can I change the message? The commit has not been pushed yet.
-
Pat Notz over 15 yearsFor those somewhat new to git: Laurie's point about having not yet pushed is important. Like rebasing, this is changing the history. If someone has cloned/pulled from your repo between the original and rewritten history then they won't be able to pull after the rewrite (for that branch).
-
-
13ren over 14 yearsCan one change the message of the first commit (which doesn't have a parent)?
-
MitMaro almost 14 yearsThis is mentioned in one of the other answers but I will put a note of it here. Since git 1.6.6 you can use
reword
in place ofpick
to edit the log message. -
Jeffrey Jose almost 14 yearsHowever
git commit --amend
isnt as powerful asgit rebase -i
. -
strager almost 14 years@jeffjose, It definitely doesn't need to be. Also,
git commit --amend
can fix up the (a?) master commit. -
Avisra over 13 yearsIncidentally,
$parent_of_flawed_commit
is equivalent to$flawed_commit^
. -
Daniel Rinser almost 13 yearsNever EVER do this (or rebase in general) if you have already pushed upstream!
-
Dave Everitt over 12 yearsI did git commit --amend -m "New message", but pushing to Github generated the "Merge the remote changes before pushing again". After pull, commit --amend, and push again, the new message doesn't appear. Instead I have "Merge branch 'master' of github.com:[myrepo]"
-
ahven about 12 yearsUse
-p
(--preserve-merges
) if there was a merge after the flawed commit. -
hughes almost 12 yearsIf you've already pushed, just force push again:
git push -f origin branchname
-
Nick over 11 yearsAlso,
$parent_of_flawed_commit
means "commit before the one you screwed up" :) -
Armand over 11 years@hughes isn't
git push -f
a bit dangerous if other people are using the same repository? -
Sam over 11 yearsIf you don't want to rewrite the entire commit message, go for
git commit --amend -c HEAD
. This will open the editor pre-populated with your old commit message, so you can change it. -
floer_m over 11 yearsWhat @Sam says also seems to work if you just type
git commit --amend
with nothing else following. -
Steve Tauber about 11 yearsIf you want to make sure your change from
git commit --amend
took affect you can usegit show
and it will show the new message. -
sjakubowski about 11 yearsIs there a version of this that does not change the commit if the regex doesn't find anything?
-
Mark about 11 yearsAFAIK filter-branch --msg-filter will generate new commits in any case. However, you could check within the msg-filter, if the sed succeeded and use this information when the filter-branch operation ends to reset your tree to refs/original.
-
Jan about 11 yearsFor me, using your command above actually creates a new commit with a new commit ID plus an extra commit saying "merge branch" as a default commit message.
-
matbrgz about 11 years@DaveEveritt you most likely pushed your commit upstream before trying to fix it.
-
Dave Everitt about 11 years@ThorbjørnRavnAndersen - thanks, that was 2 years ago, these days I've got my git workflow sorted!
-
Wowbagger and his liquid lunch almost 11 years@hughes Don't force push to repositories that other people are using without warning them first!! Otherwise it results in a bizarre conflict when they try to fetch again. If that person doesn't know what he/she is doing, they might resolve the conflict incorrectly and then push that, which would screw up the repository even further.
-
stackunderflow almost 11 yearsIs there a good way to fix commit messages already pushed to a public repository? So far I have come to the conclusion that, once pushed, my commit message typos and thinkos have to live forever.
-
hobs almost 11 years@Kyralessa not true. In bash you can easily compose multiline commit messages by just not closing the quote until you're done (hitting return at the end of each line within the quotes).
-
Emil Lundberg almost 11 yearsAmending always creates a new commit with a new commit ID. The commit ID is the SHA hash of the contents of the commit, including the commit message and authored/committed timestamps. This is a feature of Git that, barring hash collisions, ensures that two commits with the same ID are exactly the same commit, with exactly the same content, history and so on.
-
Zhenny almost 11 years@guillegr123, no, the proper terminology is, or at least used to be, the "tip" of the branch.
-
kbro almost 11 yearsThis answer doesn't address the OP's question, as they're purely interested in fixing a commit they've only just done. I regularly use
git commit --amend
to fix up comments or add files I forgot togit add
, but only ever before I'vegit push
ed. I also usegit filter-branch
when I want to totally mess with the version history, but the OP doesn't want this, so this answer needs a big health warning - don't try this at home, peeps!! -
kbro almost 11 yearsIn a word, NOPE! There is no GOOD way to retract something you have pushed. All retractions are BAD to a greater or lesser degree. You need to adopt the discipline of working in a branch in your own private repository, doing multiple commits as you add a bit, test a bit, tweak a bit. Then merge your entire branch into a single commit, write a new commit message describing the overall change, PROOFREAD it, and push.
-
Mark almost 11 years@DavidHogue This is only true when using the filter-branch method. The commit IDs following a modified commit do not change if you use the interactive rebase.
-
txulu over 10 yearsJust a little detail. If you do
git commit --amend
while there are staged changes (added withgit add
) they will become part of the amended commit. This is useful to add changes or deletes you forgot to stage (usually I forgot the -A option in thegit add
command when I'm deleting files) -
Joe over 10 years
git rebase -i HEAD~commit_count
will also allow you to change the commit messages of however many commits you choose. Just mark the chosen commits as "reword" instead of "pick". -
ShawnFumo over 10 yearsJust to point out the obvious that one doesn't have to make a single commit when going back from a feature branch. What many people do is rebase on the target branch (to make things look clean) then merge with the option to suppress fast-forwarding. Agree with the main point of being careful before you push up though.
-
Sam over 10 yearsa great answer! and covers the important point of merges which
rebase -i
wont let you do by default. To use rebase to change the message of a merge commit you must use the preserve option-p
-
Gal over 10 yearsAgree with Emil. Additionally, reading the docs - it seems that all "-c" does is tell git which commit's message to use as the default/template for your new commit..Really its already going to do "-c <commit ID>" by default, so no need to specify it.
-
trusktr over 10 years@AristotlePagaltzis I'm the only one pushing commits to a remote repository. Can I
git push -f
to pushreword
s for commits that have already pushed? -
Miles Rout over 10 years@Mark Yes they do, they are required to. Commit ids are dependent on previous commits. If they didn't change, git would be useless.
-
happy coder over 10 yearsI don't get how an answer that looks a lot like just the main idea of an answer that was written two years ago and also the accepted answer gets so many votes. Strange. (nothing wrong with the answer though)
-
Amal Murali almost 10 years@happycoder: Because the question is very popular and the first hit on Google (and many other search engines) for many git-related terms. And people find it useful.
-
happy coder almost 10 years@AmalMurali, well. My point wasn't so much about the popularity of the question, nor the utility of the answer. But this particular answer is not the oldest answer, nor does it offer any further insight into the accepted answer. It appears to be a copy of a section of the accepted answer. That was my point. CHEERS!
-
Jimmy Bosse almost 10 yearsThis worked really well for me in a Git-SVN workflow where one git commit message in a batch of changes was rejected by an SVN pre-commit hook. I was able to reword and then the dcommit worked.
-
David Ongaro almost 10 yearsThe "top" answer doesn't answer the question. It just gives a general introduction to
git commit --amend
. The question was very specific, therefore longer != better. The decisive mentioning of the-o
flag would probably be buried in the rest of the information. I'm also not comfortable editing an answer which has so many votes already. -
David Ongaro almost 10 yearsThat being said you're free to edit the top answer, since there is a real danger that people are using that as the "correct" answer. It can easily happen to amend your commit with staged stuff -- it happened to me, and it's really annoying when you happen to push that. But still, quantity is no guarantee for correctness. Neither in number of answers nor in number of votes.
-
Admin almost 10 yearsI wouldn't go so far to say that the top answer is "incorrect" and that it "doesn't answer the question". It definitely works and answers the question, you just need to make sure that you don't have staged changes when you try to amend. But I see your point about having to warn people about that. I'll edit it in later if I have time.
-
David Ongaro almost 10 yearsTo be fair: even though the
--only
option with--amend
is available since git 1.3.0 it didn't work correctly till it was fixed in 1.7.11.3 (ea2d4ed35902ce15959965ab86d80527731a177c). So the right answer back in 2008 would probably have been something like:git stash; git commit --amend; git stash pop
. -
Admin almost 10 yearsIf all you want to do is to edit the message of your last commit, using a soft reset for that purpose is over-kill. Just use
git commit --amend
, exactly like how it says in the top voted answer. Additionally,git reset --soft HEAD^
works identically to the soft reset in this earlier answer, because they both reset back to the first parent commit. -
przbadu almost 10 yearsI only bother to add
git reset
in the solution just to give an idea to split one commit message into multiple commit messages. Because, I have faced that problem when, I was starting to usegit
. Sometimes, this can be really helpfull. :) -
Admin almost 10 yearsThis earlier answer already says that you can use
git commit --amend
, and it also says that you can usegit rebase -i HEAD~commit_count
, all you did was plug in3
forcommit_count
. -
Ángel over 9 yearsYou need
$flawed_commit^..HEAD
, not$flawed_commit..HEAD
. as stated by the man page: «The command will only rewrite the positive refs mentioned in the command line (e.g. if you pass a..b, only b will be rewritten).» -
Admin over 9 years
<nitpick>
There are no "threads" on Stack Overflow, because it's not a discussion forum, there are only "questions", "answers", and "posts".</nitpick>
. Also, not all versions of Vim are the same, not all of them will let you delete characters in insertion mode (makes sense in a way, right?). If you want to always be able to delete characters in Vim,X
andx
will do that (littlex
deletes characters in front of the cursor,X
will delete behind). If you make mistakes, you can useu
repeatedly to undo. Finally,r
is shorthand forreword
in the interactive rebase editor. -
AndiDog over 9 yearsReword doesn't work for me on Windows (even in a MinGW console from SourceTree). Git always tries to open a file "$@". Very unfortunate that Git wasn't built with cross-platform in mind.
-
David Ongaro over 9 yearsNothing gets ever "overwritten" in git. In this case the branch pointer will be set to your new commit and the old commit will get stale if no references are left to it and it might get cleaned up after a few weeks. (Until then others still can find and reference it, e.g. by looking into the reflog.)
-
antinome over 9 years@rjmunro, the link you provided describes the body of the commit message as optional. "If there are any technical details that cannot be expressed in these strict size constraints [of the subject line], put them in the body instead." Sometimes a small change only needs a single line to describe it.
-
rjmunro over 9 years@antinome the answer has now been edited to reflect my previous comment (stackoverflow.com/revisions/179147/12), so that
-m
is now shown as a alternative & not the normal way to do things. I'm happy with the new version, so I'll delete my previous comment. -
onionjake over 9 yearsA link to git-scm.com/book/en/Git-Tools-Rewriting-History would be great in the answer.
-
Joseph K. Strauss over 9 yearsThe
-c
does a few things. It uses the old message by default, but it also copies authorship information (person and time).-C
does the same thing except that it does not ask you to edit the message. -
Joseph K. Strauss over 9 yearsThis does the exact same thing as
git commit --amend
except that it is a 2-step process. -
jay_t55 over 9 years@EarlJenkins Yeah, it's a little funny, but I'm glad they do go into depth even for the "simple" questions.
-
Erik Aronesty about 9 yearsthere should be 2 sha's. one of the diff, one of the metadata. that way you can move commits seamlessly around... restore commits. verify that changes are identical (same sha = same diff ... even if different people do it ... etc).
-
user2864740 about 9 years"Make sure you don't have any working copy changes..." should probably be "Make sure you don't have any staged changes.." As per normal rules only staged changes affect the commit.
-
oligan about 9 yearsLike @SantanuDey , it didn't work for me. I got
fatal: Option -m cannot be combined with -c/-C/-F/--fixup.
-
Zaz almost 9 yearsThis requires installing an external program. In my opinion, it would be better to learn to use the built-in tools and aliases more effectively. I would type:
g c; g rb -i @~9
(commit and rebase), move the new commit to where I want it, changecommit
tof
(fixup
), and save. If you wanted something faster than that, you could aliasgit commit --fixup=<commit>; git rebase -i --autosquash <commit>^
-
gogaman almost 9 years
git commit --amend -m "New commit message"
does not make entering multi-line comment cumbersome. you should use:git commit --amend -m $'- line 1\nline2'
-
Jay almost 9 yearsLittle thing, if you actually did push the commit to a remote before editing, you can "fix" it with git push -f <remote> <branch>, aka force push. It'll overwrite the previous commit. Not the best method as @Dan explained, but there's not much you can do there.
-
Dan Bechard almost 9 years@Wade You should avoid using force push on a shared repo at all costs. Doing so pretty much guarantees a conflict for anyone else using this remote. The only legitimate reason I can think to force a history change is to remove highly sensitive data from an unsecured repository (e.g. accidentally committed 'passwords.txt'). In all other cases, use
git revert
instead. If you must force push, read this first: blog.sensible.io/2012/10/09/… -
Jay almost 9 years@Dan I understand that. That's why I said it's not the best method, and pointed to your comment. But if they have already pushed to their upstream remote, there is very little they can do that wouldn't cause conflicts.
-
Dan Bechard almost 9 years@Wade I disagree with "there is very little they can do that wouldn't cause conflicts." I was responding specifically to your earlier statement "but there's not much you can do there." There is something you can do, that will not cause conflicts. As I suggested, you should use
git revert
instead ofgit push -f
. Revert will add a new commit that reverses the changes made in the reverted commit(s), rather than modifying history; thereby eliminating conflicts. git-scm.com/docs/git-revert -
Jay almost 9 years@Dan Ohh I see what you mean. Yeah that would work. If they were working on their own branch, they'd still have conflicts even with
git revert
though, no? -
Dan Bechard almost 9 years@Wade
git revert
won't introduce any conflicts thatgit commit
wouldn't also introduce. It's simply adding a new commit that happens to contain changes which reverse changes made in a previous commit. In most cases, anyone merging your branch will just be doing a fast-forward. -
sebix over 8 yearsThe
git rebase --continue
was not necessary for me, rebase finished already. -
Lukino over 8 years@13ren You might already found answer, but this might help others (I did not saw reply to your comment). stackoverflow.com/questions/2246208/…
-
MalcolmOcean over 8 yearsAnd if you don't want to add everything, you can first do
git add file.ext
then justgit commit --amend
-
yehudahs over 8 yearsif you already pushed to your remote branch it will not work if your have denyNonFastforwards=true in your config git file. you need to change that to false. try the solution in stackoverflow.com/questions/10544139/…
-
Yaroslav Nikitenko over 8 yearsTo change a word in vim is
cw
typed at its beginning (though the question is not about vim, I agree). -
wbdarby about 8 yearsIt's the lower right portion of the Windows Git Gui. Just select the 'Amend Last Commit' toggle, and it will populate with the most recent commit info.
-
SuperUberDuper about 8 yearsWhat if you don't want to rebase? You just want to change an older message?
-
everton almost 8 years@JosephK.Strauss I believe ammending the commit also keeps original commit author and date information, having the new commiter and date info separately. I'm not sure this approach does that.
-
Joseph K. Strauss almost 8 years@EvertonAgner You are correct.
--amend
will keep the author information, but the question only asks to change the message. -
Ed Randall almost 8 yearsI had some other files in the index which I hadn't committed. This command amended my previous commit message, but also added those files to the commit. Now can I amend again to split the commit up how I wanted it?
-
darkomen over 7 yearsVery good response but you don't talking about the 3th option like "change commit message on previous commit before HEAD which already not push".
-
Soren Stoutner over 7 yearsIf you receive a
denying non-fast-forward
error usinggit push -f
you need to setreceive.denyNonFastForwards false
on the server repository. See stackoverflow.com/questions/9832348/… -
webjockey over 7 yearsUsing commit id is useful in situations where you want to fix more than one commit. You dont need any other commands, this is short and clear.
-
Fontanka16 over 6 years
git commit --amend -m "New commit message"
allows you to use "#" in your commit messages without altering Git configuration -
zok over 6 yearsthe GitHub documentation is really helpful on updating the message of a previous commit with interactive rebase
-
eel ghEEz about 6 years
git reset --hard
annihilates uncommitted changes. Please replace--hard
with--soft
. -
hvaughan3 about 6 yearsFor anyone else having trouble editing things using
rebase -i
, to change frompick
to something else typei
then hit enter to go into edit mode, then changepick
to what ever else, then hitEsc
and enter:wq
to save and quit out of the editor. Finally, it will bring you to change the commit message, where you will again enteri
, change comment, hitEsc
, then type:wq
-
Viraths about 6 yearsgit rebase -i <hash of one commit before the wrong commit> works for me. thanks.
-
Pierre Ferry over 5 years@Armand You can use
git push --force-with-lease
. It is safer when working on the same repository -
Dan Dascalescu almost 5 yearsThis answer is literally identical to this older one. Have you checked existing answers before supplying another one?
-
Dan Dascalescu almost 5 yearsDownvoted as well. People just don't bother to read existing answers.
-
Dan Dascalescu almost 5 yearsThe
git commit --amend
answer had already been given (several times) before you wrote yours. Why did you post it again? If you wanted to add a link to "Rewriting Git History" you could've edited one of the existing answers, or left a comment. -
Dan Dascalescu almost 5 yearsThe vim part is completely off-topic, and instead of encouraging users to spend time learning to use an arcane editor, why not teach them something more on-topic, like how to set up the default git editor to be something user friendly, like
nano
? We're talking about trivial modifications that need to be made to a text file, not hardcore coding that would generate a flame war about the "best" text editor. -
Dan Dascalescu almost 5 yearsYou don't need to use that abomination. You can set your git editor to something sane and user-friendly, like
nano
or Midnight Commander's mcedit. -
Zaz almost 5 years@DanDascalescu: Because it's quicker to learn Vim using the instructions above than perform several rebases using nano. The whole reason git opens a text editor and not its own interface for rebasing is because Vim exists: it's lightweight, installed by default on most systems, and very easy to learn enough to perform a rebase with ease: e.g.
ddjjpZZ
moves a commit 2 down. There's nothing arcane about basic Vim knowledge; it takes 10min to become more comfortable with Vim than nano. -
miguelmorin almost 5 yearsI tried this on a commit that was 5 behind HEAD and moved to a new tree. I had to do
git reset --hard <commit-hash>
to return to the latest tree. -
revelt almost 5 yearsout of all answers — this is the most appropriate for all git newbies ^^^ (use a free program SourceTree and apply "Rebase children of" on a commit before the one you want to edit)
-
Aliaksandr Klimovich almost 5 yearsShould be a shame to Git to have a 15k votes for a simple command that should be implemented in the core. I don't want to care how hard is supposed to be implemented, it should be simple from user side, but not so crazy like I see in this post. Compare to SVN, I can do it with one command/click.
-
Soren Bjornstad almost 5 yearsAgreed,
git reset --hard
is a perfectly legitimate command, but it is misleading given the question. You use--hard
if you committed changes you want to throw away, not if you made a typo in the commit message! -
Chris McCowan over 4 yearsRegarding adding multiline commits messages simply don't close the " until you have entered all your lines"
-
jcalfee314 about 4 yearsIt seems that I can amend only certain modified files into the original commit leaving any file not listed untouched:
git commit --amend -m "New commit message" some files
-
einpoklum over 3 years@Akhila: Not sure why you mentioned my name. Rewriting comit messages of old commits can be done using
git rebase -i oldcommithashhere^
and replacingpick
withedit
. -
Akhila over 3 yearsI couldn't find the name of any person on the answer so when I opened it, last edit showed your name. But that was worth it :) Thank you for that answer!
-
Ayush Mandowara about 3 yearswill interactive rebase change the commit date of all the commits? @EfForEffort
-
Rafael Nobre almost 3 years
git commit --amend -C HEAD
is golden! Thank you -
sid7747 almost 3 yearsRunning this command will get you back to the previous state and what are the things which you want to have. git reset --soft HEAD~1 and then you can do commit from start with relevant files and message which you want to write.
-
sid7747 almost 3 yearsSmall correction over here you to added the files back again if all files than git add . can be used an post that git commit -m "New message" and git push origin BRANCH_NAME
-
Caelum almost 3 years@happycoder while in the most recent edition of this answer and the accepted it answer contains the same content, at the time this answer was submitted, the accepted answer was much simpler and didn't contain a full working example stackoverflow.com/revisions/179147/1 and it wasn't until stackoverflow.com/revisions/179147/5 2 years later from this answer that the complete example was added, and in that time this answer would have been receiving votes for a complete example
-
Pawel Cioch almost 3 yearsThis is not complete answer, missing "Find the commit you want, change pick to r (reword)..." as explained explained here stackoverflow.com/a/28421811/1818723
-
Aydin4ik over 2 yearsAs @miguelmorin said, amending a commit that is not the last commit will roll back the commit tree to that particular commit and rewrite that tree. I.e., you will lose all the commits that came after the comment that you edited. Have fun cherry-picking them to rebuild the commit history.
-
Shailendra Madda over 2 yearsFor simply rename the previous message:
git commit --amend -m "New commit message"
git push origin head -f
-
lenz over 2 yearsgit rebase -i HEAD~2 (ie: for the second to last commit). Then change the word
pick
toreword
next to the appropriate commit. Save. This will open a new terminal with your commit message. Change that message. Save. Done -
Ryan over 2 yearsFor anyone with the same question as @13ren,
git rebase -i --root
from stackoverflow.com/a/14630424/470749 helped me. -
Liran H about 2 yearsThe
-o
flag is exactly what I was looking for: how to change the commit message without adding staged files. Thank you! -
ChuckZHB almost 2 yearsI forget the grammar again and again, so I come back to this page again and again.