Working With git – Fixing Common Commit Mistakes
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”
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.