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

From: Magnus Bäck <magnus.back@sonyericsson.com>
Date: Aug 11, 2010, 06:57 UTC
Message-ID: <20100811065751.GA8808@jpl.local>
In-Reply-To: <AANLkTin0VgH8CvnUn_tCJPTkhh7Ce-tYWo52qouoVvRN@mail.gmail.com>

On Tuesday, August 10, 2010 at 21:02 CEST,
     Bradley Wagner <bradley.wagner@hannonhill.com> wrote:

Show 11 quoted lines

> I realize there are a lot of different Git workflows but I'm wondering
> how others in this community do it.
>
> We're using our "master" branch from our central repo (Beanstalk) as a
> dev branch and we have stable branches for various release versions of
> our software.
>
> We've not made as heavy use of feature branches yet as we should have.
> Once we do start using them more regularly, what kind of stuff is ever
> committed directly to "master" or is master typically the place where
> things are merged into from other stable/features branches?

Feature branches are useful when stuff needs to be developed in isolation, e.g. code that will undergo significant changes (usually leading to instability) or code whose release schedule isn't set in stone. When you're ready to create a stable branch for a public release you don't want to have half a dozen half-finished features on master.

While isolation is useful it also brings problems. If you have dependencies between features you may run into integration problems far too late. People can merge between the feature branches to mitigate this, but that also creates a mess. Isolation also means that the code will be exercised less before released, i.e. less dog fooding. In some cases it makes sense to fulfill the goal of isolation by keeping changes on the master branch but use static or dynamic configuration of the software to disable the code or maybe use branch by abstraction.

In the case of creating a feature branch for the sake of securing the releasability of a branch one must also consider the conditions surrounding the release. Is the feature currently being developed on a feature branch a must-have for the release? If yes, one of the strongest arguments for feature branches becomes moot.

Finally, bugfixes and similar smaller changes that don't make up a whole string of commits should probably not be developed on branches.

> 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