X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=kAFQk6+knKg78NtCUgojiuGEA6SXhsxf9MZ0rBJMm1k=;
	b=yZSB2gw5KURwT0O+naThCYuRrTYmxBulPZMww1dNA9oMdNADShxpmyEMbrLbushVMr
	eXFDFTXq+tGSzs6/0TgDI6uls10aI7rQ1TooIdo/qvsMQcb0c9p1Jz6Msce9aSqSjhZG
	eR6s1rgTgBJjFLYNXISUtoOshkdveqTHeeQQpPrfLRT93mCkZhok8p6/Bcm8BB2IGNPx
	kYndKpeY0crJ7NJrWS0PpuE2xsYlDtEF9USefN9ItAC8FLhjaLefws7h3OlS6Bnq9GRS
	KgxNKZzSaQ4BZaI2jGxeog4kws+A4PVTqXu42x9h5zAZAysthGAtcTtCLVBJMbTUr8mB
	Pwrw==
MIME-Version:	1.0
In-Reply-To:	<CAGde_xOFELRBJZ30utu1x+B-y+8Vo+EDGOKPLqyafO+i3ez0QQ@mail.gmail.com>
References:	<CACwWb3DJsO8J_zAfcSLK=_4iviZy05ZiKj1TFMUUSA8nxO5TwA AT mail DOT gmail DOT com>
	<CAGde_xOFELRBJZ30utu1x+B-y+8Vo+EDGOKPLqyafO+i3ez0QQ AT mail DOT gmail DOT com>
Date:	Tue, 20 Nov 2012 10:14:44 -0900
Message-ID:	<CAC4O8c9Z3zmCeeeVU-=BpYTWv1J+3bBh-YcWyepV3U0nftf=gw@mail.gmail.com>
Subject:	Re: [geda-user] branches
From:	Britton Kerin <britton DOT kerin AT gmail DOT com>
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, Nov 20, 2012 at 1:44 AM, Svenn Are Bjerkem
<svenn DOT bjerkem AT googlemail DOT com> wrote:
> On 20 November 2012 11:24, Levente <leventelist AT gmail DOT com> wrote:
>> I have some slightly off topic question.
>>
>>
>> How the branches are treated? If we make some commit to the stable-1.8 will
>> it ever be merged to the master? When do we fork a new branch? If we make a
>> change to the master, how they going to go to the stable-x.y branch?
>
> I am not a dev, but I am using git at work, and I got into the same
> thought for my own one-man git use.
> Since git is so powerful and can be used in so many ways, I just copy
> this link again.
> http://nvie.com/posts/a-successful-git-branching-model/
>
> It is a model with some supporting git overlay, but it is also a nice
> discussion on what problems distributed programmers may face.

That is a good system, especially worth mentioning is --no-ff.  I like the
approach that goes a step farther and has every developer named Bob make
a branch called Bob off whatever he's working on.  Then you don't have to
rebase but can actually have the main repository reflect what's actually
happened, which is the whole point of version control.  Then you don't get
this situation:

1.  Bob clones
2.  Bob edit-compiles-debugs
3.  Bob rebases, which breaks something that he doesn't catch
4.  Bob pushes
5.  Its a hard mess to sort out since you don't have any working version with
    Bob's changes in the canonical repository

Britton

- Raw text -