“git request-pull"和“pull request"的区别 [英] Difference between 'git request-pull' and 'pull request'

问题描述

什么是 git request-pull 和它与发出 pull request 相比如何，例如在 github 上?

What is git request-pull and how does it compare to making a pull request, e.g. on github?

1.它应该如何使用?

2. 它可以用作拉取请求的替代品吗(例如在 github 上)?

2. Can it be used as replacement for pull requests (e.g. on github)?

3.使用它有什么好处?

推荐答案

git request-pull 命令早于托管服务.如评论中所述，它适用于倾向于包括运行 git format-patch 和 git send-email 以通过电子邮件传递补丁的工作流程.一旦补丁经过测试和批准，补丁生成器可能会在他们或他们的公司提供的公共服务器上访问提交，并向项目维护者发送最终的电子邮件消息，宣布他们已经清理、重新定位、等，准备合并的项目主题.

The git request-pull command predates hosting services. As noted in comments, it's meant for a workflow that tends to include running git format-patch and git send-email to pass patches around via email. Once the patches have been tested and approved, the patch-generator might make the commits accessible on a public server that they or their company provide, and send a final email message to the project maintainer announcing that they have the cleaned-up, rebased, etc., project-topic ready for merging.

例如，假设一个名叫 Phil Systeme 的人有一个文件系统的 Linux 内核补丁.他有一个 Linux 内核树的克隆，从一些 Linux 版本开始.他的补丁包括对十几个文件的一次巨大提交，他将这些文件发送到文件系统维护列表，并附有一个主题行:

For example, suppose a guy named Phil Systeme has a Linux kernel patch for a file system. He has a clone of the Linux kernel tree, as of some Linux release. His patch consists of one giant commit to a dozen or so files, which he sends to the file-system maintenance list, with a subject line:

PATCH: make the foo file system better

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

The feedback on the file-system maintenance mailing list first says: break this into at least six smaller parts. Phil Systeme breaks up his Phile System patch into eight logical smaller patches, each of which does something useful and still builds. He sends out 9 messages this time:

[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 cpu 需要一种特殊的东西，而 MIPS CPU 需要一种不同的特殊东西.于是他发出第三轮 [PATCH v3 m/n] 消息，依此类推.

This time, he gets feedback that says it looks better but he forgot to account for the fact that ARM cpus require one special thing and MIPS CPUs require a different special thing. So he sends out a third round of [PATCH v3 m/n] messages, and so on.

最终，文件系统维护副官同意应该加入这个补丁.现在 Phil 或副官将通过电子邮件发送的补丁转换为实际的 Git 提交，应用于当前的开发内核或维护内核，管他呢.在这一点上，Linus Torvalds 足够信任这个人，这个人可以说:这是一个 Git 存储库，其中包含您应该添加到内核中的新提交."然后，Linus 可以直接从这个其他存储库中 git pull，或者更有可能的是，从那里 git fetch 并决定是否以及如何合并它们，或者是否侮辱这个人.:-)

Eventually, the file system maintenance lieutenant(s) agree that this patch should go in. Now Phil, or the lieutenant, converts the emailed patches to actual Git commits, applied to a current development kernel, or to a maintenance kernel, or whatever. Linus Torvalds trusts this person enough at this point that this person can say: "here is a Git repository with new commits that you should add to the kernel." Linus can then git pull directly from this other repository, or more likely, git fetch from there and decide whether and how to merge them, or whether to insult the person. :-)

GitHub 和 Bitbucket 等托管服务声称、感觉或您喜欢这里的任何动词，他们的拉取请求"机制优于所有这些电子邮件.在某些方面，它很明显是；但是他们对隐藏实际提交图的热情(如果您要使用真正的合并，这确实很重要)对我来说有点神秘.

Hosting services like GitHub and Bitbucket claim, or feel, or whatever verb you like here, that their "pull request" mechanism is superior to all this email. In some ways, it pretty clearly is; but their enthusiasm for hiding the actual commit graph, which really does matter if you're going to use a true merge, is kind of a mystery to me.

这篇关于“git request-pull"和“pull request"的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！