With feature branches, what is ever committed directly to master

With feature branches, what is ever committed directly to master

[Bradley Wagner]

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?

Is "master" really even unstable at that point?

Thanks in advance! I realize this question is pretty open-ended.

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

[Michael Witten]

On Tue, Aug 10, 2010 at 14:02, Bradley Wagner
<bradley.wagner@hannonhill.com> wrote:
> 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?
>
> Is "master" really even unstable at
> that point?
>
> Thanks in advance! I realize this
> question is pretty open-ended.

See here:

  http://git.kernel.org/?p=git/git.git;a=blob_plain;f=MaintNotes;hb=todo

The `master' branch is indeed considered the most stable version of
the software when it comes to the way `git' itself is maintained.

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

[David Ripton]

On 08/10/10 15:02, Bradley Wagner 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?
>
> Is "master" really even unstable at that point?

If your repo is accessible to the public then I think it makes sense to 
have master be stable.  Because that's what people will see by default 
if they clone your repo, and you want to make a good first impression.

If it's a private repo that only insiders are allowed to see, then it 
doesn't matter as much.

Our team uses unstable master, which anyone on the team can push to.  If 
someone pushes to it then a build and tests automatically run, and if 
they succeed then that commit gets automatically pushed to the stable 
branch.  We let anyone create shared branches on the server if they want 
to collaborate on a feature.  We make a tag for each release, but we 
don't make a maintenance branch until we actually need it.

-- 
David Ripton    dripton@ripton.net

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

[Jon Seymour]

On Wed, Aug 11, 2010 at 5:02 AM, Bradley Wagner
<bradley.wagner@hannonhill.com> 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?
>
> Is "master" really even unstable at that point?
>
> Thanks in advance! I realize this question is pretty open-ended.

The project I am on is in test/fix mode at the moment.

In our workflow, we tend not to even bother with a shared master
branch. The build team maintains one, but it is for their own sanity,
not for sharing with the rest of the development team.

We do at least two team builds a day, the AM build ends with 10, the
PM build with 5 and patch builds, if required with the next available
unused number which is not 5 or 10. Each build is tagged with the
build number [ providing most of the convenience of an SVN commit id
].

Our developers tend to base their work on the latest released build
tag, except if it is a fix required to patch a build that has already
been delivered to a higher test environment, in which case the patch
is based on the build number of the code deployed into that
environment. This patch can usually then be trivially merged into
builds in lower environments as required.

Personally, I maintain several topic branches which are merged with
the upstream only in the event of the requirement to resolve a merge
conflict. Otherwise, I keep them clean and merge them into the base of
my working branch (as described into an earlier note).  By always
merging into the base of my working branch (and never the tip) I can
keep my working tree stable and my patches clean.

In my view, tag-based (rather than branch-based) sharing is a better
way to work when you have a large team. In a large team, the shared
branch is necessarily going to be highly unstable. The tags issued by
the build team help create a measure of stability and point of
reference in what would otherwise be a somewhat chaotic environment.

The single biggest mistake we made with git was to attempt to share
work throughout the team by having developers keep in sync by merging
with a shared master branch. Extracting a developers history from such
a tangle is a complete nightmare.

jon.

> --
> 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
>

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

[Magnus Bäck]

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

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

[Jon Seymour]

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
>

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

[Tim Visher]

On Tue, Aug 10, 2010 at 3:02 PM, Bradley Wagner
<bradley.wagner@hannonhill.com> 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?
>
> Is "master" really even unstable at that point?
>
> Thanks in advance! I realize this question is pretty open-ended.

Since no one mentioned it yet, I found this [paper][] to be an
incredible resource and it's the workflow my team has adopted.

[paper]: http://nvie.com/git-model

-- 

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ - Spend less time on e-mail

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

[Steven E. Harris]

Jon Seymour <jon.seymour@gmail.com> writes:

> Otherwise, I keep them clean and merge them into the base of my
> working branch (as described into an earlier note).  By always merging
> into the base of my working branch (and never the tip) I can keep my
> working tree stable and my patches clean.

Can you clarify what you mean by "merging into the base" and "never the
tip"? Perhaps a pointer to the earlier note you mentioned would suffice.

-- 
Steven E. Harris

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

[Jon Seymour]

On Sat, Aug 14, 2010 at 8:19 AM, Steven E. Harris <seh@panix.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> Otherwise, I keep them clean and merge them into the base of my
>> working branch (as described into an earlier note).  By always merging
>> into the base of my working branch (and never the tip) I can keep my
>> working tree stable and my patches clean.
>
> Can you clarify what you mean by "merging into the base" and "never the
> tip"? Perhaps a pointer to the earlier note you mentioned would suffice.
>

Here is a link to the earlier note:

     http://permalink.gmane.org/gmane.comp.version-control.git/153168

this explains how I am using the term base.

Informally, it is the first commit your history which contains work
that your current work depends on, but is not part of your current
work.
It is always directly reachable from your head via a path which does
not include a merge (and, as such, defines a linear range of commits
that is easily re-ordered or rebased as required).

The idea is that the base of your working branch accumulates
dependencies, while the head (or tip) of your working branch
accumulates your work. By merging at the base, you are never "hiding"
work in progress with a merge. As your view of what your dependencies
are changes, you can rebuild your base at will, and then rebase your
work on top of that.

jon.



> --
> Steven E. Harris
>
> --
> 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
>