Working With git – Fixing Common Commit Mistakes

Rick HerrmannWe’ve all done it – committed code too soon, made a typo in a commit message, or left code in that was added for debugging.  Here’s how to fix these types of mistakes using git.

1.) “These commit messages would read better if I could type…”

Let’s say you have just committed your code.  You then check the git log and see your commit on top of the list and the commit message says “addded a new idenx.html file”  (if you missed the typo, ‘added’ should only have 2 d’s in it)


So, what’s our next move?  With git, we can amend a prior commit message by adding

git commit –amend -m “added a new index.html file”

So now it looks like this:


2.) “Oops – I didn’t mean to commit that yet…”

Another common mistake is committing code before finishing a task.  For example, we’re testing our new feature and suddenly realize we incorrectly styled something, or forgot to add error handling in one spot, or maybe forgot to comment some code.  (That last one was made up)

While we COULD just fix the mistake and add a second commit, it would be nice if we could just undo the last commit and continue with our work like it never happened.  The easiest way to do this is with git reset.  There are a couple of ways to use git reset, so you have to understand the different options:

·        To uncommit the last commit, but leave the changed files staged, use:  git reset HEAD~1 –soft  (HEAD~x means go back x commits)

·        To uncommit and unstage the last commit, use: git reset HEAD~1 –mixed (–mixed is the default and can be omitted)



Either of these options will undo the commit and allow you to continue.  The –soft option removes the commit, but leaves the files staged, while —mixed removes the commit and also unstages the files.  When I am done (for real this time), I use:

git add .
git commit -m “my commit message”

Checking the git log will show that the bad commit is now gone.

NOTE: One thing to be careful of when using git reset is the –hard option.  This option actually blows away the last commit and undoes the file changes so the work is gone.  This can be a very useful tool, but use it with caution.  We will look at some ways to use this in a future post. “Commit, annnd… done!  Oh shoot, I left that alert(‘testing’) line in there. Commit, annnd… done.  Oh wait…”

What if I have made a whole series of commits that are really only logically one unit of work?  No problem.  We can use the same approach with git reset, but replace HEAD~1 with however many commits I want to go back. For example, for four commits:

git reset HEAD~4 –soft


git reset HEAD~4 –mixed

This retains all of the work that was done in the last four commits, but removes the history of the commits.


A word of caution: git reset works great when the commits we are fixing have not yet been pushed to a published branch.  If we change the commit history to fix our mistake we are going to cause problems for other devs that have pulled those commits.

We will look at strategies for handling that scenario on a future post.

As you can see, it is quite easy using git reset to fix some common commit mistakes.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s