如何在无法rebase的长期feature分支下维护半线性Git历史？

核心思路 #

既满足主分支的线性历史要求，又允许长期协作分支内部保留自然的协作痕迹，同时把复杂的整理操作集中到少数人身上，降低全体开发者的学习成本，尤其是初级开发者。

具体操作流程 #

1. 分支分层设置

• 主分支（main）：严格保持线性历史，仅接受经过整理的、原子化的提交。
• 长期协作分支（如feature/xxx-long-term）：作为团队协作的中间载体，允许多人提交，通过git merge main同步主分支更新，内部无需强制squash或rebase，初级开发者只需掌握基础的commit和merge即可参与。
• 个人工作分支：每个开发者基于长期协作分支创建个人分支（如feature/xxx-alice），在个人分支上自由开发，完成后可选择：
  • 直接合并到长期协作分支：git checkout feature/xxx-long-term && git merge feature/xxx-alice（无需处理复杂操作）
  • 或自行squash个人提交后合并：git checkout feature/xxx-long-term && git merge --squash feature/xxx-alice（可选，适合想整理个人提交的开发者）

2. 长期分支合并主分支前的整理

当长期协作分支开发完成，准备合并到main时，由分支负责人（或指定的熟悉Git的成员）完成以下步骤：

1. 同步主分支最新代码到长期分支：

   git checkout feature/xxx-long-term
   git merge main
   

   （仅需负责人处理冲突，其他开发者无需参与）
2. 创建临时整理分支，基于主分支整理提交：

   git checkout -b feature/xxx-clean
   git rebase -i main
   

   在交互界面中，将长期分支的提交按功能模块/逻辑拆分，把相关的小提交squash或fixup成几个有意义的原子提交（无需全量squash成一个大提交），同时修正提交信息使其清晰准确。
3. 将整理好的临时分支推送到远程，发起PR合并到main分支。合并后main分支的历史依然保持线性，且提交都是清晰的功能单元。

团队协作规则（极简版） #

• 初级开发者只需：拉取长期分支代码→创建个人分支→开发→提交→合并到长期分支，无需掌握rebase等复杂操作。
• 长期分支负责人定期（如每周）合并一次main分支的更新，避免冲突积累。
• 整理提交时，负责人需和团队确认提交拆分的合理性，确保重要变更的痕迹不丢失。

内容的提问来源于stack exchange，提问作者Luca Sara Czudar