Re: With feature branches, what is ever committed directly to master

[Jon Seymour <jon.seymour@gmail.com>]

On Wed, Aug 11, 2010 at 4:57 PM, Magnus Bäck
<magnus.back@sonyericsson.com> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>