如何使用 Git 扩展处理拉取请求？
我在 github 上有一个公共存储库，我在使用内部 GitExtensions 处理拉取请求时遇到问题。到目前为止我已经做了 3 个，但我认为它们中的任何一个都没有正常工作或达到我想要的效果。
19 日，我尝试处理 Yi Jiang 创建的拉取请求。在 GitExtensions 中，我在 GitExtensions 中进行了拉取，放入远程存储库，选择 master 作为远程分支，并将将远程分支合并到当前分支作为默认值。我点击“Pull”，它完成了，没有错误。我清理了一些东西，然后我在 GitExtensions 中进行了推送。它没有填写提交消息，这让我感到惊讶，所以我只是扔了易江提交的 URL，因为我不知道还能做什么。结果是，它显示为一对提交，一个来自 Yi Jiang 作为作者，一个来自我作为作者。
19 日晚些时候，我尝试处理 Michael 创建的拉取请求。由于很明显我做错了第一个，所以我寻找另一种选择。我运行了此处找到的第一组命令，这似乎效果很好。唯一的问题是我必须通过命令行而不是在 GitExtensions 中完成此操作。
来自 Yi Jiang 的另一个拉取请求。由于上次通过 GitBash 而不是 GitExtensions 似乎有效，所以我再次尝试。但这一次，由于存在合并冲突，它无法完成。好的，所以我转到 GitExtensions 并进行合并，因为我知道这会让我解决冲突。因此，我打开“合并分支”对话框，选择
合并，然后选择 Yi Jiang 的主分支，留下如果可能，保留一条分支线（快进）。我解决冲突并推动。它会自动为我添加提交消息。这显示为 4 个条目，其中 3 个来自 Yi Jiang 作为作者，1 个来自我作为作者。似乎不对。
所以我的问题是，我应该如何正确地做到这一点？我有另一个拉取请求，我想确保我正确处理它。分叉队列表示它不会完全应用，所以我预见我需要进行合并。我想确保我正确合并，并且分支和提交都归因于完成这项工作的人。如果需要进行编辑，我是否应该先进行合并/推送，然后仅使用单个分支进行第二次提交？这对解决合并的需要有何影响？
有人可以完成在 GitExtensions 中正确处理拉取请求的确切过程吗？
I have a public repository on github that 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.
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 branch as 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.
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.
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 leavingKeep 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.
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?
Could someone walk through the exact process of correctly handling a pull request in GitExtensions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
#1 听起来很正常 - 第一个是来自您拉入的分支的提交，第二个是合并提交（实际上将分支合并在一起）。合并提交是由
git pull的任何人完成的 - 但是如果你查看gitblame中的文件，你会发现所有的blame行都是原作者的（除非解决冲突，否则合并提交实际上不会添加责任线）。出于同样的原因，#3 似乎也很正常 - 合并添加了一个实际合并分支的单个提交。
我对 #2 的猜测是，那里的拉取请求实际上是快进的，因此不需要合并提交，而 #1 和 #3 不是快进的（即使它们确实合并了）如果没有冲突，他们就不是你的
HEAD的直接后代）。基本上，我认为你实际上做得对，即使看起来有点奇怪。 :)
如果您想要更详细地解释快进和合并之间的差异，请参阅其他人的话：
（来自 http://cworth.org/hgbook-git/tour/）
编辑
我去了并查看了 Github 上的实际存储库。最后两次拉取（#2 和#3）似乎工作正常，并且完成了应该做的事情 - 在#2 的情况下快进，并在#3 中合并（添加了合并提交）。
我不太确定 #1 发生了什么 - 不知何故，部分更改似乎被您放入了单独的提交中？如果不了解当时实际做了什么，就无法更好地判断。也许您有未提交的更改，并且您在没有注意到的情况下提交了这些更改？
#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 ingit 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).#3 also seems normal for the same reason - merging adds a single commit that actually merges the branches.
My guess with #2 is that the pull request there actually was a 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 direct descendants of the your
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:
(From 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.
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?