分支提交差异问题解决及GitHub合并方式选型咨询

背景 #

长期基于feature分支开发新功能，完成后合并至测试环境的working分支；发布时通过GitHub Pull Request的「Squash and merge」方式将working分支合并到master分支。当前创建PR时，始终显示「This branch is 4 commits ahead, 73 commits behind working」，且所有提交都会被列出。

问题1：拟执行的命令是否正确？ #

你给出的命令可以解决当前master分支落后于working分支的问题，具体分析如下：

git checkout master
git pull working master
git push origin master 

• git checkout master：切换到本地master分支
• git pull working master：拉取远程working分支的内容并合并到本地master，等价于git fetch working + git merge working/master，会生成一个合并提交
• git push origin master：将更新后的本地master推送到远程仓库

执行后，远程master分支会同步working分支的所有提交历史，PR中「behind」的提示会消失。但此操作会在master分支产生一个合并提交，若追求完全线性的提交历史，可考虑先将master变基到working分支再推送（需注意权限及协作场景）。

问题2：未来选用哪种GitHub合并方式避免此类问题？ #

先将可选方式翻译为中文：

• 创建合并提交：将分支所有提交通过合并提交添加至基准分支
• 变基并合并：将分支的提交变基后添加至基准分支

推荐选用创建合并提交：
之前使用「Squash and merge」时，会将working分支的多个提交压缩为一个新提交合并到master，导致master与working的提交历史完全脱节——working保留了所有开发提交，而master仅存在压缩后的单一提交，因此每次PR都会显示master落后于working大量提交。

「创建合并提交」会保留working分支的完整提交历史，通过一个合并提交将其合并到master，合并后master包含working的所有提交记录，两者历史保持对齐，后续再创建PR时不会出现大量「behind」的提示。

若选择「变基并合并」，虽能得到线性的master历史，但需要额外将working分支变基到更新后的master分支，否则working的旧提交历史仍会与master脱节，操作成本更高，不适合当前的协作流程。

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