On Dec 1, 4:02 pm, haziz <hsa...@gmail.com> wrote:
> Sorry, but this trio of git commands is taxing my intelligence.
> Can you explain these commands for total newbies? What I am trying to learn
> is how to restore or rollback files and projects to a prior state.
> As I have no experience with subversion or other centralized version
> control software, reference to how they did things differently is
> unnecessary and often confusing.

Though explaining them would introduce other non-n00b Git terms, I'd
put them this way:

You use checkout when you want to take Git objects (the sha1-digested
form of files that are tracked by Git, under .git directory) out of
the repository to the file system. That includes checking out branches
altogether, or files selectively. When you checkout branches, a whole
set of files are taken from Git repository, and laid out on to the
file system, according to the path recorded in the index. When you
checkout files selectively, it's pretty much the same thing, except
that you tend to use this mode of command when you discard local
changes to tracked files (i.e. checking out a fresh copy).

Git revert does fairly simple thing of 'undoing' a given commit. What
it effectively does it to apply a patch introduced by an earlier
commit, in reverse. If you revert an old  commit A in your repository,
your will look as if you never made A in the first place. Another way
to achieve the same effect is to remove A by doing an interactive
rebase (git rebase -i) but then you modify history. That'd create
headache for others, if you do it on a public branch.

Of all the three, I think reset is the most notorious command, mostly
because it has mainly 3 modes of operation - soft, mixed and hard
(newer Git versions have added 2 more modes). I myself am not that
immune to the confusion, but here it's anyway. Git reset, as I see it,
is a synchronizing command. When you clone a repository afresh, all 3
entities of Git -- repository, index and local copy -- are all in
sync. There are no local changes, and nothing staged in index (i.e.
scheduled to be committed). This is the same effect if you apply reset
--hard on your working directory. I.e. makes everything in sync
(again). Careful when applying this, because it throws away local
changes without any warning.

The mixed mode is the default (i.e when you don't specify the mode
explicitly) and it synchronizes the repository and index. One usage is
when you've done 'git add', decided you added things by mistake or
wrong files. You can simply do a reset and it's as if you added
nothing yet, and you can start afresh. Another use case is that if you
have A-B-C-D, with D being your head and everything clean, doing a
'git reset B' would make your index look like you just make the commit
B, but you've local changes corresponding to C and D, waiting to be
committed. This use case is followed when for example, you wanted to
make remake commits after B - say as A-B-C'-D'-E-F.

I'm not sure if I've made it all look complex, but my take is that you
create a dummy repository and play with these commands, especially the
reset. Admittedly, the reset man page has a table listing different
modes, which I personally haven't found very useful.



You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to