为什么要更新分支
目标分支前进之后，落后的分支会因为「必须与目标分支同步」的保护规则被挡住。平台通常提供更新分支的操作，可以页面上一键完成，也可以本地变基之后再推送。更新之后必需检查要重新跑一遍，评审也可能需要重新确认。
基本信息
| GitHub 操作 | 请求页面上的更新分支按钮，可选合并或变基方式 |
|---|---|
| GitLab 操作 | 页面上的变基按钮，或本地变基后强推 |
| 结果 | 重新触发必需检查，评审可能需要重新确认 |
| 替代方案 | 用合并队列代替手工反复同步 |
典型使用场景
- 主干前进之后分支落后，合并按钮不可用
- 保护规则要求分支与目标分支保持同步
- 用变基式更新让历史保持线性
- 需要在新主干之上重新跑一遍检查
- 排查「为什么这条请求一直不能合并」
本地做法
本地做法
git fetch origin # 取最新的目标分支
git rebase origin/main # 把当前分支重放到最新主干
git push --force-with-lease origin feature/login # 安全强推同步后的分支
gh pr view 128 --json mergeStateStatus # 确认已经不再落后两种更新方式
| 方式 | 做法 | 影响 |
|---|---|---|
| 合并式更新 | 把目标分支合并进当前分支 | 分支里产生反向合并提交 |
| 变基式更新 | 把当前分支重放到目标分支上 | 提交哈希变化，历史保持线性 |
频繁手工更新会产生大量中间状态；团队可以改用合并队列，让平台在合入前自动完成同步与检查。
变基式更新会改写提交，已经批准的状态可能因此失效，需要重新请求评审，或按团队约定处理。
处理步骤
- 先确认阻塞原因确实是分支落后，而不是检查失败或缺少批准
- 按需要选择更新方式：要线性历史用变基，要保留分支拓扑用合并
- 更新之后等必需检查重新跑完，再请评审人确认一遍
- 把反复出现的同步需求交给合并队列处理，减少手工操作