如何将beta合并到main无额外提交？GitHub分支流程优化方案

我们的GitHub仓库包含main（对应生产服务器流水线）和beta（对应测试服务器流水线）两个分支，开发新功能时基于feature1分支进行。当前操作流程如下：

现有操作步骤 #

步骤1：开发功能并推送 #

git checkout feature1
# 进行代码修改
git add .
git commit -am "Feature is created"
git push origin feature1

步骤2：合并到测试分支 #

从feature1向beta创建Pull Request（PR），触发测试流水线验证通过后，执行：

git checkout beta
git pull origin beta

遇到的问题 #

当从beta向main或feature1向main创建PR时，会出现beta分支超前/滞后main分支1个提交的问题。

问题解答 #

1. 有没有办法将beta合并到main而不产生额外的合并提交？ #

有两种可行方案：

• 变基+快进合并：切换到beta分支执行git rebase main，把beta的提交移到main最新提交之后，再切回main执行git merge beta——此时属于快进合并，不会生成额外的合并提交。注意：如果beta是团队共用的公共分支，变基前必须同步所有成员，避免打乱他人的本地分支状态。
• Squash合并：在GitHub的PR界面选择「Squash and merge」，会把beta上的所有相关提交压缩成一个单一提交合并到main，同样不会产生传统的合并提交。

2. 避免上述问题的正确分支流程是什么？ #

推荐采用主干优先的流动式分支策略，核心逻辑如下：

• 所有功能分支（如feature1）必须从main分支拉取创建，而非beta分支，确保功能分支的基线与生产分支一致。
• 功能开发完成后，先向beta提交PR做测试验证；验证通过后，将feature1分支基于main最新版本变基（git rebase main），再向main提交PR合并。
• 明确beta的定位：如果是临时测试分支，每次测试完成后直接重置到main的最新状态（git reset --hard main）；如果是预发布分支，则仅接收已验证的功能分支合并，定期向main同步。

3. 这种分支方式维护生产与测试服务器是否合理？ #

这种分支模式本身是合理的，但当前流程的问题在于beta分支的定位模糊：如果beta仅作为测试临时分支却长期保留并积累提交，必然会导致与main的提交偏差。
若要继续使用该模式，需明确beta的角色：

• 若作为预发布分支：长期存在，仅合并已通过测试的功能分支，定期向main同步更新；
• 若作为临时测试分支：每次测试完成后重置到main状态，避免无关提交积累。

4. 如何通过PR将变更推送到测试和生产服务器，且不出现分支超前/滞后问题？ #

按以下标准化流程执行：

1. 从main拉取创建功能分支：git checkout -b feature1 main
2. 开发完成后，向beta提交PR，触发测试流水线；验证通过后，用Squash方式合并到beta（减少beta的提交数量）。
3. 准备上线时，将feature1分支变基到main最新版本：git checkout feature1 && git rebase main，解决可能的冲突。
4. 向main提交PR，合并后触发生产流水线。
5. 每次main更新后，同步beta到main状态：git checkout beta && git reset --hard main && git push origin beta --force（操作前需同步团队成员，避免本地beta分支与远程不一致）。

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