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

Git is way better then TFS. I have been using git for over 7 years now and used TFS before that. Recently I changed my job where I have to use TFS. Just having a dev branch and all developers working on the same dev does not allow any proper review opportunity. I love the fact that in git code review is a formal process.

With git i have worked on local branch by creating feature/workitem related branches. After you have with your work you can then push it to your remote branch. From the remote branch then you will do a pull request to your dev/integration branch. Once the pull request is reviewed then reviewer will merge the PR to dev branch. This has worked for me very nicely.

Answer 2

The more teams working on the merge target with their own branches the better your communication will need to be to deal with conflicts.

Be wary of high churn, coupled, and common areas in your code. Those will be the areas of contention.

Branch by feature can be done effectively in TFS, but as with anything in dev the more complex you get the more overhead you incur.

Answer 3

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

Answer 4

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 5

An alternative to branches for features would be feature toggles (ie a switch in the code that can make a feature available or not). They can be really useful in this regard. They can allow new features to be developed and deployed, but only available once the toggle is...well toggled (is that even a word). I imagine it is something like the whole google labs idea.

The point to note here, is that these toggles can also cause dramas in themselves if they aren't carefully considered and tested during development. You are in effect increasing the amount of testing you need to perform to see how things behave with a feature enabled and disabled. If you have multiple features under development, then you need to see how they all interact with various combinations of enabled/disabled states.

Having said that, if done well, they offer great benefits too. You can release a feature to certain users (power users, or champions of the feature etc) without affecting everyone. If it is deemed to be causing problems, it could be turned off via a change in DB record of presence of some configuration element.

Once a given feature is deemed to have passed muster, it is advisable to remove the toggle and just make it part of the overall application.

Having said that, I don't think that feature branching is bad, but it does rely on everyone understanding the concept of source control and merging and ensuring that branches don't get too out of line with the main branch causing one massive OMG type merge.

I recently attended a conference hosted by Thoughtworks where Martin Fowler discussed this very topic. The talk was focused on Continuous Delivery and how this can help overcome slow and risky deployments. See http://www.thoughtworks.com/events/thoughtworks-continuous-delivery-devops or just do a search for continious delivery for more info.