我们有以下设置:三个彼此相似的应用程序，将公共(public)代码提取到一个框架中。每个应用程序都在自己的 git 存储库中进行管理，并将框架作为 git 子模块包含在内。
问题在于，应用程序现在是与添加到框架的新功能并行开发的，而其他应用程序不需要立即支持这些功能。目前，我们为所有应用程序提供了不同的框架分支。一个应用程序使用框架的 master 分支，因为大多数时候新功能首先在此应用程序中引入。
框架分支
- master(由 App A 使用)
- 应用B
- 应用C
当在 appB 中引入新功能时，需要对框架进行更改，这些更改是对分支 appB 进行的。如果稍后在 App A 中需要进行这些更改，则将分支 appB merge 到 master 中。这意味着 appB 中的所有更改都必须 merge 到 master 中。
这个系统有效但有一些缺陷
- 将一个功能从一个分支 merge 到另一个分支意味着我们必须 merge 所有更改
- 在将一个分支 merge 到另一个分支时，很容易跟踪已经 merge 的内容或将要 merge 的内容
- 标记中断更改是使用提交消息完成的，这使得最后一点更加重要
我们目前正在寻找新的工作流程。我正在考虑拥有以下分支机构
- 大师
- 应用A
- 应用B
- 应用C
因此，对于每个应用程序，一个分支和一个包含所有更改的主分支。当开发新功能时，应创建一个功能分支，然后将其应用于 master 以及所有应用程序分支，立即需要该功能。其他应用可以在以后需要该功能时 merge 该功能分支。
我看到了以下问题
- 如何将一个功能分支 merge 到多个分支上，并且只 merge 分支中发生的更改。我知道“git rebase onto ...”，但我不太确定我是否可以多次使用此命令。
- 我应该使用 git cherry-pick 将特性 merge 到多个分支中吗？我宁愿不这样做，因为我认为如果不选择在功能分支中所做的所有更改，这将很容易出错
- 如何跟踪哪个功能(分支)已应用于哪个应用程序。我可以使用 branch --no-merge 还是仅当分支具有相同的祖先时才有效？
我有目的的方法是实现此目标的最佳方法还是我应该彻底重新考虑我的策略？
最佳答案
如“Git & Working on multiple branches”中所述，将提交应用到多个分支(这就是您将使用“功能分支”选项所做的)的两个实用解决方案是:
- merge(这应该允许您继续重用该功能分支，因为它会跟踪已经 merge 到特定分支的内容):
rebase --interactive可能是为了您重新排序提交，首先放置您想要 merge 的那些，然后是您尚未准备好 merge 的那些。 - cherry-picking (现在是 supports a range of commits )，但我总是 have been wary of cherry-picking .
关于不同版本框架的 Git 工作流程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9018254/