On Dec 1, 4:02 pm, haziz <[email protected]> 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. HTH. -- Jeenu -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
