Gitflow模式下dev分支始终落后master分支的问题排查

这类问题本质是master分支的提交链上比dev多了1个无实际代码变更的独立提交，按出现概率从高到低排序，具体诱因如下：

• PR合并策略设置为非快进合并：如果代码平台上dev合入master的默认合并规则选了「创建合并提交」模式，哪怕dev的提交完全基于最新master，合并时也会自动生成一个新的merge commit挂在master的HEAD上。这个提交只记录合并动作，没有任何实际代码变更，所以反向提master到dev的PR时看不到文件差异，但提交节点本身真实存在，等于master比dev多了1个提交。每次合码后没把这个merge commit同步回dev，下次发版自然会提示dev落后1个提交。
• master分支绑定的CI/CD或服务端钩子自动生成空提交：很多团队会给master配置发版流水线，比如合码完成后自动更新版本号、生成CHANGELOG、打版本标记，如果这类逻辑存在缺陷（比如版本号变量未正确取值、CHANGELOG生成失败），就会往master推一个无实际文件变更的空提交；也有部分团队会特意在合码后推空提交作为发版节点标记，这类提交没有代码diff，但会占用一个提交位。
• 分支保护规则隐式生成新提交：如果master开启了强制签名提交、强制追加合码追溯信息这类规则，平台在合并PR时会重新生成带签名/追溯字段的新提交，不会直接复用dev分支上原有的提交节点，这个新生成的提交仅存在于master分支，不会自动同步到dev。
• 误操作推送空提交或强推：如果有管理员权限的成员不小心在master上执行git commit --allow-empty推送了空提交，或者做过分支重置后强推，导致master和dev的提交链出现单个节点的差异，也会触发这个问题。

按以下顺序排查，10分钟内即可定位根因：

1. 先定位多出来的提交属性
   本地拉取最新的远端master和dev分支，执行命令：

   git fetch origin
   git log origin/dev..origin/master --oneline
   

   命令输出的就是master比dev多的那1个提交，查看提交信息、提交作者、附带的文件变更：如果是平台默认生成的合并提交信息（比如Merge branch 'dev' into 'master'），就是合并策略配置问题；如果提交作者是CI机器人，就是流水线自动生成的提交。
2. 核对PR合并配置
   打开代码平台的仓库设置，找到dev到master的PR默认合并选项：
   • 如果当前选中的是「创建合并提交（Create a merge commit）」，即可确认是合并策略导致的问题。可以根据团队规范改成「快进合并（Fast-forward merge）」或者「变基合并（Rebase and merge）」，这两种模式不会在master上生成额外的冗余merge commit，从根源上避免问题。
   • 如果团队规范必须保留merge commit，那每次把dev合入master之后，必须把master反向合入dev一次，将新生成的merge commit同步到dev分支，不然下次发版一定会复现提示。
3. 排查流水线和钩子配置
   检查master分支绑定的所有合码后触发的流水线、服务端钩子脚本，查找是否存在自动执行git commit/push的逻辑，重点确认这类逻辑会不会在无文件变更的情况下执行提交操作，删掉无意义的空提交逻辑，必要的自动提交要补充同步回dev分支的步骤。
4. 核查分支审计日志
   通过代码平台自带的分支审计日志，查看master分支每一次提交的来源，确认是否存在非预期的人为推送、强推操作，收严master分支的推送权限，避免无关人员直接往master推提交。

内容的提问来源于stack exchange，提问作者Jack-of-some