适用于不同版本框架的Git工作流程

Question

We have the following setup: Three apps which are similar to each other with the common code extracted into a framework. Each app is managed in their own git repository and includes the framework as a git submodule.

The problem is that the apps are now developed in parallel with new features being added to the framework that other apps don't need to support right away. Currently we have different branches of the framework for all apps. One app uses the master branch of the framework because most of the time new features were first introduced in this app.

Framework branches

• master (used by App A)
• appB
• appC

When a new feature is introduced in appB that needed changes in the framework these changes were made to branch appB. If these changes were later needed in App A, branch appB was merged into master. This means that all changes in appB had to be merged into master.

This system worked but had some flaws

• merging a feature from one branch to another meant we had to merge all the changes
• easy to loose track what had been merged already or what is going to be merged when merging one branch into another
• Marking breaking changes was done using commit messages, which made the last point even more important

We are currently searching for a new workflow. I was think about having the following branches

• master
• appA
• appB
• appC

So for each app one branch and a master branch that includes all the changes. When new features are developed a feature branch should be created and then applied to master as well as to all app branches the feature is needed right away. Other apps can merge the feature branch when they need the feature later on.

I see the following problems with this

• How can I merge a feature branch onto multiple branches and only merge the changes that happened in the branch. I know of "git rebase onto ..." but I am not quite sure if I can use this command multiple times.
• Should I use git cherry-pick for merging features into multiple branches? I would rather not do this, because I can think that this will be error prone when not selecting all changes that were made in a feature branch
• How to keep track of which feature(branch) had been applied to which app. Can I use branch --no-merge or will that only work if the branches have the same ancestor?

Is my purposed way the best way to accomplish this or should I rethink my strategy completely?

Answer 1

As explain in " Git & Working on multiple branches ", the two practical solutions when applying commits to multiple branches (which is what you would do with your "feature branches" option) are:

• merge (which should allow you to keep reusing that feature branch, as it would keep track of what has already been merge to a specific banch): a rebase --interactive might be in order for you to re-order the commits, putting first the ones you want to merge, and then the ones you are nnot ready yet to merge.
• cherry-picking (and it now supports a range of commits ), but I always have been wary of cherry-picking .