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

How to handle pull requests with Git Extensions?

提问by Rebecca Chernoff

I have a public repository on githubthat I'm having trouble handling pull requests with inside GitExtensions. I've done 3 so far, and I don't think any of them have worked properly or worked where I want them to.

我在github上有一个公共存储库，但在处理 GitExtensions 内部的拉取请求时遇到问题。到目前为止，我已经完成了 3 个，我认为它们中的任何一个都没有正常工作或在我希望它们的地方工作。

1. On the 19th, I tried to handle a pull request that Yi Jiang created. In GitExtensions, I did a pull within GitExtensions, putting in the remote repository, selecting master as the remote branch, and leaving Merge remote branch to current branchas the default. I clicked Pull and it completed without error. There were a couple of things that I cleaned up, and then I then did a push in GitExtensions. It didn't fill in a commit message, which surprised me, so I just tossed in the URL of Yi Jiang's commit because I didn't know what else to do. The result was that it shows up as a pair of commits, one from Yi Jiang as an author and one from me as an author.

2. Later on the 19th, I tried to handle a pull request that Michael created. Since it seemed pretty clear that I did the first one wrong, I looked for another option. I ran the first set of commands found here, and this does seem to have worked great. The only problem is that I had to do it via the command line rather than within GitExtensions.

3. Another pull request from Yi Jiang. Since doing it via GitBash rather than GitExtensions seemed to work the last time, I tried it again. This time however, it wouldn't complete because there were merge conflicts. Ok, so I go to GitExtensions and do a merge because I know that will let me solve the conflicts. So, I open up the Merge branches dialog and select Merge withand select Yi Jiang's master branch leaving Keep a single branch line if possible (fast forward). I resolve the conflicts and do a push. It automatically put in the commit message for me. This shows up as 4 entries, 3 from Yi Jiang as the author, and 1 from me as the author. Doesn't seem right.

1. 19号，我尝试处理易江创建的一个pull request。在 GitExtensions 中，我在 GitExtensions 中做了一个 pull，放入远程存储库，选择 master 作为远程分支，并将Merge remote branch to current branch作为默认值。我点击了拉，它没有错误地完成了。我清理了一些东西，然后我在 GitExtensions 中进行了推送。没有填写commit message，这让我很意外，所以我只好把易江的commit URL扔进去，因为我不知道还能做什么。结果是它显示为一对提交，一个来自 Yijiang 作为作者，一个来自我作为作者。

2. 19 日晚些时候，我尝试处理 Michael 创建的拉取请求。因为很明显我做错了第一个，所以我寻找了另一种选择。我运行了在这里找到的第一组命令，这似乎效果很好。唯一的问题是我必须通过命令行而不是在 GitExtensions 中完成。

3. 来自易江的另一个拉取请求。由于上次通过 GitBash 而不是 GitExtensions 执行此操作似乎有效，因此我再次尝试。然而这一次，它不会完成，因为存在合并冲突。好的，所以我去 GitExtensions 并进行合并，因为我知道这会让我解决冲突。因此，我打开合并分支对话框并选择Merge with并选择 Yi Jiang 的 master 分支离开Keep a single branch line if possible (fast forward)。我解决了冲突并进行了推动。它会自动为我放入提交消息。这显示为 4 个条目，3 个来自 Yijiang（作为作者），1 个来自我（作为作者）。好像不太对

So my question is, how am I supposed to do this properly? I've got another pull request and I want to make sure I am handling it correctly. The fork queue says it won't apply cleanly, so I foresee that I'll need to do a merge. I want to make sure that I am merging properly and that the branches and the commits are being attributed to the people that did the work. If there are edits that need to be done, should I just do the merge/push first and then do a 2nd commit just with the single branch? How does this affect needing to resolve merges?

所以我的问题是，我应该如何正确地做到这一点？我有另一个拉取请求，我想确保我正确处理它。fork 队列说它不会完全应用，所以我预见我需要进行合并。我想确保我正确合并，并且分支和提交都归于完成工作的人。如果需要进行编辑，我是否应该先进行合并/推送，然后仅使用单个分支进行第二次提交？这对解决合并的需求有何影响？

Could someone walk through the exact process of correctly handling a pull request in GitExtensions?

有人可以完成在 GitExtensions 中正确处理拉取请求的确切过程吗？

采纳答案by Amber

#1 sounds normal - The first is the commit from the branch you pulled in, the second is the merge commit (that actually merges the branches together). The merge commit is by whoever does the git pull- but if you look at the files in git blame, you'll see that the blame lines are all for the original author (merge commits don't actually add blame lines unless you resolve conflicts).

#1 听起来很正常 - 第一个是来自您拉入的分支的提交，第二个是合并提交（实际上将分支合并在一起）。合并提交是由执行此操作的人进行的git pull- 但如果您查看 中的文件git blame，您会发现责备行都是针对原始作者的（除非您解决冲突，否则合并提交实际上不会添加责备行）。

#3 also seems normal for the same reason - merging adds a single commit that actually merges the branches.

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

My guess with #2 is that the pull request there actually wasa fast-forward, and thus no merge commit was necessary, whereas #1 and #3 were not fast-forward (even if they did merge without conflicts, they weren't directdescendants of the yourHEAD).

我对 #2 的猜测是那里的拉取请求实际上是快进的，因此不需要合并提交，而 #1 和 #3 不是快进的（即使它们确实没有冲突地合并，它们也不是您的) 的直系后代。HEAD

Basically, I think you're actually doing it right, even if it seems a bit odd. :)

基本上，我认为你实际上做对了，即使它看起来有点奇怪。:)

If you want a slightly more length explanation of the differences between fast-forward and merge, here's someone else's words:

如果您想对快进和合并之间的差异进行更详细的解释，这是别人的话：

On merges and "fast forward"

You'll notice that we've been seeing the phrase "fast forward" several times. This is a special-case operation performed by "git merge" where a branch can be advanced along a linear sequence. This happens whenever you pull changes that build directly on top of the same commit you have as your most recent commit. In other words, there was never any divergence or simultaneous commits created in parallel in multiple repositories. If there had been parallel commits, then "git merge" would actually introduce a new merge commit to tie the two commits together.

When a non-fast-forward merge occurs, there is always the possibility that a conflict occurs. In this case, "git merge" will leave conflict markers in the files and instruct you to resolve the conflicts. When you are finished, you would issue a "git commit -a" to create the merge commit.

关于合并和“快进”

您会注意到我们已经多次看到“快进”一词。这是由“git merge”执行的特殊情况操作，其中分支可以沿线性序列前进。每当您拉取直接构建在与最近一次提交相同的提交之上的更改时，就会发生这种情况。换句话说，在多个存储库中并行创建的提交从来没有任何分歧或同时提交。如果有并行提交，那么“git merge”实际上会引入一个新的合并提交来将两个提交联系在一起。

当发生非快进合并时，总是有发生冲突的可能性。在这种情况下，“git merge”将在文件中留下冲突标记并指示您解决冲突。完成后，您将发出“git commit -a”来创建合并提交。

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

（来自http://cworth.org/hgbook-git/tour/）

Edit

编辑

I went and looked at the actual repository on Github. The last two pulls (#2 and #3) seem to have worked properly, and done what should have been done - fast-forwarding in the case of #2, and merging (with an added merge commit) in #3.

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

I'm not quite sure what happened with #1 - somehow, it appears, part of the changes got put into a separate commit by you? Couldn't really tell better without having been able to look at what actually was done at the time. Perhaps you had uncommitted changes and you committed them without noticing?

我不太确定 #1 发生了什么 - 不知何故，看起来，部分更改由您单独提交？如果不能看看当时实际做了什么，就不能说得更好。也许您有未提交的更改并且您在没有注意到的情况下提交了它们？