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: References: Date: Tue, 20 Nov 2012 10:14:44 -0900 Message-ID: Subject: Re: [geda-user] branches From: Britton Kerin To: geda-user AT delorie DOT com Content-Type: text/plain; charset=ISO-8859-1 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 Precedence: bulk On Tue, Nov 20, 2012 at 1:44 AM, Svenn Are Bjerkem wrote: > On 20 November 2012 11:24, Levente 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