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.

-- 
NULL && (void)