git-request-pull 教程

一句话理解

git request-pull 生成一段文本摘要，告诉维护者“请从这个基线拉取我这个分支的改动”。

什么时候适合用

• 邮件列表或传统补丁协作流程
• 无法直接开平台 PR 的仓库
• 需要明确说明 base、仓库地址与变更范围

典型命令

git request-pull origin/main https://example.com/repo.git feature/my-change

输出通常包含：

• 基线提交
• 目标仓库 URL
• 变更摘要与提交列表

这条命令不是做什么的

• 不是自动创建 GitHub/GitLab PR
• 不是自动推送分支
• 不是自动通知维护者

它只生成“可发送的拉取说明文本”。

推荐流程

1. 先确保分支已推送到可访问远端
2. 用 request-pull 生成摘要并人工校对
3. 再通过邮件或约定渠道发送

!基线写错会直接误导评审范围

request-pull 的可用性高度依赖 base 选择。基线不准，维护者看到的比较范围就会偏移。

常见误区

git request-pull 生成一段纯文本摘要，告诉维护者应该从哪个 URL 拉取哪些提交。理解它时，要明确它只生成描述文本，不发起任何平台的 pull request，也不修改本地仓库。

误区 1：把它当平台 PR 替代按钮

它是文本摘要工具，不是平台 API。

• 向维护者发送拉取请求时，用 git request-pull 生成一段包含拉取 URL、起始点和提交范围的说明文本。
• 把生成的摘要直接粘贴到邮件或协作平台中，让维护者可以手动执行 git pull 来拉取你的改动。
• 在邮件列表协作模式中，作为 format-patch / send-email 之外的另一种提交改动的方式。

误区 2：分支没推送就发 request-pull

维护者无法拉取到你描述的对象。

输入

起始提交远端 URL结束分支

→git request-pull

结果

纯文本拉取请求摘要

这条命令不修改本地仓库，只输出文本，维护者收到后需要自行执行 git pull。

误区 3：摘要不校对直接发送

base 或 URL 有误会增加维护者沟通成本。

• 这条命令生成的是"请求摘要"文本，不是自动发起 GitHub/GitLab 的 PR，需要结合团队实际协作渠道使用。
• 指定的起始提交必须在维护者可以访问的远端上可见，否则对方无法拉取。
• 执行前最好确认你的远端仓库已经 push 了相关分支，且 URL 是维护者有权限访问的。
• 输出的摘要可以直接粘贴到邮件正文中，维护者通常只需要复制其中的 git pull 命令即可执行。

接下来建议继续看什么

1. git-send-email
2. git-format-patch
3. fork upstream sync