如何使用Git扩展处理拉请求？

Question

我在github上有一个公共存储库，在处理GitExtensions内部的拉请求时遇到了问题。到目前为止，我已经做了3次了，我不认为他们中的任何一个都工作正常，或者在我想要的地方工作。

1. 十九号，我试着处理奕江提出的拉动请求。在GitExtensions中，我在GitExtensions中执行了一次拉动操作，放入远程存储库，选择主服务器作为远程分支，并将合并远程分支保留给当前分支作为默认设置。我点击拉，它完成了没有错误。我清理了几件事情，然后我在GitExtensions上做了一个推送。它没有填写一条提交信息，这让我很惊讶，所以我只是抛出奕江提交的URL，因为我不知道还能做什么。其结果是，它表现为一对承诺，一个来自奕江作为一个作者，一个来自我作为一个作家。
2. 十九号晚些时候，我试着处理迈克尔提出的拉请求。因为似乎很清楚我做了第一个错误，所以我寻找了另一个选择。我运行了第一组找到这里的命令，这看起来非常有效。唯一的问题是，我必须通过命令行而不是在GitExtensions中这样做。
3. 奕江的又一次拉扯请求。因为上一次通过GitBash而不是GitExtensions来做这个工作，所以我又试了一次。然而，这一次，由于存在合并冲突，它无法完成。好的，所以我去GitExtensions做一个合并，因为我知道这会让我解决冲突。因此，我打开合并分支对话框，并选择Merge with并选择奕江的主分支离开Keep a single branch line if possible (fast forward)。我解决冲突，做一个推动。它会自动为我输入提交消息。这是4个条目，其中3个来自奕江作为作者，1个来自我作为作者。似乎不对。

所以我的问题是，我应该如何正确地做这件事？我有另一个拉请求，我想确保我是正确的处理它。叉队列说它不会很干净地应用，所以我预见到我需要进行合并。我想确保我正在正确地合并，并且分支和提交都被归因于完成工作的人员。如果有编辑需要完成，我是否应该先进行合并/推送，然后只对单个分支执行第二次提交？这对解决合并的需要有什么影响？

有人能在GitExtensions中完成正确处理拉请求的准确过程吗？

Answer 1

#1听起来很正常-第一个是从您输入的分支提交的，第二个是合并提交(实际上是将这些分支合并在一起)。合并提交是由执行git pull的人进行的--但是如果您查看git blame中的文件，您将看到所有的指责行都是针对原始作者的(合并提交实际上不会添加指责行，除非您解决冲突)。

出于同样的原因，#3看起来也很正常--合并添加了一个实际合并分支的提交。

我对#2的猜测是，那里的拉请求实际上是一个快速转发，因此不需要合并提交，而#1和#3并不是快速转发(即使它们没有冲突地合并，它们也不是HEAD的直接后代)。

基本上，我认为你做得很对，尽管这看起来有点奇怪。:)

如果您想要更详细地解释快速转发和合并之间的区别，下面是其他人的话：

论合并与“快速前进” 你会注意到我们已经好几次看到“快进”这个词了。这是由"git合并“执行的一种特殊情况操作，其中一个分支可以沿着线性序列前进。每当您将直接构建在与最近提交相同的提交之上的更改提取时，就会发生这种情况。换句话说，从来没有在多个存储库中并行地创建任何差异或同时提交。如果存在并行提交，那么"git“实际上将引入一个新的合并提交来将两个提交连接在一起。 当发生非快速前向合并时，总是存在冲突发生的可能性.在这种情况下，"git合并“将在文件中留下冲突标记，并指示您解决冲突。完成后，您将发出一个"git提交-a“来创建合并提交。

(来自http://cworth.org/hgbook-git/tour/)

编辑

我去看了一下Github上的实际存储库。最后两个拉环(#2和#3)似乎工作正常，完成了应该做的事情--在#2的情况下进行快速转发，在#3中进行合并(添加了一个合并提交)。

我不太清楚#1到底发生了什么--看起来，部分更改是由您单独提交的吗？如果不能够看清楚当时到底做了什么，就不能说得更好。也许你有未提交的更改，而你没有注意到就提交了它们？