Branch setup when features are interrelated

Question

Say we have a a web app under git. We are doing localization, so we have a long running topic branch 'loc'. We are also doing a new skin that would go with the l10n, so we have a long running topic branch 'skin'.

We would like to have separate branches for each, but the issue is that the two features are entangled. When you do l10n work, the length of the translated messages and other things affects the skin. Likewise if you make changes to the skin, that might require some modifications to messages or other l10n features. From another angle: when we make changes in 'loc' and we want to test, we would like to have recent working copy of 'skin', and the other way round.

So how to best handle this situation - do we just use a single branch, do we make both branches feed into an intermediate branch 'skin-plus-loc' where we do the tests then merge into dev, do we keep merging the tips of the two branches into each other maybe? or do we keep merging dev into them? What's the best practice for handling such case.

Answer 1

Branches serve many useful purposes, but for this discussion, I'm going to separate them into two categories:

• Bugfix branches aggregate a series of loosely related bugfixes and improvements.
• Feature branches, or topic branches, isolate work on a feature until it is ready to be merged.

Coming up with a decent branching strategy means looking at the work being done and discerning where these changes should live. In my view, it sounds like your localization work is independent (changes don't depend on one another) and stable (changes don't break the build), making it a prime candidate for a bugfix branch.

On the other hand, it sounds like the skinning work more resembles a feature; the work being done is closely related and possibly unstable. As a result, I'd consider using a feature branch.

Let me pretend I'm right in the above assessment and outline a strategy for you:

Solution: Rebase off of your bugfix branch

This solution is optimal assuming the following conditions are met:

• Rebasing is possible and allowed. If only one developer is working on a branch, this is allowed by default. However, if there's several developers, it can be hazardous to use rebasing unless you can guarantee rebasing will always be trivial.

• The bugfix branch remains "clean" as often as possible. The site should build from any point in the bugfix branch. If development is too unstable to allow this, then this isn't a good solution.

• The bugfix branch does not depend on the feature branch. If there's a lot of coupling between the two efforts, then rebasing will be painful and this solution should be avoided.

If you can meet all these requirements, then this can be a very clean and advantageous scenario. Non-semantic merges (i.e., those done just to update to today's work) are eliminated, and the commit history is very clear. Since the bugfix branch is stable, it can be used as the root for other features.

Finally, when the time comes to merge the topic into the bugfix branch, it will occur effortlessly as a fast-forward. I like to disable fast-forwarding in this case, so the merge and branch remains in the commit history to provide evidence of the developed feature.

Problem: Rebasing isn't possible/allowed

If you have multiple developers working on branch, and it's not possible to ensure that rebases will not require manual merging, then rebasing is hazardous.

To avoid this problem, you should consider using branches of a smaller scope; instead of having a localization branch, have a "localize personal settings" topic branch and a "localization plumbing" bugfix branch. The motivation behind this is to meet the conditions of the solution above: small branches can be tackled by a single developer, small branches are generally easier to rebase, and small features can be completed and shared quicker than bigger ones.

It may seem counter-intuitive that introducing more branches will simplify your development. However, it's analogous to refactoring one dual-purpose function into two single-purpose ones.

Problem: The bugfix branch isn't clean, or it depends on the feature branch

The solution to this problem is the same as the previous one: use more branches. If there's dependency, then you should ask yourself why that's the case: Should we be committing to a feature branch instead of the bugfix branch? Is the bugfix branch trying to encompass too much?

Branches should have a distinct purpose and lifespan. If a branch starts having multiple purposes, the advantages of using version control are diminished. It's better to have two or three finely tuned branches than one fuzzy one.

Aside: Why repeated merging is bad

Merging repeatedly is likely what will happen by default. Each branch is kept separate and merges are used to update one with progress that occurs in the other. There's no need to isolate work, since it will be shared regularly.

The problems associated with repeated merging tend to made this alternative untenable. The history will be polluted with merges that have no semantic value. Repeated merging will also force developers in one branch to be intimately aware of changes in the other branch, obviating the possibility to use it as a root for other features.

If repeated merging seems like the only option, you may want to consider using only one branch and be done with it. It's possible that current development is so intertwined that having one branch right now makes more sense. As things settle down, it will become possible to separate them again if that seems prudent.

Answer 2

See "When should you branch".

Branch are for isolating a development effort, allowing to have separate tasks evolving independently one from another.

If your two tasks (skin and localization) are tightly linked, they should be in the same branch. And separate from the dev branch.