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 
index.html now
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:

* (the progit book is generally a 
good starter for learning Git, and it's free online)
* Video:

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
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to