7659

I wrote the wrong thing in a commit message.

How can I change the message? The commit has not been pushed yet.

Baum mit Augen
  • 46,177
  • 22
  • 136
  • 173
Laurie Young
  • 129,506
  • 13
  • 44
  • 54
  • 868
    For 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). – Pat Notz Oct 10 '08 at 20:12

27 Answers27

16965

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:

Enter image description here

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

Community
  • 1
  • 1
EfForEffort
  • 55,496
  • 4
  • 33
  • 39
  • 263
    However `git commit --amend` isnt as powerful as `git rebase -i`. – Jeffrey Jose Jul 05 '10 at 08:40
  • 79
    @jeffjose, It definitely doesn't need to be. Also, `git commit --amend` can fix up the (a?) master commit. – strager Jul 14 '10 at 06:02
  • 120
    If you've already pushed, just force push again: `git push -f origin branchname` – hughes May 02 '12 at 14:12
  • 183
    @hughes isn't `git push -f` a bit dangerous if other people are using the same repository? – Armand Nov 08 '12 at 07:48
  • 98
    If 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. – Sam Nov 14 '12 at 15:38
  • 19
    What @Sam says also seems to work if you just type `git commit --amend` with nothing else following. – driftcatcher Dec 07 '12 at 20:37
  • 8
    @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. – Mark E. Haase May 23 '13 at 15:05
  • 18
    But, **don't amend commits** that have been shared! – EdwardGarson Jun 19 '13 at 02:31
  • 3
    @guillegr123, no, the proper terminology is, or at least used to be, the "tip" of the branch. – EfForEffort Jun 19 '13 at 19:55
  • 13
    Just a little detail. If you do `git commit --amend` while there are staged changes (added with `git 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 the `git add` command when I'm deleting files) – txulu Aug 01 '13 at 08:11
  • a 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` – Sam Sep 24 '13 at 20:57
  • @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. – antinome Sep 17 '14 at 13:12
  • @antinome the answer has now been edited to reflect my previous comment (http://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. – rjmunro Sep 17 '14 at 18:28
  • 1
    A link to http://git-scm.com/book/en/Git-Tools-Rewriting-History would be great in the answer. – onionjake Oct 02 '14 at 02:31
  • there 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). – Erik Aronesty Feb 27 '15 at 20:40
  • "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. – user2864740 Apr 03 '15 at 00:49
  • 1
    `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'` – gogaman May 01 '15 at 21:42
  • 2
    It would be nice if this answer also mentioned editing a commit message that is not the most recent. I.e., it should include this [answer](http://stackoverflow.com/a/180085/1659403). – wachr Jun 01 '15 at 22:32
  • These will change the hashes fyki. – Santosh Kumar Jul 12 '15 at 02:19
  • if 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 http://stackoverflow.com/questions/10544139/how-to-force-push-a-reset-to-remote-repository – yehudahs Nov 12 '15 at 08:05
  • I 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? – Ed Randall Jun 03 '16 at 23:29
  • Very good response but you don't talking about the 3th option like "change commit message on previous commit before HEAD which already not push". – darkomen Aug 04 '16 at 08:27
  • If you receive a `denying non-fast-forward` error using `git push -f` you need to set `receive.denyNonFastForwards false` on the server repository. See http://stackoverflow.com/questions/9832348/git-push-rejected-error-failed-to-push-some-refs#9832377 – Soren Stoutner Oct 30 '16 at 07:55
  • what does "e/r" mean? – rubo77 Mar 29 '17 at 14:54
  • 1
    It means choose the "edit" or "reword" option in the rebase. – EfForEffort Apr 07 '17 at 15:15
  • `git commit --amend -m "New commit message"` allows you to use "#" in your commit messages without altering Git configuration – Fontanka16 Oct 25 '17 at 09:26
  • the [GitHub documentation](https://help.github.com/articles/changing-a-commit-message/#amending-older-or-multiple-commit-messages) is really helpful on updating the message of a previous commit with interactive rebase – zok Jan 08 '18 at 16:30
  • 1
    For anyone else having trouble editing things using `rebase -i`, to change from `pick` to something else type `i` then hit enter to go into edit mode, then change `pick` to what ever else, then hit `Esc` 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 enter `i`, change comment, hit `Esc`, then type `:wq` – hvaughan3 Apr 04 '18 at 14:45
  • @Armand You can use ```git push --force-with-lease```. It is safer when working on the same repository – Pierre Ferry Nov 21 '18 at 09:43
  • 1
    Should 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. – Aliaksandr Klimovich Jul 09 '19 at 09:27
  • Regarding adding multiline commits messages simply don't close the " until you have entered all your lines" – Chris McCowan Oct 04 '19 at 16:53
  • It 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` – jcalfee314 Feb 22 '20 at 17:43
  • How do you rewrite the commit message of an old commit? @einpoklum – Akhila Aug 01 '20 at 19:43
  • 1
    @Akhila: Not sure why you mentioned my name. Rewriting comit messages of old commits can be done using `git rebase -i oldcommithashhere^` and replacing `pick` with `edit`. – einpoklum Aug 01 '20 at 19:46
  • I 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! – Akhila Aug 01 '20 at 20:03
  • will interactive rebase change the commit date of all the commits? @EfForEffort – Ayush Mandowara Feb 13 '21 at 13:43
  • Running 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 May 27 '21 at 13:34
2568
git commit --amend -m "your new message"
David Ferenczy Rogožan
  • 18,863
  • 8
  • 68
  • 65
lfx_cool
  • 25,745
  • 1
  • 13
  • 2
  • 8
    I 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]" – Dave Everitt Oct 14 '11 at 16:58
  • 8
    @DaveEveritt you most likely pushed your commit upstream before trying to fix it. – Thorbjørn Ravn Andersen Apr 25 '13 at 08:21
  • 1
    @ThorbjørnRavnAndersen - thanks, that was 2 years ago, these days I've got my git workflow sorted! – Dave Everitt Apr 25 '13 at 08:41
  • 12
    @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). – hobs Jun 11 '13 at 21:11
  • 36
    I 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) – happy coder Jan 15 '14 at 05:30
  • 2
    @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. – Amal Murali May 21 '14 at 02:36
  • 9
    @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! – happy coder May 21 '14 at 20:16
  • @EarlJenkins Yeah, it's a little funny, but I'm glad they do go into depth even for the "simple" questions. – jay_t55 Jan 10 '15 at 09:04
  • Little thing, if you actually did push the commit to a remote before editing, you can "fix" it with git push -f , 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. – Jay Jul 07 '15 at 18:31
  • @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: http://blog.sensible.io/2012/10/09/git-to-force-put-or-not-to-force-push.html – Dan Bechard Jul 07 '15 at 18:54
  • @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. – Jay Jul 09 '15 at 15:32
  • 1
    @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 of `git 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. http://git-scm.com/docs/git-revert – Dan Bechard Jul 09 '15 at 17:35
  • @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? – Jay Jul 10 '15 at 16:56
  • @Wade `git revert` won't introduce any conflicts that `git 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. – Dan Bechard Jul 10 '15 at 18:52
  • How to change an older commit message? (I have not connected to any remote repository) – Akhila Aug 01 '20 at 19:36
2424

If the commit you want to fix isn’t the most recent one:

  1. git rebase --interactive $parent_of_flawed_commit

    If you want to fix several flawed commits, pass the parent of the oldest one of them.

  2. An editor will come up, with a list of all commits since the one you gave.

    1. Change pick to reword (or on old versions of Git, to edit) in front of any commits you want to fix.
    2. Once you save, Git will replay the listed commits.

  3. 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:

    1. Change the commit in any way you like.
    2. git commit --amend
    3. 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?

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Aristotle Pagaltzis
  • 101,052
  • 21
  • 94
  • 96
  • 42
    Can one change the message of the first commit (which doesn't have a parent)? – 13ren Jan 21 '10 at 19:57
  • 28
    This 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 of `pick` to edit the log message. – MitMaro May 31 '10 at 13:27
  • 90
    Incidentally, `$parent_of_flawed_commit` is equivalent to `$flawed_commit^`. – Peeja Nov 28 '10 at 23:26
  • 7
    @pingu: No, you won't loose any commit dates. – Daniel Rinser May 31 '11 at 19:11
  • 69
    Never EVER do this (or rebase in general) if you have already pushed upstream! – Daniel Rinser May 31 '11 at 19:14
  • 22
    Use `-p` (`--preserve-merges`) if there was a merge after the flawed commit. – ahven Jan 31 '12 at 14:37
  • 5
    Also, `$parent_of_flawed_commit` means "commit before the one you screwed up" :) – Nick Oct 04 '12 at 14:44
  • @AristotlePagaltzis I'm the only one pushing commits to a remote repository. Can I `git push -f` to push `reword`s for commits that have already pushed? – trusktr Dec 01 '13 at 02:38
  • 1
    This 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. – Jimmy Bosse May 29 '14 at 13:32
  • Reword 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. – AndiDog Aug 09 '14 at 07:47
  • The `git rebase --continue` was not necessary for me, rebase finished already. – sebix Sep 01 '15 at 15:39
  • 1
    @13ren You might already found answer, but this might help others (I did not saw reply to your comment). http://stackoverflow.com/questions/2246208/change-first-commit-of-project-with-git – Lukino Sep 16 '15 at 20:07
  • What if I want to edit the very first commit message, i.e the initial commit's message? – Sam Chats Jul 17 '17 at 18:23
  • 3
    Use `--root` instead of a commit hash. – Aristotle Pagaltzis Jul 17 '17 at 22:57
799

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

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Fatih Acet
  • 25,751
  • 8
  • 49
  • 56
  • 20
    `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". – Joe Aug 21 '13 at 20:21
  • 2
    What if you don't want to rebase? You just want to change an older message? – SuperUberDuper Apr 21 '16 at 08:56
  • 3
    `git reset --hard` annihilates uncommitted changes. Please replace `--hard` with `--soft`. – eel ghEEz Feb 28 '18 at 17:44
  • 3
    Agreed, `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! – Soren Bjornstad Jul 22 '19 at 13:52
  • `git commit --amend -C HEAD` is golden! Thank you – Rafael Nobre May 20 '21 at 15:44
406

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"
Steven Penny
  • 82,115
  • 47
  • 308
  • 348
John
  • 4,254
  • 1
  • 13
  • 10
365

You also can use git filter-branch for that.

git filter-branch -f --msg-filter "sed 's/errror/error/'" $flawed_commit..HEAD

It's not as easy as a trivial git commit --amend, but it's especially useful, if you already have some merges after your erroneous commit message.

Note that this will try to rewrite every commit between HEAD and the flawed commit, so you should choose your msg-filter command very wisely ;-)

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Mark
  • 5,905
  • 1
  • 17
  • 14
  • 4
    Is there a version of this that does not change the commit if the regex doesn't find anything? – sjakubowski Mar 28 '13 at 20:08
  • 3
    AFAIK 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. – Mark Mar 29 '13 at 16:16
  • 4
    @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. – Mark Jul 06 '13 at 19:08
  • 6
    @Mark Yes they do, they are required to. Commit ids are dependent on previous commits. If they didn't change, git would be useless. – Miles Rout Jan 11 '14 at 04:45
  • 2
    You 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)._» – Ángel Jul 29 '14 at 11:18
324

I prefer this way:

git commit --amend -c <commit ID>

Otherwise, there will be a new commit with a new commit ID.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
krevedko
  • 3,967
  • 1
  • 15
  • 12
  • 8
    For 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. – Jan Mar 29 '13 at 16:27
  • 46
    Amending _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. – Emil Lundberg Jun 19 '13 at 09:30
  • 7
    Agree 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 " by default, so no need to specify it. – Gal Sep 29 '13 at 19:12
  • 2
    The `-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 Dec 28 '14 at 02:55
  • 1
    Like @SantanuDey , it didn't work for me. I got `fatal: Option -m cannot be combined with -c/-C/-F/--fixup.` – Andrew Grimm Apr 14 '15 at 05:22
  • Using 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. – webjockey Dec 21 '16 at 16:43
  • I tried this on a commit that was 5 behind HEAD and moved to a new tree. I had to do `git reset --hard ` to return to the latest tree. – miguelmorin May 23 '19 at 21:20
317

If you are using the Git GUI tool, there is a button named Amend last commit. Click on that button and then it will display your last commit files and message. Just edit that message, and you can commit it with a new commit message.

Or use this command from a console/terminal:

git commit -a --amend -m "My new commit message"
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Akhilraj N S
  • 8,253
  • 5
  • 29
  • 37
  • 5
    This answer is *literally* identical to this [older one](https://stackoverflow.com/questions/179123/how-to-modify-existing-unpushed-commits/6258114#6258114). Have you checked existing answers before supplying another one? – Dan Dascalescu May 02 '19 at 01:15
289

You can use Git rebasing. For example, if you want to modify back to commit bbc643cd, run

$ git rebase bbc643cd^ --interactive

In the default editor, modify 'pick' to 'edit' in the line whose commit you want to modify. Make your changes and then stage them with

$ git add <filepattern>

Now you can use

$ git commit --amend

to modify the commit, and after that

$ git rebase --continue

to return back to the previous head commit.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Shoaib Ud-Din
  • 4,404
  • 3
  • 19
  • 23
  • 1
    If you want to make sure your change from `git commit --amend` took affect you can use `git show` and it will show the new message. – Steve Tauber Feb 19 '13 at 20:12
282
  1. If you only want to modify your last commit message, then do:

    git commit --amend
    

That will drop you into your text editor and let you change the last commit message.

  1. If you want to change the last three commit messages, or any of the commit messages up to that point, supply HEAD~3 to the git rebase -i command:

    git rebase -i HEAD~3
    
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Heena Hussain
  • 3,583
  • 1
  • 18
  • 20
  • 6
    [This earlier answer](http://stackoverflow.com/a/7070976/456814) already says that you can use `git commit --amend`, and it also says that you can use `git rebase -i HEAD~commit_count`, all you did was plug in `3` for `commit_count`. –  Jul 23 '14 at 12:21
  • Downvoted as well. People just don't bother to [read existing answers](https://stackoverflow.com/questions/179123/how-to-modify-existing-unpushed-commits/6258114#comment98541887_13282142). – Dan Dascalescu May 02 '19 at 01:16
265

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

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 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
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
sebers
  • 2,856
  • 1
  • 11
  • 12
  • 3
    This 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 to `git add`, but only *ever* before I've `git push`ed. I also use `git 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 Jun 29 '13 at 03:17
229

Use

git commit --amend

To understand it in detail, an excellent post is 4. Rewriting Git History. It also talks about when not to use git commit --amend.

skin
  • 2,540
  • 1
  • 14
  • 13
  • 2
    Is 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. – stackunderflow Jun 04 '13 at 11:32
  • 2
    In 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. – kbro Jun 29 '13 at 03:29
  • 1
    Just 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. – ShawnFumo Sep 11 '13 at 18:20
  • 1
    The `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 May 02 '19 at 01:17
212

If it's your last commit, just amend the commit:

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

(Using the -o (--only) flag to make sure you change only the commit message)


If it's a buried commit, use the awesome interactive rebase:

git rebase -i @~9   # Show the last 9 commits in a text editor

Find the commit you want, change pick to r (reword), and save and close the file. Done!



Miniature Vim tutorial (or, how to rebase with only 8 keystrokes 3jcwrEscZZ):

  • Run vimtutor if you have time
  • hjkl correspond to movement keys
  • All commands can be prefixed with a "range", e.g. 3j moves down three lines
  • i to enter insert mode — text you type will appear in the file
  • Esc or Ctrlc to exit insert mode and return to "normal" mode
  • u to undo
  • Ctrlr to redo
  • dd, dw, dl to delete a line, word, or letter, respectively
  • cc, cw, cl to change a line, word, or letter, respectively (same as ddi)
  • yy, yw, yl to copy ("yank") a line, word, or letter, respectively
  • p or P to paste after, or before current position, respectively
  • :wEnter to save (write) a file
  • :q!Enter to quit without saving
  • :wqEnter or ZZ to save and quit

If you edit text a lot, then switch to the Dvorak keyboard layout, learn to touch-type, and learn Vim. Is it worth the effort? Yes.



ProTip™: Don't be afraid to experiment with "dangerous" commands that rewrite history* — Git doesn't delete your commits for 90 days by default; you can find them in the reflog:

$ git reset @~3   # Go back three commits
$ git reflog
c4f708b HEAD@{0}: reset: moving to @~3
2c52489 HEAD@{1}: commit: more changes
4a5246d HEAD@{2}: commit: make important changes
e8571e4 HEAD@{3}: commit: make some changes
... earlier commits ...
$ git reset 2c52489
... and you're back where you started

* Watch out for options like --hard and --force though — they can discard data. * Also, don't rewrite history on any branches you're collaborating on.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Zaz
  • 39,637
  • 10
  • 70
  • 92
  • 3
    The 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 May 02 '19 at 01:19
  • 2
    @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. – Zaz May 02 '19 at 22:07
201

Amend

You have a couple of options here. You can do

git commit --amend

as long as it's your last commit.

Interactive rebase

Otherwise, if it's not your last commit, you can do an interactive rebase,

git rebase -i [branched_from] [hash before commit]

Then inside the interactive rebase you simply add edit to that commit. When it comes up, do a git commit --amend and modify the commit message. If you want to roll back before that commit point, you could also use git reflog and just delete that commit. Then you just do a git commit again.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
wallerjake
  • 3,809
  • 3
  • 24
  • 30
186

If you are using the Git GUI, you can amend the last commit which hasn't been pushed with:

Commit/Amend Last Commit
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
gulchrider
  • 4,206
  • 3
  • 23
  • 15
169

I use the Git GUI as much as I can, and that gives you the option to amend the last commit:

Tick that box

Also, git rebase -i origin/masteris a nice mantra that will always present you with the commits you have done on top of master, and give you the option to amend, delete, reorder or squash. No need to get hold of that hash first.

Amal Murali
  • 70,371
  • 17
  • 120
  • 139
Havard Graff
  • 2,699
  • 1
  • 12
  • 15
141

Wow, so there are a lot of ways to do this.

Yet another way to do this is to delete the last commit, but keep its changes so that you won't lose your work. You can then do another commit with the corrected message. This would look something like this:

git reset --soft HEAD~1
git commit -m 'New and corrected commit message'

I always do this if I forget to add a file or do a change.

Remember to specify --soft instead of --hard, otherwise you lose that commit entirely.

Radu Murzea
  • 10,036
  • 9
  • 44
  • 68
  • 5
    This does the exact same thing as `git commit --amend` except that it is a 2-step process. – Joseph K. Strauss Dec 28 '14 at 02:58
  • 3
    @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. – everton May 07 '16 at 23:13
  • 4
    @EvertonAgner You are correct. `--amend` will keep the author information, but the question only asks to change the message. – Joseph K. Strauss May 09 '16 at 13:59
  • Small 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 – sid7747 May 27 '21 at 13:47
138

For anyone looking for a Windows/Mac GUI to help with editing older messages (i.e. not just the latest message), I'd recommend Sourcetree. The steps to follow are below the image.

Sourcetree interactive rebase

For commits that haven't been pushed to a remote yet:

  1. Make sure you've committed or stashed all current changes (i.e., so there are no files listed in the "File Status" tab) - it won't work otherwise.
  2. In the "Log / History" tab, right click on the entry with an adjoining line in the graph one below the commit(s) you wish to edit and select "Rebase children of <commit ref> interactively..."
  3. Select the whole row for a commit message you wish to change (click on the "Message" column).
  4. Click the "Edit Message" button.
  5. Edit the message as desired in the dialog that comes up and then click OK.
  6. Repeat steps 3-4 if there are other commit messages to change.
  7. Click OK: Rebasing will commence. If all is well, the output will end "Completed successfully". NOTE: I've sometimes seen this fail with Unable to create 'project_path/.git/index.lock': File exists. when trying to modify multiple commit messages at the same time. Not sure exactly what the issue is, or whether it will be fixed in a future version of Sourcetree, but if this happens would recommend rebasing them one at a time (slower but seems more reliable).

...Or... for commits that have already been pushed:

Follow the steps in this answer, which are similar to above, but require a further command to be run from the command line (git push origin <branch> -f) to force-push the branch. I'd recommend reading it all and applying the necessary caution!

Deni J.
  • 1,211
  • 3
  • 21
Steve Chambers
  • 31,993
  • 15
  • 129
  • 173
  • 1
    out 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) – revelt Jun 29 '19 at 05:53
  • 1
    That was exactly what I was looking for! It's a pity SourceTree is not available for Linux... – Antônio Medeiros Apr 12 '21 at 21:45
129

If you just want to edit the latest commit, use:

git commit --amend

or

git commit --amend -m 'one line message'

But if you want to edit several commits in a row, you should use rebasing instead:

git rebase -i <hash of one commit before the wrong commit>

Git rebase editing

In a file, like the one above, write edit/e or one of the other options, and hit save and exit.

Now you'll be at the first wrong commit. Make changes in the files, and they'll be automatically staged for you. Type

git commit --amend

Save and exit that and type

git rebase --continue

to move to next selection until finished with all your selections.

Note that these things change all your SHA hashes after that particular commit.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Shubham Chaudhary
  • 36,933
  • 9
  • 67
  • 78
128

If you only want to change your last message you should use the --only flag or its shortcut -o with commit --amend:

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

This ensures that you don't accidentally enhance your commit with staged stuff. Of course it's best to have a proper $EDITOR configuration. Then you can leave the -m option out, and Git will pre-fill the commit message with the old one. In this way it can be easily edited.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
David Ongaro
  • 2,899
  • 1
  • 19
  • 34
  • 1
    The "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 Jul 20 '14 at 20:51
  • 2
    That 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. – David Ongaro Jul 20 '14 at 20:51
  • 1
    I wouldn't go so far to say that the [top answer](http://stackoverflow.com/a/179147/456814) 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. –  Jul 21 '14 at 21:26
  • 2
    To 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](https://github.com/git/git/commit/ea2d4ed35902ce15959965ab86d80527731a177c)). So the right answer back in 2008 would probably have been something like: `git stash; git commit --amend; git stash pop`. – David Ongaro Jul 21 '14 at 23:00
104

Update your last wrong commit message with the new commit message in one line:

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

Or, try Git reset like below:

# You can reset your head to n number of commit
# NOT a good idea for changing last commit message,
# but you can get an idea to split commit into multiple commits
git reset --soft HEAD^

# It will reset you last commit. Now, you
# can re-commit it with new commit message.

Using reset to split commits into smaller commits

git reset can help you to break one commit into multiple commits too:

# Reset your head. I am resetting to last commits:
git reset --soft HEAD^
# (You can reset multiple commit by doing HEAD~2(no. of commits)

# Now, reset your head for splitting it to multiple commits
git reset HEAD

# Add and commit your files separately to make multiple commits: e.g
git add app/
git commit -m "add all files in app directory"

git add config/
git commit -m "add all files in config directory"

Here you have successfully broken your last commit into two commits.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
przbadu
  • 5,093
  • 2
  • 37
  • 54
  • 3
    If 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](http://stackoverflow.com/a/179147/456814)**. Additionally, `git reset --soft HEAD^` works identically to the soft reset in [this earlier answer](http://stackoverflow.com/a/20338254/456814), because they both reset back to the first parent commit. –  Jul 21 '14 at 23:15
  • 3
    I 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 use ```git```. Sometimes, this can be really helpfull. :) – przbadu Jul 22 '14 at 06:29
89

On this question there are a lot of answers, but none of them explains in super detail how to change older commit messages using Vim. I was stuck trying to do this myself, so here I'll write down in detail how I did this especially for people who have no experience in Vim!

I wanted to change my five latest commits that I already pushed to the server. This is quite 'dangerous' because if someone else already pulled from this, you can mess things up by changing the commit messages. However, when you’re working on your own little branch and are sure no one pulled it you can change it like this:

Let's say you want to change your five latest commits, and then you type this in the terminal:

git rebase -i HEAD~5

*Where 5 is the number of commit messages you want to change (so if you want to change the 10th to last commit, you type in 10).

This command will get you into Vim there you can ‘edit’ your commit history. You’ll see your last five commits at the top like this:

pick <commit hash> commit message

Instead of pick you need to write reword. You can do this in Vim by typing in i. That makes you go in to insert mode. (You see that you’re in insert mode by the word INSERT at the bottom.) For the commits you want to change, type in reword instead of pick.

Then you need to save and quit this screen. You do that by first going in to ‘command-mode’ by pressing the Escbutton (you can check that you’re in command-mode if the word INSERT at the bottom has disappeared). Then you can type in a command by typing :. The command to save and quit is wq. So if you type in :wq you’re on the right track.

Then Vim will go over every commit message you want to reword, and here you can actually change the commit messages. You’ll do this by going into insert mode, changing the commit message, going into the command-mode, and save and quit. Do this five times and you’re out of Vim!

Then, if you already pushed your wrong commits, you need to git push --force to overwrite them. Remember that git push --force is quite a dangerous thing to do, so make sure that no one pulled from the server since you pushed your wrong commits!

Now you have changed your commit messages!

(As you see, I'm not that experienced in Vim, so if I used the wrong 'lingo' to explain what's happening, feel free to correct me!)

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Marijn
  • 1,349
  • 10
  • 12
  • 4
    ``There are no "threads" on Stack Overflow, because it's not a discussion forum, there are only "questions", "answers", and "posts".``. 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` and `x` will do that (little `x` deletes characters in front of the cursor, `X` will delete behind). If you make mistakes, you can use `u` repeatedly to undo. Finally, `r` is shorthand for `reword` in the interactive rebase editor. –  Aug 07 '14 at 17:47
  • 1
    To change a word in vim is `cw` typed at its beginning (though the question is not about vim, I agree). – Yaroslav Nikitenko Dec 05 '15 at 06:25
  • You don't need to use [that abomination](https://www.zdnet.com/article/vim-update-classic-unix-linux-editor-gets-first-update-in-years/). You can [set your git editor](https://stackoverflow.com/questions/2596805/how-do-i-make-git-use-the-editor-of-my-choice-for-commits) to something sane and user-friendly, like `nano` or Midnight Commander's mcedit. – Dan Dascalescu May 02 '19 at 01:28
80

I have added the aliases reci and recm for recommit (amend) it. Now I can do it with git recm or git recm -m:

$ vim ~/.gitconfig

[alias]

    ......
    cm = commit
    reci = commit --amend
    recm = commit --amend
    ......
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Chu-Siang Lai
  • 2,370
  • 22
  • 21
80

You can use git-rebase-reword

It is designed to edit any commit (not just last) same way as commit --amend

$ git rebase-reword <commit-or-refname>

It is named after the action on rebase interactive to amend a commit: "reword". See this post and man -section interactive mode-

Examples:

$ git rebase-reword b68f560
$ git rebase-reword HEAD^
albfan
  • 10,988
  • 2
  • 49
  • 74
  • 6
    This 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, change `commit` to `f` (`fixup`), and save. If you wanted something faster than that, you could alias `git commit --fixup=; git rebase -i --autosquash ^` – Zaz Apr 29 '15 at 15:25
58

I realised that I had pushed a commit with a typo in it. In order to undo, I did the following:

git commit --amend -m "T-1000, advanced prototype"
git push --force

Warning: force pushing your changes will overwrite the remote branch with your local one. Make sure that you aren't going to be overwriting anything that you want to keep. Also be cautious about force pushing an amended (rewritten) commit if anyone else shares the branch with you, because they'll need to rewrite their own history if they have the old copy of the commit that you've just rewritten.

neoneye
  • 44,507
  • 23
  • 155
  • 143
  • 7
    Nothing 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.) – David Ongaro Sep 04 '14 at 23:47
53

I like to use the following:

  1. git status
  2. git add --all
  3. git commit -am "message goes here about the change"
  4. git pull <origin master>
  5. git push <origin master>
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Kedar Adhikari
  • 691
  • 5
  • 5
47

If you have 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 the wrong message, and you need to be careful when changing the message. That is, 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 my 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 those 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.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Prabhakar Undurthi
  • 5,818
  • 2
  • 36
  • 46