I usually submit a list of commits for review. If I have the following commits:
HEAD
Commit3
Commit2
git rebase -i @~9 # Show the last 9 commits in a text editor
Find the commit you want, change pick
to e
(edit
), and save and close the file. Git will rewind to that commit, allowing you to either:
git commit --amend
to make changes, orgit reset @~
to discard the last commit, but not the changes to the files (i.e. take you to the point you were at when you'd edited the files, but hadn't committed yet).The latter is useful for doing more complex stuff like splitting into multiple commits.
Then, run git rebase --continue
, and Git will replay the subsequent changes on top of your modified commit. You may be asked to fix some merge conflicts.
Note: @
is shorthand for HEAD
, and ~
is the commit before the specified commit.
Read more about rewriting history in the Git docs.
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 3 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.
On many systems, git rebase -i
will open up Vim by default. Vim doesn't work like most modern text editors, so take a look at how to rebase using Vim. If you'd rather use a different editor, change it with git config --global core.editor your-favorite-text-editor
.