使用 git rebase --onto 更新堆叠的拉取请求
摘要
解释如何在父提交被压缩或替换时,使用 `git rebase --onto` 更新堆叠的拉取请求。
<p><a href="https://lobste.rs/s/akc6h4/updating_stacked_pull_requests_with_git">评论</a></p>
查看缓存全文
缓存时间: 2026/06/18 22:07
# 使用 git rebase --onto 更新栈式拉取请求
来源:https://bd103.dev/blog/2026-06-18-git-rebase-onto/
有时我会遇到这种情况:我有多个拉取请求,它们相互依赖。
然后,审阅者要求我将提交 B 合并到提交 A 中,创建一个新的提交 E。我照做了,但现在我的第二个拉取请求全乱了!
当 Git 创建提交 E 时,它没有告诉提交 B 的子节点,它们的新父节点应该是提交 E。这意味着提交 C 仍然认为它的父节点是提交 B!
虽然这种行为是合理的默认设定,但在这种情况下我们不希望这样。我们可以通过使用以下命令进行变基,告诉提交 C 它的新父节点是提交 E:
```bash
# 确保我们位于第二个拉取请求的分支上。
git switch second-pr
# 告诉提交 C,它的新父节点是 E,而不是 B。
git rebase --onto E B
```
该命令的一般形式是 `git rebase --onto <新基> <旧基>`,在更新栈式拉取请求(父提交已被替换)时非常有用。如果基础拉取请求只是新增了提交,则不需要使用此命令,此时只需使用不带 `--onto` 选项的普通 `git rebase`。
在完成第二个拉取请求的变基后,可以查看 `git push` 的 `--force-with-lease` 选项(https://git-scm.com/docs/git-push#Documentation/git-push.txt---force-with-lease),以安全地将更改推送到远程仓库。
*感谢 Stack Overflow 上的 sEver 提供的答案(https://stackoverflow.com/a/39081674)启发了这篇文章!*
相似文章
spr:GitHub上的堆叠拉取请求
spr 是一个 CLI 工具,可将 Git 分支上的每个提交转换为 GitHub 上的独立拉取请求,无需手动管理分支即可实现堆叠式 PR。
接受混乱的 git 历史
一篇博客文章,讨论两种 git 工作流理念——频繁提交与谨慎变基——并解释为何在大型团队中,鉴于团队的韧性,混乱的历史是可以接受的,文中还提到了 GitHub 的新堆叠 PR 功能。
@GergelyOrosz:实际上,关于堆叠差异(又称堆叠式拉取请求)这个概念,你需要了解的是,这篇深度文章写于……
Gergely Orosz 分享了 Pragmatic Engineer 关于堆叠差异的深度解析,解释了这一由 Meta 和 Google 推广的概念,以及 GitHub 新的公开预览如何使其更容易使用。
@github:现代化一个8年历史的代码库需要什么?堆叠(再堆叠)。
GitHub 重点介绍了 Cassidy Williams 的一篇博客文章,展示了 GitHub Copilot 应用中的堆叠会话和拉取请求如何帮助现代化一个已有8年历史的 React 代码库,演示了一种 AI 辅助的大型重构工作流程。
堆叠式拉取请求现已公开预览
GitHub 现已推出堆叠式拉取请求的公开预览,允许开发者将大型变更拆分为更小、更易审查的 PR,这些 PR 可独立审查并一键合并。