Version control problems in multi version project

Question

Background

We have a game operating in three different regions, so it's three different versions of release branches that checkout from one master branch, let's say branch_jp, branch_us, branch_tw(call them release branches), and the master.

Usually new features are developed on the master branch, and merged into release branches. But not all features are needed by every release branches - that's decided by some operating needs etc - so it takes some effort to merge the changes of master branch to them.

The problem

We used Subversion to do the version control, recently we decided to move to Git.

The problem is what we did in subversion when merging code is to pick the commits from master that this branch needs and merge into it, like what is shown below:

• commitA1
• commitA2
• commitB1
• commitB2
• commitA3

If branch_jp needs featureA, what we do is picking out commitA&Bs and merge them into branch_jp, if branch_us just need featureB we just pick out commitBs.

Since we have moved to Git, assume that all features are developed at feature branches from master, and merged into release branches. The problem is that we can't go like this:

master → featurebranch → master → branch_jp/tw/us

or

master → featurebranch → branch_jp/tw/us

              ↓
            master

because the feature branch is checkout from the master, so former features that were not merged into release branches would be merged this way.

I know there's a command 'cherry-pick' may do the same trick, but I wonder if there's some more 'Git-y' ways to handle the situation?

Furthermore, is there a more common/nicer/elegant work flow to handle this 'multi release version codes' situation?

Answer 1

I’ve worked in places that have this issue. While it’s a tough thing to deal with, I would not recommend the cherry-pick workflow that @Marina proposed in her answer. The reason I wouldn’t recommend it is that git cherry-pick breaks the connection between the original commit and the cherry-picked one, so Git’s history analysis won’t work as well.

IMHO you have two better alternatives, both of which have the advantage that they preserve commit identity and thus make the source tree easier to reason about.

1 (smaller change from status quo but perhaps a bit tedious).

Change your branching model. Master (if it even exists at all) shouldn’t contain all features, but only the core features that are in all three releases. If a feature is only supposed to be in one release, then only merge it into that one branch. In other words, your release process should be one of picking features to include, not ones to remove.

2 (bigger change, more effort up front but will make future development easier).

Rethink your architecture. Instead of three versions of the code to maintain, release only one version of the application, and factor out the differences into configuration files or plugins. If you can do this, you’ll probably see benefits to your code quality, not just your ease of version control.

I would strongly recommend option 2 if at all possible.

Answer 2

git cherry-pick (as you know) is the correct and common way for this situation.

Since you need to pick different of features for different release branches, you should not use git merge command since git merge will merge all the changes into release branches.

And for cherry-pick commit to different release branches, you can follow the situations you need:

• Apply changes only for a single feature:

  You should cherry-pick the commit from the feature branch. Such as apply the changes from featureA to branch_jp, you should cherry-pick the latest commit fromfeatureA` branch.

• Apply changes for all the released features:

  You just need to cherry-pick the commit from the last merged commit. Such as apply the changes from feature A and B to branch_us, then you just need to cherry-pick the latest merged commit on `branch_us.