On Sun, Aug 12, 2012 at 12:24 AM, Justin Mclean <jus...@classsoftware.com>wrote:
> Hi, > > > Why is using a local branch important? > When using git most branches are local and not shared between developers > unless it's needed (in my experience anyway). Although it easy to share > between people working on a large feature - have a look at the IDE dev on > github and yuo'll see that in action. > > > Is this because of a branching strategy or is there something about Git > that > > makes this easier? > Mostly github (easier to branch and merge) but you still need need the > right branching stategy and as it's easier to branch in git we are likely > to have more need to a branch structure/rule than if we used SVN. > Not necessarily because of the way merging is handled. The branching strategy is more about facilitating parallel development as opposed to trying to avoid merge conflicts, which is usually the motivator in SVN, not Git. > > I've had a deeper look at the gitflow branching structure and before we > vote on using we might want to think about: > - What branches are local/what are in the origin repo. Only 2 long lived > branches in the gitflow model (ie develop and master) are stored centrally. > That's correct, as well as tags of Release branches before they're merged back into trunk and dev, in case we need to perform a hotfix on a released version. > - Are we going to have issues with cherry picking fixes from develop into > master causing unstable releases? May want to consider what Linus has to > say on the issue on the issue https://lkml.org/lkml/2008/5/21/351 + > https://lkml.org/lkml/2010/11/12/291. (I do like the idea of stable and > next branches mentioned in the second email). > Well, you wouldn't be cherry picking from develop into master. The only way code gets into Master is from a Release branch. Release branches are made directly from Dev. Dev only contains code that has been added to the source either via a Hotfix branch or a Feature branch. When you're done with a Feature branch and its time to merge the code into Dev usually an 'Integration' branch is made locally in order to merge the Feature branch back into the an integration branch that is freshly made from Dev. This is where you make sure the Feature branch code doesn't break the stability of Dev, if it does the issues should be fixed in the temporary Integration branch and then merged back into Dev, at which point you can kill both the local Feature and Integration branches. > - Think carefully about the no fast forward option and it's effects. Look > at comments as it may be being incorrectly being used. Do we want it on by > default as suggested? > I get confused w/ this one, will get back to you on this one. :) - Do we want release branches to be short lived? Main issue this this is (I > think) is that's hard to patch issues in previous releases and means any > serious bug fix allways going the latest release forcing user of the SDK to > allway be on the latest version. I'm really not sure on this one. However > note than in Linux development has a stable branch for each release and not > a master as such ( see development model at > http://en.wikipedia.org/wiki/Linux_kernel). > Thanks, > Justin This is incorrect. Release branches are short lived, yes. However, before a release branch is killed off you MUST tag it. The whole purpose of the tag is to mark the point in time at which the Release branch was done being worked on and sent to Master. When you merge a release branch to Master its the equivalent of producing a release, that is why you must tag it "v.1.0.1". Then you kill the Release branch. If two weeks later a bug that must be fixed is needed, but new features are already being developed in Dev, then you create a Hotfix branch from the "v.1.0.1" tag and go to town fixing the emergency bug. Once that bug is ready to be deployed you can use it as a release branch to update version numbers, and do all the other things required for a release, tag it "v.1.0.2", merge it to Master, merge it to Dev, and destroy the Hotfix branch. So in short, you can make fixes to any version at any time. -omar
