With feature branches, what is ever committed directly to master

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.

On Tue, Aug 10, 2010 at 14:02, Bradley Wagner <bradley.wagner@hannonhill.com> wrote:

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.

On 08/10/10 15:02, Bradley Wagner wrote:

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.

On Wed, Aug 11, 2010 at 5:02 AM, Bradley Wagner <bradley.wagner@hannonhill.com> wrote:

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.

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

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.

On Sat, Aug 14, 2010 at 8:19 AM, Steven E. Harris <seh@panix.com> wrote:

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.

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

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.

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?

On Wed, Aug 11, 2010 at 4:57 PM, Magnus Bäck <magnus.back@sonyericsson.com> wrote:

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.

On Tue, Aug 10, 2010 at 3:02 PM, Bradley Wagner <bradley.wagner@hannonhill.com> wrote:

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