https://shawndeng.tech/tags/github/Recent content in GitHub on ShawnDeng's Tech BlogHugo -- 0.146.0zh-cnSat, 01 Aug 2026 18:04:00 +0800https://shawndeng.tech/posts/git-rebase-before-squash-merge/Sat, 01 Aug 2026 18:04:00 +0800https://shawndeng.tech/posts/git-rebase-before-squash-merge/<h2 id="先说结论">先说结论</h2> <p>在 GitHub 中使用 <strong>Squash and Merge</strong> 合并 PR，并不意味着每个 PR 都必须先执行 <code>rebase</code>。</p> <p>两者解决的问题不同：</p> <ul> <li><code>rebase</code>：把当前分支重新接到目标分支最新提交之后，必要时顺便整理提交顺序。</li> <li><code>Squash and Merge</code>：合并 PR 时，把 PR 中的多个提交压缩成目标分支上的一个提交。</li> </ul> <p>所以，是否需要 rebase，主要看分支是否落后、是否出现冲突、是否需要在合并前验证最新代码，而不是看 PR 里有多少个 commit。</p> <h2 id="一个常见的误区">一个常见的误区</h2> <p>很多人看到 PR 里有这样的提交记录：</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>feat: add login page </span></span><span style="display:flex;"><span>fix: adjust login style </span></span><span style="display:flex;"><span>fix: handle empty password </span></span><span style="display:flex;"><span>WIP </span></span></code></pre></div><p>于是认为合并前必须执行：</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>git rebase -i HEAD~4 </span></span></code></pre></div><p>其实，如果仓库最终使用 <strong>Squash and Merge</strong>，GitHub 会在合并时把这些提交压成一个提交。上面的提交历史虽然不够整齐，但通常不会污染 <code>develop</code> 或 <code>main</code> 分支。</p> <p>为了整理提交信息而 rebase，属于可选操作；为了让 PR 基于最新目标分支并通过测试，才是更常见、更有实际价值的 rebase 场景。</p> <h2 id="什么时候应该在合并前-rebase">什么时候应该在合并前 Rebase？</h2> <h3 id="1-目标分支已经有较多新提交">1. 目标分支已经有较多新提交</h3> <p>假设你的 PR 是从 <code>develop</code> 创建的：</p>