问题描述
在Git中遇到了一个需求，他们的项目非常大，分为核心功能和扩展功能。现在需要将核心功能和扩展功能分别分配给不同的开发团队来开发。用户希望能够创建如下的分支结构：核心功能将在core_branch分支上开发，扩展功能将在extended_branch分支上开发，并且在extended_branch分支上执行git pull命令时，能够自动拉取core_branch分支上的任何提交。用户已经了解了git rebase和git merge的用法，但无论使用哪种方法，扩展团队/开发人员都需要检查核心分支上的任何新提交，并将其合并/变基到extended_branch分支上。用户希望找到一种方法来减少这种合并的复杂性。同时，他们关注在团队协作中避免分支合并带来的麻烦和不稳定性。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1 – 使用Trunk-Based Development（TBD）和特性标志（Feature Flags）
Trunk-Based Development（TBD）是一种开发方法，强调在主干（master或main）上进行开发，避免多个长期存在的分支，减少分支合并的复杂性。在这种方法中，特性的开发通过特性标志来控制。特性标志允许你在主干上持续集成新特性，但这些特性在运行时可以启用或禁用，以便保持主干的稳定性。
以下是在Git中实现TBD和特性标志的步骤：
1. 在master（或main）分支上创建一个特性标志，用于控制核心功能的开发。
2. 开发团队根据需要创建分支来实现核心功能，但这些分支应该基于主干。
3. 当核心功能开发完成时，将其合并到主干。
4. 扩展功能团队基于主干创建一个分支，用于扩展功能的开发。
5. 使用特性标志控制是否启用核心功能的代码。
6. 在扩展功能分支上执行git pull时，它会拉取主干上的最新代码，包括核心功能的更新。
方案2 – 使用”分支抽象”（Branch by Abstraction）方法
分支抽象是一种用于处理代码演进和升级的方法。它允许你通过引入抽象层来逐步改进代码，而不是直接在分支上进行大规模的合并。这种方法可以帮助减轻合并带来的压力，尤其是在核心功能和扩展功能之间有重叠的情况下。
以下是在Git中实现”分支抽象”的步骤：
1. 在主干上创建一个抽象层，该抽象层用于兼容核心功能和扩展功能。
2. 开发团队基于主干创建分支，分别用于核心功能和扩展功能的开发。
3. 在核心功能分支上，逐步引入抽象层，并确保核心功能仍然正常运行。
4. 在扩展功能分支上，基于引入抽象层的代码进行开发。
5. 当核心功能和扩展功能都完成开发并经过测试时，将它们合并到主干上。
这两种方法都可以帮助减轻分支合并的复杂性，但需要在团队中明确沟通和协作。同时，要根据项目的具体情况和团队的偏好选择适合的方法。