a git plan, long term

[Ian Young]

Wow, everyone woke up while I was asleep ;-)

On 8 Aug 2013, at 23:01, Brent Putman <putmanb at georgetown.edu> wrote:

>> The other thing is the branching model, of course.  We *never* branch in Subversion, as a matter of policy, except when establishing a new minor release line. 
> 
> Historically true, but only because we just haven't.  Chad and I
> discussed several times the desirability to using branches more
> effectively.    There's absolutely no technical reason, and no policy
> reason (other than what we decide) to preclude us branching like crazy.

> I'll take your word for how it re: Git users work, but many Subversion
> users branch that way too.  That's the so-called "stable trunk" model,
> where nothing every goes on the trunk unless it's "done" and
> releasable.  So by definition any body of work which is going to span
> more than one commit is done on a (possibly short-lived) task or feature
> branch, and then merged to trunk in one go when it's ready.

I've used Subversion and other earlier systems in a more branchy fashion than we do here, and while I accept that in general you *can* do that, particularly in very small projects, I think there are pretty good reasons why most projects don't.  The big one in my experience has been that merges fail far too often.  If you branch in Subversion, you know it's likely to be a pain to merge it (particularly if someone else is working on the same project), so that makes you wary of creating one unless you know it's never going to be merged back in.  In something like Git, where every commit in the decentralised collection of repositories is implicitly a branch you just don't know about yet, you have more tools to help with branching (note that I'm not saying "to help with merging") so somewhat counter-intuitively merges tend to succeed, and that means branching is lower risk, which in turn means you tend to use it more often.

One of those tools is rebasing, which you can think of as moving the branch point forward while retaining branch history.  It's essentially what you get from a "svn update" on the main line, but for a branch.  It helps keep branches current with the material they will later be merged with, so that the merge is much more likely to occur.  In fact, in many cases, the merge evaporates because the branch is finally applied upstream as a push to the head.

I realise I'm probably not explaining rebasing very well.

http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html

http://alexvollmer.com/posts/2009/01/31/rewriting-history-with-git/



If you're using Subversion, there is *one* repository, and any branch however transient must appear there and never goes away.  This means that branching affects everyone, and has to be a matter for central policy.  In a distributed system, the policy for branching in the "central" repository can be independent of the developers' personal choices as to how they want to manage their day-to-day work.

I don't have the broad experience to know for sure, but I'd guess that particularly for the very large projects using Git, the branching policy for the "central" repository is pretty much the same as we have for ours, to avoid everyone going insane.  The individual developers are branching locally far more often but that's not apparent because the changes they push are to a head.

> The main thing that puzzles me is:  Git may be better if you're
> really using it as a *distributed* SCM - but most people seem to wind up
> just using it with GitHub or other centralized repo.  I'm sure there's
> more to it than that, but I welcome enlightenment.

You should probably think of GitHub not as providing centralised repositories, as such, but as providing centralised hosting for distributed repositories.  One collaboration model is indeed to treat the GitHub version of the project repository as a central master with project committers pushing changes directly to it, but even then each developer has their own local repository and that may have local branches not visible to anyone else.

The other common collaboration pattern, which doesn't require committer access, is for someone who wants to contribute to fork the repository on GitHub.  Now they have their own publicly visible repository separate from the project's one (as well as the one on their machine, of course).  Contribution to the upstream project is by sending a pull request via GitHub or e-mailing a changeset.  This way of working isn't possible with a truly centralised system, as you can't branch or retain source control for a sequence of experimental changes without being able to write to the central repository.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130809/099cd088/attachment.bin