Branch by feature - Advantages/disadvantages?

Question

I'm currently working in a project where branching and merging haven't been working very well at all from the start. In order to change this, we've been talking about loads of different ways to do it. I assume everyone have there own philosophy about how to do this kind of stuff, and so it seems to be here as well.

One thing we've been talking about is to branching by feature. We happen to have very different views at whats good and bad with this particular method.

Do you have experience of doing this before? Did it work well? Did you have issues - what kind of issues?

I know this question wont really have a correct answer, but I find it very interesting to hear the opinions of other developers around the world, and stackowerflow seems to be a great spot for that.

Answer 1

We use branch by feature and it works very well for us. The biggest advantage is that the feature teams know that what they are working on does not affect the other feature teams until the new feature is integrated (into Main in our case).

When we are finished with a new feature (and the branch has been merged to Main) we move the branch into a Branch History folder. This keeps the numebr of branches (folders) the developers need to look at to a minumum.

In our case, no one works in the Main branch. All development is done in a feature branch. Initial development (before the first release to Production) is done in a development branch. After the first realease to Production all development is done in a new Feature Branch.

Answer 2

If you have a small-medium team then avoid extra branches when you don't truly need full branch isolation... especially if your dev team's culture is averse to branching and merging properly. Perhaps in exchange for fewer branches to maintain make sure merging practices are followed religiously by all developers who are allowed to do merges. Shelvesets (in TFS) and short-lived feature branches are good techniques to minimize merge overhead and related risks.

DETAILS

Here's a pattern I've found to balance productivity with version control safety (for team of ~25 devs and ~3 testers):

1. Work in same branch: Developers working on loosly coupled or unrelated code can work directly in the same Dev (or "Integration") branch relatively safely. Bugfixes and non-breaking changes nicely fit here (lower risk of major regressions impacting other devs). Continuous Integration builds and gated builds are two best practices that mitigate risk of many devs working in the same branch. Toggle Note: Feature toggles can be used to further avoid need to branch, but make sure overhead to test/maintain the toggle behavior isn't riskier than using a branch.

2. Shelvesets: Use your version control system's feature to save pending changes in developer-specific proto-branches. Developers checking in to TFS (Team Foundation Server) can use shelvesets instead of personal branches (or many micro-feature/task branches) if they are the only one who needs to develop and test the feature before checking in to the integration/dev branch. I believe other version control systems have similar constructs ANTIPATTERN: Local workspace(s) automatically provide temporary isolation for each developer... but developers need to check in their changes frequently/daily somewhere in source control to prevent risk of losing days+ of local-only work.)

3. Short-lived branches: When you do need a branch for isolation (such as for a breaking feature that multiple developers need to work on) then creating short-lived feature branches is one good way to go. I recommend a branch naming convention that keeps branch use well defined and unique over time.

The primary advantage of the above workflow is that it minimizes the merge tax (time spent Integrating forward/reverse (merging down/up)) instead of developing features that directly improve customer happiness.

Example Scenario: The new "Cool" feature will break existing functionality and builds until completed. It also requires 2+ devs to collaborate on same codebase (eliminating option to use Shelveset). Dev owner for "Cool" Creates branch named Cool1, then develop & integration test the first version of feature. Dev owner is responsible for merging parent changes daily (weekly at absolute most). Confirm ready to merge (Parent merged do child (FI), all UT and core Acceptance Tests run and still pass). Merge to parent (RI), then confirm works in parent branch (all UT and core Acceptance Tests pass), then delete the Cool1 feature branch (cleanup).
Test the Cool feature more thoroughly after merged to dev/integration branch. (Test resources are limited so avoid full test environment for each branch.) Bugfixes and tactical enhancements/refactoring for Cool would are done directly in the Dev branch (using shelvesets when assigned dev needs many days to localy dev/test before checkin). If major (multi-developer) rework of Cool is needed later then create a new Cool2 branch.

TFS2010 move/rename Note: TFS 2010 move and rename behavior changed (from TFS 2008) to make moves and Renames = "branch to new name/location, then mark original item as deleted". This means you should just delete the inactive feature branches if you don't want to see them in source control \Dev\ instead of moving the branch to a different folder. This also means developers that enable viewing deleted folders will always see these deleted (or moved or renamed) short-lived branches as "ghosts" which can get cluttered. (That's how you can view history or undelete a deleted item.)