如何用3个永久分支通过GitHub的rebase and merge实现线性Git历史？

问题根源 #

你遇到的重复提交问题，本质是GitHub的「rebase and merge」功能在处理已有独立提交历史的分支时，会将源分支的提交重新应用到目标分支顶部，而非直接移动分支指针。比如当staging之前有过自己的提交（哪怕是之前合并过来的），后续development有新提交后，用「rebase and merge」会把development的新提交在staging上重新生成一遍，导致历史重复。

可行解决方案 #

1. 快进合并（Fast-forward Merge）：让staging与development完全同步 #

如果staging仅作为预发布镜像分支，没有自己的独立修改（比如不需要在staging上做临时修复），最直接的方式是使用快进合并，让staging直接指向development的最新提交：

• 本地操作：

  git checkout staging
  git merge development --ff-only
  git push origin staging
  

• GitHub上设置：在仓库的「Settings」→「Branches」→「Branch protection rules」中，针对staging分支关闭「Require a pull request before merging」（如果开启的话），或者确保合并时选择「Merge pull request」中的快进选项（当满足快进条件时，GitHub会默认提供）。

2. 本地Rebase+强制推送：处理staging有独立提交的场景 #

如果staging偶尔需要做临时修改，但最终要与development保持线性历史：

1. 确保本地仓库是最新状态：

   git fetch origin
   

2. 切换到staging分支并基于development重定基：

   git checkout staging
   git rebase origin/development
   

3. 解决可能出现的冲突，完成rebase后强制推送（使用--force-with-lease比直接--force更安全，避免覆盖他人未推送的修改）：

   git push origin staging --force-with-lease
   

注意：执行强制推送前，必须通知团队成员不要在staging分支上工作，避免他们的本地提交被覆盖。

3. 直接重置staging到development提交 #

如果staging的所有修改都已经合并回development，或者不需要保留staging的独立历史，可以直接重置分支：

git checkout staging
git reset --hard origin/development
git push origin staging --force-with-lease

这种方式能确保staging与development完全一致，历史100%线性，但会丢弃staging的独立提交（需确认这些提交已无价值）。

分支策略优化建议 #

为了长期维持线性历史，建议明确各分支的职责：

• development：所有特性分支的目标合并分支，仅通过「rebase and merge」接受特性分支的提交，保持自身历史线性。
• staging：预发布分支，仅作为development的镜像或临时预发布验证分支，不保留独立提交历史，每次迭代结束后直接同步development的最新状态（用快进合并或重置）。
• main：生产分支，从staging同步时同样使用快进合并或重置，确保生产分支历史完全线性。

内容的提问来源于stack exchange，提问作者Joaquin Leimeter