Comments on: Branch-Per-Feature Source Control. Part 1: Why

By: Jason

Jason — Thu, 13 Aug 2009 10:40:49 +0000

@Ben, check out this post on branch-per-feature with TFS. Maybe it’ll change your opinion ;)

http://staxmanade.blogspot.com/2009/08/branch-per-feature-with-team-foundation_06.html

By: Jeffrey

Jeffrey — Mon, 27 Jul 2009 03:50:26 +0000

I switched to Git about 6 months ago and I started doing BPF since the switch. Compare to svn git is so much (1 million ahead of the game) better than svn. Only complain is that I am a c# guy it’s a bit hard to get started on windows. I am using Git extentions as the GUI.

By: derick.bailey

derick.bailey — Fri, 17 Jul 2009 16:39:35 +0000

@ike,

since we don’t work directly on the trunk, we don’t have changes in the trunk every day. when someone does push changes into the trunk, though, they notify the team so that the team can pull updates into their branch. this will be discussed in more detail, in my next post

@charl,

my next post should help to address your issues of bug fixes, from a concept level. at a high level, you need to define the merge strategy for your team. what merges where, when, and how often, etc.

@Dale,

code reviews are part of the merge strategy that a team has to define. for my team, they happen before we allow merging back into the trunk

By: Dale

Dale — Fri, 17 Jul 2009 13:21:31 +0000

On the face of it, this seems like a great idea. It would have saved a lot of grief on the large project I was just on. I’m wondering, though, where code review fits in. Do you save code reviews for the merges?

By: charl

charl — Fri, 17 Jul 2009 13:13:08 +0000

Great article. I can’t wait for the next one in the series. I have also tried the feature branching in one of my Java projects with mixed success. Like Andy, I also had some issues with conflicts when merging back into the trunk and lost changes that I thought merge correctly.

I had a situation where I had 2 feature branches and while in the middle of that I also had to make a critical bug fix. My route I went was to always keep my trunk as the operational version so that you can do these kind of bug fixes in there and ALWAYS deploy from my trunk compilation and not from a branch.

So what do you send for QA and deployment, your feature branch or your trunk?

You face breaking your trunk and delaying bug fixes or face having testing a branch and when merging into the trunk causing issues.

By: Ike Casteleyn

Ike Casteleyn — Fri, 17 Jul 2009 12:48:31 +0000

I’m running into these problems aswell, however I think I have more problems on releasing.
Partially done work on the trunk and I need to be able to create a release from that trunk.
Could you talk a little about release too in a later post.

One other thing.
You branch per feature, so you don’t bring in any changes from others.
Does this mean that you don’t merge daily from the trunk to your branch too?

Best regards,
Ike

By: Adam D.

Adam D. — Thu, 16 Jul 2009 23:29:11 +0000

@Rob

For the database issue. Use a version script. In git you can use the attribute command to force a conflict if there’s any merging. You manually change it. It’s not hard. And you’re good to go. Most of the time the db changes are additive.

By: derick.bailey

derick.bailey — Thu, 16 Jul 2009 19:04:39 +0000

Thanks for the feedback everyone (including those on Twitter)! I’ve updated the article to include a section on the underlying principles, and have tried to make the “Benefits” more explicit by putting them into their own section after the “Cost”.

By: Ben Scheirman

Ben Scheirman — Thu, 16 Jul 2009 16:36:04 +0000

Thanks for the detailed post! I found it to be very informative. I’m leaning towards doing this on future projects.

One more reason not to use TFS I guess. Like I needed any more :)

By: Nathan Prather

Nathan Prather — Thu, 16 Jul 2009 13:11:17 +0000

Great article. I look forward to your discussion of branching and merging using Subversion.

Keep it up!

Thanks,
Nathan