我们有以下设置：三个应用程序相似，公共代码提取到一个框架中。每个应用程序都在自己的git仓库中进行管理，并将框架作为git子模块包含在内。
问题在于，这些应用程序现在是并行开发的，框架中添加的新功能其他应用程序不需要立即支持。目前，我们为所有应用程序拥有不同的框架分支。一种应用程序使用框架的主分支，因为大多数情况下新功能首先在该应用程序中引入。
框架分支：
- 主分支（由App A使用） - App B - App C
当在App B中引入了一个需要对框架进行更改的新功能时，这些更改被加入到App B分支中。如果稍后这些更改在App A中也需要，那么就将App B分支合并到主分支中。这意味着必须将App B中的所有更改合并到主分支中。
这个系统虽然可行，但存在一些缺陷：
- 从一个分支合并一个功能意味着我们必须合并所有更改 - 很容易失去追踪已经合并或将要合并的内容 - 使用提交消息来标记破坏性更改，这使得最后一点变得更加重要
我们目前正在寻找新的工作流。我考虑拥有以下分支：
- 主分支 - App A - App B - App C
因此，每个应用程序都有一个分支和一个包含所有更改的主分支。当开发新功能时，应该创建一个功能分支，然后将其应用于主分支以及需要立即使用该功能的所有应用程序分支。其他应用程序可以在稍后需要该功能时合并该功能分支。
我认为这样存在以下问题：
- 如何将一个功能分支合并到多个分支中，并仅合并在该分支中发生的更改。我知道“git rebase onto…”但我不确定是否可以多次使用此命令。 - 对于将功能合并到多个分支中，是否应该使用git cherry-pick？我宁愿不这样做，因为我认为如果没有选择在功能分支中进行的所有更改，那么这将容易出现错误。 - 如何跟踪哪个特性（分支）已被应用于哪个应用程序。我可以使用“branch --no-merge”，还是只能在分支具有相同祖先的情况下才能使用？
我的提议是实现这个的最佳方式，还是应该彻底重新思考我的策略？
问题在于，这些应用程序现在是并行开发的，框架中添加的新功能其他应用程序不需要立即支持。目前，我们为所有应用程序拥有不同的框架分支。一种应用程序使用框架的主分支，因为大多数情况下新功能首先在该应用程序中引入。
框架分支：
- 主分支（由App A使用） - App B - App C
当在App B中引入了一个需要对框架进行更改的新功能时，这些更改被加入到App B分支中。如果稍后这些更改在App A中也需要，那么就将App B分支合并到主分支中。这意味着必须将App B中的所有更改合并到主分支中。
这个系统虽然可行，但存在一些缺陷：
- 从一个分支合并一个功能意味着我们必须合并所有更改 - 很容易失去追踪已经合并或将要合并的内容 - 使用提交消息来标记破坏性更改，这使得最后一点变得更加重要
我们目前正在寻找新的工作流。我考虑拥有以下分支：
- 主分支 - App A - App B - App C
因此，每个应用程序都有一个分支和一个包含所有更改的主分支。当开发新功能时，应该创建一个功能分支，然后将其应用于主分支以及需要立即使用该功能的所有应用程序分支。其他应用程序可以在稍后需要该功能时合并该功能分支。
我认为这样存在以下问题：
- 如何将一个功能分支合并到多个分支中，并仅合并在该分支中发生的更改。我知道“git rebase onto…”但我不确定是否可以多次使用此命令。 - 对于将功能合并到多个分支中，是否应该使用git cherry-pick？我宁愿不这样做，因为我认为如果没有选择在功能分支中进行的所有更改，那么这将容易出现错误。 - 如何跟踪哪个特性（分支）已被应用于哪个应用程序。我可以使用“branch --no-merge”，还是只能在分支具有相同祖先的情况下才能使用？
我的提议是实现这个的最佳方式，还是应该彻底重新思考我的策略？