'git request-pull'和'pull request'之间的区别是什么？

Question

'git request-pull'和'pull request'之间的区别是什么？

gitgithubversion-controlpull-request

13

git request-pull是什么，它与在github上发起pull request有何不同？

1.它应该如何使用？

2.它能否替代拉取请求（例如在github上）？

3.使用它的优点是什么？

- jschnasse

虽然它与GitHub / GitLab等上的PR工具不同，但其描述的第一行“生成请求，请求您的上游项目将更改拉入其树中。”听起来在想法上非常接近，唯一的区别是不需要协调的网站。运行命令，将stdout转储并通过电子邮件/博客文章等发送给某人。 - quetzalcoatl

拉取请求不是 Git 的一部分，而是托管服务的一部分。该命令无法创建拉取请求。它生成一个补丁，可用于将更改拉入存储库，此补丁需要通过邮件列表、电子邮件、讨论论坛或其他方式与存储库所有者进行沟通。 - Lasse V. Karlsen

我的猜测，当然是 Linus 和 Linux 内核的开发人员们？ - quetzalcoatl

Git书籍，章节“为项目做贡献”，段落“分叉公共项目” - 在此在线查看：https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project - 顺便提一下，它还描述了email/patch工作流程/命令，也非常有用。 - quetzalcoatl

因此，审查和讨论是通过邮件列表或问题跟踪器等方式完成的。我想知道是否有支持这种工作流程的工具，例如在Web界面中显示文本输出之类的。我的意思是，不需要重新发明拉取请求... - jschnasse

显示剩余3条评论

2个回答

2

1. 一个Pull Request支持通过由托管者提供的Web-UI（例如github、bitbucket）控制地将代码修改引入给定的代码库。示例。

2. git request-pull是一个git命令，它简化了在不依赖单个托管服务的情况下通过电子邮件贡献补丁的过程。示例。

+-----------------+--------------------------------+--------------------------+
|     操作          |           Pull Request         |       git request-pull   |
+-----------------+--------------------------------+--------------------------+
| 鉴权             |  在托管者处注册并登录           |  全名，签名电子邮件      |
| 描述             |  Web-Ui                        |  补丁，电子邮件          |
| 讨论             |  Web-Ui                        |  电子邮件，邮件列表      |
| 审查             |  Web-Ui                        |  电子邮件，邮件列表      |
| 引入             |  一个按钮“合并”操作            |  git pull/push           |
+-----------------+--------------------------------+--------------------------+

- jschnasse

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- torek · Accepted Answer

git request-pull 命令早于托管服务。正如评论中所指出的，它适用于一种工作流程，通常包括运行 git format-patch 和 git send-email 通过电子邮件传递补丁。一旦补丁被测试和批准，补丁生成器可能会在他们或其公司提供的公共服务器上使提交可访问，并向项目维护人员发送最后一个电子邮件消息，宣布他们有干净、合并等待的项目主题。

例如，假设一个名叫 Phil Systeme 的人有一个文件系统的 Linux 内核补丁。他有一个 Linux 内核树的克隆版本，截至某个 Linux 发布版本。他的补丁由十几个文件的一个巨大提交组成，他将其发送到文件系统维护列表，主题行为：

PATCH: make the foo file system better

在文件系统维护邮件列表上的反馈首先说：将其分成至少六个较小的部分。Phil Systeme 将他的 Phile 系统补丁分成了八个逻辑更小的补丁，每个补丁都会做些有用的事情，并且仍然可以构建。他这次发送了 9 条消息：

[PATCH v2 0/8]: make the foo file system better

(description of what the patch series is about)

[PATCH v2 1/8]: split up the xyzzy function

As a prerequisite for improving the foo file system, break
a large function into several smaller ones that each do one
thing.  We'll use this later to work better and add new features.

[PATCH v2 2/8]: ...

这次，他收到了反馈信息，说看起来更好了，但他忘记考虑ARM处理器需要一种特殊东西，而MIPS处理器需要另一种特殊东西。因此，他发送了第三轮的 [PATCH v3 m/n] 消息等等。

最终，文件系统维护负责人同意采纳这个补丁。现在Phil或者负责人将通过邮件收到的补丁转换为实际的Git提交，应用于当前开发内核、维护内核或其他位置。Linus Torvalds对此人已经有足够的信任，让此人可以说：“这里是一个新的Git存储库，您应该将它添加到内核中。” 然后，Linus 可以直接从这个存储库进行git pull，或者更可能地，从那里进行git fetch，并决定是否以及如何合并它们，或者是否侮辱此人。:-)

像 GitHub 和 Bitbucket 这样的托管服务声称，或者说感觉上，他们的“拉取请求”机制优于所有这些电子邮件。在某些方面，它非常明显；但是他们隐藏实际的提交记录图表的热情，如果你要使用真正的合并，这真的很重要，对我来说有点神秘。