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

Question

我们有以下设置：三个相似的应用程序，将公共代码提取到框架中。每个应用程序都在自己的git存储库中进行管理，并将框架作为git子模块包含在内。

问题在于，应用程序现在与并行开发的新功能被添加到框架中，其他应用程序不需要立即支持。目前，我们为所有应用程序提供了不同的框架分支。一个应用程序使用框架的主分支，因为大多数时候新功能首次在此应用程序中引入。

框架分支

• master（由App A使用）
• appB的
• APPC

当在appB中引入需要更改框架的新功能时，会对分支appB进行这些更改。如果以后需要在App A中进行这些更改，则将分支appB合并为master。这意味着appB中的所有更改都必须合并为master。

这个系统有效，但有一些缺陷

• 将功能从一个分支合并到另一个分支意味着我们必须合并所有更改
• 在将一个分支合并到另一个分支时，容易松散跟踪已经合并的内容或将要合并的内容
• 使用提交消息标记重大更改，这使得最后一点变得更加重要

我们目前正在寻找新的工作流程。我考虑过拥有以下分支机构

• 主
• 的appA
• appB的
• APPC

因此，对于每个应用程序，一个分支和一个包含所有更改的主分支。在开发新功能时，应创建功能分支，然后将其应用于主分支以及所有应用分支，立即需要该功能。其他应用程序可以在以后需要该功能时合并功能分支。

我看到了这个

的以下问题

• 如何将功能分支合并到多个分支上，并且只合并分支中发生的更改。我知道“git rebase into ...”但我不太确定我是否可以多次使用此命令。
• 我应该使用git cherry-pick将功能合并到多个分支中吗？我宁愿不这样做，因为我认为如果不选择在功能分支中进行的所有更改，这将是容易出错的。
• 如何跟踪哪个功能（分支）已应用于哪个应用。我可以使用分支--no-merge，还是仅当分支具有相同的祖先时才能使用？

我的目的是实现这一目标的最佳方式还是我应该完全重新考虑我的策略？

Answer 1

正如“Git & Working on multiple branches”中的解释，将提交应用于多个分支时的两个实际解决方案（这是您对“功能分支”选项的处理方式）：

• 合并（这应该允许您继续重用该功能分支，因为它会跟踪已经合并到特定banch的内容）：rebase --interactive可能是为了让您重新订购提交，首先放置你想要合并的那些，然后你还没有准备合并。
• cherry-picking（现在supports a range of commits），但我总是have been wary of cherry-picking。