Rewriting Commit History

 19 Nov 2009

 0 Comments

Recently at work I was working on a small bug fix git branch that had MANY small commits doing relatively the same thing. I really wanted to go through and clean up the commit messages to make them uniform and actually needed to change some of the commits too.

By google searching I found this stack overflow question that gave me my answer. This user wrote about how using rebase –interactive can be used to specify any number of commits to edit. You basically call git rebase --interactive COMMIT where COMMIT can be HEAD^ to just do one commit, or any SHA1 or branch reference as normal. Git will open your $EDITOR with a file listens all commits in question. You can then edit this temporary file to tell git what commits to let you edit and which ones to drop completely or merge into the commit above them (which you can do manually via edit as well). Then git will play through your commits that you’ve said you want to edit one at a time, and drop you into a shell to let you do anything you want. Sometimes you want to edit just the commit message so you just git commit --amend and change the message. Other times you want to undo the last two commits and redo them git reset HEAD^^ and then edit and commit again.

Also just to remember this (recently discussed at work as well):

<ul>
  • git reset HEAD^ undoes the last commit and places changes as changes in the working tree.
  • <li><code>git reset --hard HEAD^</code> removes the commit changes completely (not form the git data store, but completely from your working tree at least)</li>
    
    
    
    <li><code>git reset --soft HEAD^</code> puts the changes into a "staged" state. This makes it east to add to a commit while you have many other edited files in your tree (Maybe even more changes to a changed file that you don't want to add into this commit)</li></ul>