Git PR 使用 Squash and Merge 前，什么时候应该 Rebase？
先说结论 在 GitHub 中使用 Squash and Merge 合并 PR，并不意味着每个 PR 都必须先执行 rebase。 两者解决的问题不同： rebase：把当前分支重新接到目标分支最新提交之后，必要时顺便整理提交顺序。 Squash and Merge：合并 PR 时，把 PR 中的多个提交压缩成目标分支上的一个提交。 所以，是否需要 rebase，主要看分支是否落后、是否出现冲突、是否需要在合并前验证最新代码，而不是看 PR 里有多少个 commit。 一个常见的误区 很多人看到 PR 里有这样的提交记录： feat: add login page fix: adjust login style fix: handle empty password WIP 于是认为合并前必须执行： git rebase -i HEAD~4 其实，如果仓库最终使用 Squash and Merge，GitHub 会在合并时把这些提交压成一个提交。上面的提交历史虽然不够整齐，但通常不会污染 develop 或 main 分支。 为了整理提交信息而 rebase，属于可选操作；为了让 PR 基于最新目标分支并通过测试，才是更常见、更有实际价值的 rebase 场景。 什么时候应该在合并前 Rebase？ 1. 目标分支已经有较多新提交 假设你的 PR 是从 develop 创建的： ...