You're not the first one to get confused about those :)
Maybe the biggest cause of confusion is that the last two (checkout &
reset) have two modes: Either they work on files, or they work on revisions
(or references, to be concrete). I'll try giving a short, but somewhat
incomplete explanation (I've sacrificed a lot of correctness for brevity
here as I couldn't find the best words):
*git checkout*: Checks something out of the repository and into the working
tree. Usually we use this for switching between branches:
git checkout -b featureA //creates and switches to the branch featureA
git checkout master //switches back to the master
git checkout 28aa2a20aaf8 //checks out the code as it was in a particular
git checkout 2.0 //checks out the code as it was in the tag '2.0'
The second mode is to check out files of the repository and into the
working tree. This means dropping local changes that you have made.
git checkout index.html // drops the changes you have made in index.html
It's all fairly, although extensively explained in git checkout --help
*Onto git reset.* Like with checkout, it can can take either a reference,
or a path.
If it is a reference, reset will move your current branch's "pointer"
(called HEAD) to the given reference. This sounds a bit complicated, but
don't stress: the only area where you'll use this command as a beginner is
typically to delete the previous commit:
git reset --hard HEAD~1
The above command says move the current branch back one commit, and --hard
changes the work tree state to be the same as it was (removing your local
changes and your last commit!). You'll probably do this a lot when you
accidentally merge something, and you want to undo it.
Another example, but this one doesn't have so many practical purposes:
git reset 28aa2a20aaf8 // move the HEAD pointer in the current branch to
point at 28aa2a20aaf8, keeping your work tree as it is
In the second mode, working on paths, reset is used to unstage changes you
have added for committing:
git add *.html //adding all local changes to the stage, getting ready to
git status // doh, I don't want to commit the changes I've done in
git reset index.html
git status //there, that's better. index.html is not to be committed
It is all fully covered in git reset --help
*Git revert *is perhaps the most intuitive one, as it only has one use: git
revert [revision] reverts the given revision, by doing the exact inverse
changes in a new commit. If you have this history for example:
A - B
You do a new commit C:
A - B - C
And now you go git revert C (which creates the commit C'):
A - B - C - C'
.. The state of your code is exactly as it was back with A - B.
Here's some further reading material:
* http://progit.org/2011/07/11/reset.html (the progit book is generally a
good starter for learning Git, and it's free online)
* Video: http://marakana.com/forums/git/git/399.html
Feel free to ask more, it was surprisingly difficult to explain here, but
I'd like to get better at that with some more practice.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at