Git分支合并后反复显示领先/落后master的无限循环问题

• 这个循环不是故障，是合并PR时默认的合并策略导致的正常现象，不需要过度紧张。
• 如果你创建orm分支只是为了开发单次功能，合并PR后这个分支就已经完成使命了，那个1 commit behind master的提示完全可以忽略，最干净的做法是直接删除这个废弃分支。

整个流程的提交逻辑非常清晰：

1. 初始阶段你从master切出orm分支，提交1个功能提交后推送到远端，此时orm比master多1个独有提交，提示1 commit ahead of master，和你预期一致。
2. 你创建PR合并orm到master时，GitHub默认采用「创建合并提交（merge commit）」的非快进合并策略，合并完成后master分支会新增一个独有的合并提交，这个提交不存在于orm分支的提交历史中，因此系统判定orm比master少1个提交，弹出1 commit behind master的提示。
3. 你按照提示创建PR把master反向合并回orm时，会再次在orm分支上生成一个新的独有合并提交，这个提交不存在于master的历史中，orm就会回到1 commit ahead of master的状态，反复操作就会形成无意义的循环。

• 针对单次功能开发的临时分支：合并完PR确认功能已经进入master后，直接删除本地和远端的orm分支即可，完全不需要处理落后提示，长期留存已经合并完成的临时分支只会干扰后续分支管理。
• 针对需要长期保留的常驻分支（比如固定的环境分支、集成分支）：合并PR后不要通过提PR反向合并的方式同步代码，在本地切换到orm分支后执行git rebase master，将分支提交变基到最新的master节点后强制推送到远端，不会产生多余的合并提交，也就不会出现循环提示。
• 如果想从根源避免这个问题，合并PR时可以选择「Rebase and merge」或者「Squash and merge」选项，这两种合并方式不会生成额外的合并提交，合并完成后master和orm会指向同一个提交节点，自然不会出现领先/落后的提示。

不要在两个分支之间反复互相合并，这类操作只会生成大量无意义的合并提交，把仓库提交历史搅得混乱不堪，没有任何实际价值。

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