评审期间的推送策略
评审期间怎么把新改动推上去，团队需要一套约定，核心是照顾评审人的阅读体验。常见做法是评审中只管追加提交（fixup 也可以），保留增量视图，让对方只看新增的变化；批准之后再整理历史（squash 或 rebase）合入。若确实需要强推，例如同步主干以消除冲突，要在 PR 里说明本轮改了什么并重新请求评审。
基本信息
| 推荐做法 | 评审中追加提交，合并前按仓库约定整理历史 |
|---|---|
| 强推影响 | 平台的增量对比可能重置，评审人需重新核对 |
| 沟通方式 | 推送后发一条本轮改动说明，列出主要变更点 |
| 仓库约束 | 部分仓库在平台上禁用了对 PR 分支的强推 |
| 判断顺序 | 先看仓库规则，再看评审人的实际需要 |
典型使用场景
- 处理评审意见时逐条追加提交，让对方只看增量
- 合并前把 fixup 与临时提交折叠成干净的提交
- 与主干出现冲突时用 rebase 同步，并在 PR 里说明范围
- 提交信息写错时用 amend 后强推（仅限自己的未合入分支）
- 团队要求线性历史时，在合并前统一变基
常用示例
常用示例
git add src/login.js # 暂存本轮改动
git commit -m 'fixup: 处理评审意见（限流边界）' # 追加提交，保留增量视图
git push origin feature/login # 正常推送，不改写历史
git rebase origin/main # 批准后同步主干
git push --force-with-lease origin feature/login # 安全强推，避免覆盖他人提交策略对照
| 做法 | 适用时机 | 对评审人的影响 |
|---|---|---|
| 追加提交 | 评审进行中 | 增量视图清晰，只需看新提交 |
| amend 后强推 | 仅修提交信息或极小改动 | 页面刷新后需重新核对 |
| rebase 同步主干 | 出现冲突或分支落后 | 差异范围变化，需要重看 |
| squash 整理 | 批准之后、合入之前 | 历史更干净，不影响已完成的评审 |
强推优先用 --force-with-lease：远端出现意外的新提交时它会拒绝推送，避免覆盖别人的工作；--force 没有这层保护。
有的仓库禁用了对 PR 分支的强推，动手前先看仓库设置。被禁用时，用追加提交加合并前 squash 同样能得到干净的历史。