• View
• Edit
• History
• Print

ChangingHistory

WARNING: Changing history is a very risky thing to do in git. In the simplest case, a single, local repository, there should not be any problems. However, as soon as you use more than one repository, changing history will make them incompatible until the same changes are made to all the directories and they are in sync again. With that being out of the way, let's proceed!

Changing the latest commit

After working on a new feature and happily committing your changes, you notice a glaring, terrible typo in your commit message, you forgot to do something or add some file, you were working on a new machine and forgot to set your global configuration, or discover a bug minutes later that was introduced with your modifications and would be best fixed now. As long as you have not shared the commit, there is nothing to fear!

git commit --amend

will allow you to change the latest commit. If you have added any file to your staging area, changes to those files will be committed and you will have a new, hopefully better, version of your code in that commit. It will also open up your text editor for you to change the commit message if needed (handy to fix typos that you only notice after committing for the first time!). Alternatively, the -m option will allow you to give a commit message as usual.

For configuration issues (ex.: name and email address), first set the proper values then amend, with the --reset-author option, or simply use:

git commit --amend --author="Author Name <author@email.address>"

Undoing an amendment

If you were overeager with the amendments, or not quite at the position you thought in the tree, it is possible to undo an amendment and then commit it as a proper commit instead.

# Move the current head so that it's pointing at the old commit
# Leave the index intact for redoing the commit.
# HEAD@{1} gives you "the commit that HEAD pointed at before 
# it was moved to where it currently points at". Note that this is
# different from HEAD~1, which gives you "the commit that is the
# parent node of the commit that HEAD is currently pointing to."
git reset --soft HEAD@{1}

# commit the current tree using the commit details of the previous
# HEAD commit. (Note that HEAD@{1} is pointing somewhere different from the
# previous command. It's now pointing at the erroneously amended commit.)
git commit -C HEAD@{1}

Original answer found here: https://stackoverflow.com/questions/1459150/how-to-undo-git-commit-amend-done-instead-of-git-commit

Changing older commits

This is getting in dangerous territory, as two repos with different histories cannot easily work together. Nonetheless, it is sometimes practical, say when creating a new repo starting from features that were first added to another repo but now deserve their own.

git rebase -i "HASH"

will allow you to act on commits between HEAD and the HASH. HASH can be a commit hash, or given as HEAD~n where n is the number of commits to go back in time to, or --root which will start from the beginning. You will the see a list of all commits to be affected and be able to:

pick

use without changes

reword

use the commit, but with a different message

edit

change the commit itself (by pausing and allowing you to use amend)

squash

combine that commit with the previous one, message and all

fixup

identify this commit as a correction for the previous one. This will merge the fixup with the previous commit, but also get rid of the fixup commit message (which presumably just said something like: "fixed bug in previous commit"

exec

?!?!

drop

remove the commit from history (beware of compatibility issues!)