On 30 Jul 2012, David C. Rankin outgrape:
I think I got it! So I need to create the local branch v3.5.13-sru and then checkout 3.5.13 into that. (or whatever new name I dream up for the branch :)
Normally one creates the new branch straight from the remote-tracking branch, like so:
git branch v3.5.13-sru whatever-remote-name/v3.5.13-sru
though if your branch has the same name on the local and remote ends, there is a shortcut:
git checkout --track v3.5.13-sru
(where '--track' means 'this branch remains associated with the remote-tracking branch, and pushes and pulls go to it or come from it by default).
Personally, I never use this shortcut: branching and checking out are completely different operations, and it is not helpful to confuse the two. Also, 'git checkout --track BLAH' isn't actually much shorter than 'git branch BLAH remote/BLAH', and 'git branch' has the right defaults (i.e. making a tracking branch is automatic and you have to ask for the opposite).
Also, the 'git checkout' shorthand tends to cause the misconception I see above in new users, that branches are some sort of concrete thing into which you check out code. It is not so. All a branch is is a name: a pointer to a commit which is moved onto any new commit you make on top of that one: the growing tip of some line of development. The name of the branch is completely evanescent: nobody else ever sees it (except perhaps in default commit messages when merging): in particular it doesn't get wired into commits like in Mercurial, or into the filesystem like in Subverison.
This is actually very powerful, because it means branches are really free (not just 'free' in the Subversion sense of 'they don't cost much to create'). Want to create five hundred branches under script control and mess about with each one? Easy! Want to preserve your current state because you're about to do some history-rewriting or something and are scared of messing up? 'git branch a-backup-branch' and now nothing can disturb that backup (since git commits are tied to the *contents* of all their parents, history rewriting must necessarily create *new* commits, while a-backup-branch points to the old one, unaffected).
Many of us old git hands do *all* our significant development on temporary branches ('feature branches' because they often track the addition of some feature), doing a 'git rebase' on those branches whenever we want to catch up with work on our development trunk (also a local branch, but one untouched except for jobs so small they can be done in one commit), then merging at the end (and because it's rebased, that merge is seamless and undetectable to outsiders). e.g. we do this
master -> A -> B -> C \ temp-branch - my work -> more work
Now some complete bastard comes along and does *other* work, imagine it. We pull into our trunk with a simple 'git pull', leaving us with this:
master -> A -> B -> C -> D -> E \ temp-branch - my work -> more work
Now, on the temp branch, when we decide we want to catch up with what other people have done (and make any necessary changes to our code), a simple 'git rebase master' gives us:
master -> A -> B -> C -> D -> E \ temp-branch - my work -> more work
(If there are any conflicts with the new work D and E, git stops in the middle of the rebase and lets us fix it. If we're scared that there will be a lot of conflicts and things might get too hairy to untangle, we can just use 'git branch temp-branch-backup' to make a backup branch of temp-branch before we rebase it, or make a backup branch and rebase *that* -- there is no difference between the two.)
Now, when it comes time to merge, the 'merge' is utterly trivial. There's no change in the commit graph at all, just in a couple of labels:
master -> A -> B -> C -> D -> E -> my work -> more work
This is an *incredibly* powerful workflow, enormously better than the conventional workflow in other version control systems of working in master and coping with conflicts, or working on a branch and periodically merging from the master branch and *hoping* that things work out.