我在 github 上有一个公共(public)存储库我在处理内部 GitExtensions 的 pull 请求时遇到问题。到目前为止，我已经完成了 3 个，但我认为它们中的任何一个都没有正常工作或在我希望它们工作的地方工作。
19 日，我尝试处理 Yi Jiang 创建的 pull 请求。在 GitExtensions 中，我在 GitExtensions 中进行了 pull ，放入远程存储库，选择 master 作为远程分支，并将 Merge remote branch to current branch 作为默认设置。我点击了 Pull，它没有错误地完成了。我清理了几件事，然后在 GitExtensions 中进行了推送。居然没有填写commit message，让我很意外，所以我就把易江的commit url扔进去了，不知道还能做什么。结果是它显示为一对提交，一个来自作为作者的易江，一个来自作为作者的我。
19 日晚些时候，我尝试处理 Michael 创建的 pull 请求。由于很明显我做错了第一个，所以我寻找另一种选择。我运行了找到的第一组命令 here ，这似乎确实奏效了。唯一的问题是我必须通过命令行而不是在 GitExtensions 中完成。
Yi Jiang 的另一个 pull 请求。由于上次通过 GitBash 而不是 GitExtensions 似乎有效，所以我再次尝试。然而这一次，它不会完成，因为存在 merge 冲突。好的，所以我转到 GitExtensions 并进行 merge ，因为我知道这会让我解决冲突。因此，我打开“merge 分支”对话框并选择
Merge with并选择 Yi Jiang 的主分支离开Keep a single branch line if possible (fast forward)。我解决冲突并 push 。它会自动为我放入提交消息。这显示为 4 个条目，3 个来自作者易江，1 个来自作者本人。好像不太对。
所以我的问题是，我应该如何正确地执行此操作？我有另一个 pull 请求，我想确保我正确处理它。 fork 队列说它不会干净地应用，所以我预见到我需要进行 merge 。我想确保我正在正确 merge ，并且分支和提交都归因于完成工作的人员。如果需要进行编辑，我是否应该先进行 merge/推送，然后仅对单个分支进行第二次提交？这对解决 merge 的需求有何影响？
有人可以详细介绍在 GitExtensions 中正确处理 pull 请求的确切过程吗？
最佳答案
#1 听起来很正常 - 第一个是来自您 pull 入的分支的提交，第二个是 merge 提交(实际上将分支 merge 在一起)。 merge 提交是由执行 git pull 的人完成的 - 但如果你查看 git blame 中的文件，你会发现 blame 行都是针对原作者的(除非您解决冲突，否则 merge 提交实际上不会添加 blame 行)。
出于同样的原因，#3 看起来也很正常 - merge 添加了一个实际 merge 分支的提交。
我对 #2 的猜测是那里的 pull 请求实际上是快进，因此不需要 merge 提交，而 #1 和 #3 不是快进(即使它们确实在没有冲突的情况下 merge ，它们不是您的 HEAD 的直接后代。
基本上，我认为您实际上做对了，即使看起来有点奇怪。 :)
如果你想对快进和 merge 之间的区别进行更详细的解释，这是别人的话:
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.
(来自http://cworth.org/hgbook-git/tour/)
编辑
我去查看了 Github 上的实际存储库。最后两次 pull (#2 和 #3)似乎工作正常，并且完成了应该完成的工作 - 在 #2 的情况下快进，在 #3 中 merge (添加 merge 提交)。
我不太确定 #1 发生了什么 - 不知何故，你似乎将部分更改放入了单独的提交中？如果不能够看到当时实际做了什么，就无法真正说得更好。也许您有未提交的更改并且在没有注意到的情况下提交了它们？
关于git - 如何使用 Git 扩展处理 pull 请求？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3993751/