Git for people with other VCSes wired into their fingers

[zackw]

This is a handy tutorial. I'd like to suggest that you augment it with some specific help for people who are already deeply accustomed to some other version control system (which might itself have the distributed nature) and so are constantly tripping over our own expectations when using git, whose CLI seems to have been designed specifically to confuse people who aren't coming to it new.

I'm not talking about trivial stuff like checkout -- file being how you revert changes in the working copy. Here are some specific points that I have never seen clarified anywhere:

• No other DVCS (that I'm aware of, and I've used most of them) bothers with the distinction between local branches and remote-tracking branches. No git documentation that I'm aware of bothers to explain why remote-tracking branches exist. Please talk about this a little.
• If you're used to CVS-style centralized version control systems, git pull seems like the equivalent of cvs update -- until the first time you don't have a fast-forward, at which point (I think) the remote-tracking branch is updated but the local branch isn't. How are you supposed to proceed from that state? I have cargo-culted my way to git merge origin/currentbranch but I'm not convinced that's the correct operation.
• Similarly, if you have more than one active branch in your local repo and you do git pull, it updates all the remote-tracking branches but only syncs up the local branch that is currently checked out. (Or that's what I think it does. I could easily be confused.) This is never what I want, and I doubt it's what anyone else wants either. Is there any way to get all the branches updated?
• And, inversely, git push does a whole lot of different things, but it doesn't by default do the obvious thing, viz. take every branch in the local tree and make the corresponding remote branch have the same head, creating remote branches if necessary. (Again, I could easily be confused.) Explain why not and explain how to get that behavior when wanted.

There are probably more such gotchas, but those are the ones that regularly make me feel like I am standing on treacherous ground with this thing.

[tensory]

Those are some really nice suggestions. I have to admit that my only experience with VCS prior to Git was SVN, and I have never used CVS, so I am wholly unqualified to write about it. I could try to put in a word about why remote-tracking branches exist, at best.

In the domain of stuff I can talk about, I feel there are a ton of SVN-to-Git tutorials out there, but it's better to just try to understand what Git is actually doing rather than attempt to put it in SVN terms. (Even understanding by cargo-cult repetition is better than trying to force the analogy to work.) There just is no SVN analogy for the Github branch-and-merge procedure.

The other problems you mention I think are simply poor design in Git commands -- like, they just don't often mean what a typical English speaker would expect them to mean. Why in the world do you use git checkout to create a branch, but git branch to delete it? And I didn't understand what "git pull origin master" was doing with the word "origin" for literally over a year. I keep certain facts in rote memory, like "git push only works on the branch I mention", and I just don't use shortcuts that make the meaning less clear. I'm right there with you! It really is confusing!