On Tuesday, August 10, 2010 at 21:02 CEST,
Bradley Wagner <bradley.wagner@xxxxxxxxxxxxxx> wrote:
> 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
--
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