On Wed, Aug 11, 2010 at 4:57 PM, Magnus Bäck <magnus.back@xxxxxxxxxxxxxxxx> wrote: > Finally, bugfixes and similar smaller changes that don't make up a > whole string of commits should probably not be developed on branches. I think there is a case for _developing_ fixes on branches as opposed to _sharing_ fix branches. In particular, it is good to minimize the stuff that a fix drags along, so delivering a a fix to an integration stream which is depends on the minimum amount of other cruft is good practice. It also means the fix can easily be shared with other developers even if it hasn't yet mean integrated into the main integration stream. This is where the idea of maintaining a private working branch (described in an earlier e-mail) really pays off. You get to keep all your unintegrated fixes in your working tree, but you can freely share the stable ones with other developers and the integration stream without reduced fear of creating a merge nightmare, since you have taken care (in selecting the base for the fix) to keep each fix isolated. As to whether the team should maintain _shared_ feature branches this does, as you say, depend on your circumstances. By _shared_ feature branch, I mean a branch that has its own build cycle, test cycle etc. Such things are expensive, and they get more expensive the more complicated your delivery environment is. If your team and product is small and nimble, it doesn't cost much to maintain the several loosely coupled development processes. If it isn't, then you save a lot by having a single integration stream that everyone bases their work on since you can share that build and QA overhead across the entire team. jon. > >> Is "master" really even unstable at that point? > > I guess that depends on your organization, your developers, and the > maturity, architecture and inherent quality of the software. And, of > course, how you define unstable. How bad can it be before it hurts? > How would *you* weigh the risk of branching against the risk of > developer slowdowns caused by frequent regressions? > > -- > Magnus Bäck Opinions are my own and do not necessarily > SW Configuration Manager represent the ones of my employer, etc. > Sony Ericsson > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html