git github：向现有拉取请求添加提交

github: Adding commits to existing pull request

提问by CuriousMind

I opened a pull request to railsrepo on github by using Fork & Edit this filefile button.

我使用Fork & Edit this filefile 按钮在 github 上打开了一个到railsrepo的拉取请求。

Now, After getting feedback on my PR, I wanted to add some more commits. so here is what I ended by doing

现在，在获得对我的 PR 的反馈后，我想添加更多提交。所以这就是我所做的

$ git clone [email protected]:gaurish/rails.git #my forked repo
$ git rebase -i 785a2e5 #commit hash of my commit using which PR was opened
$ git checkout patch-3 #branch name I had to send my commits under to be shown in that PR
$ git commit -am "Changes done as per feedback"
$ git push origin patch-3

This worked fine but seems quite a complex workflow. Maybe I am wrong something wrong here?

这工作正常，但似乎是一个相当复杂的工作流程。也许我错了这里有什么问题？

my question is: Am I doing this the correct way? if not, then what is the proper way to do this?

我的问题是：我这样做是否正确？如果没有，那么这样做的正确方法是什么？

采纳答案by Abe Voelker

Since you're using GitHub's tools and just changing one file, you could also browse to the fileon GitHub, select the proper branch from the upper left corner under the "tree:" dropdown (patch-3in your case), and now choose "Edit this file". Now your changes will be committed to this branch and will show up in your pull request

由于您使用的是 GitHub 的工具并且只是更改了一个文件，因此您还可以浏览到GitHub 上的文件，从左上角“树：”下拉列表（patch-3在您的情况下）下选择正确的分支，然后选择“编辑这个文件”。现在您的更改将提交到此分支，并将显示在您的拉取请求中

回答by Serge van Ginderachter

I just recently bloggedon this topic:

我最近刚刚写了一篇关于这个主题的博客：

How do we keep this feature branch up to date? Merging the newest upstream commits is easy, but you want to avoid creating a merge commit, as that won't be appreciated when pushed to upstream: you are then effectively re-committing upstream changes, and those upstream commits will get a new hash (as they get a new parent). This is especially important, as those merged commits would be reflected in your Github pull request when you push those updates to your personal github feature branch (even if you do that after you issued the pull request.)

我们如何保持这个功能分支是最新的？合并最新的上游提交很容易，但您希望避免创建合并提交，因为推送到上游时不会受到赞赏：然后您有效地重新提交上游更改，并且这些上游提交将获得新的哈希值（因为他们有了新的父母）。这一点尤其重要，因为当您将这些更新推送到您的个人 github 功能分支时，这些合并的提交将反映在您的 Github 拉取请求中（即使您在发出拉取请求后这样做）。

That's why we need to rebase instead of merging:

这就是为什么我们需要变基而不是合并：

git co devel #devel is ansible's HEAD aka "master" branch
git pull --rebase upstream devel
git co user-non-unique
git rebase devel

Both the rebase option and rebase command to git will keep your tree clean, and avoid having merge commits. But keep in mind that those areyour first commits (with whom you issued your first pull request) that are being rebased, and which now have a new commit hash, which is different from the original hashes that are still in your remote github repo branch.

git 的 rebase 选项和 rebase 命令都将保持您的树清洁，并避免合并提交。但请记住，那些是您的第一次提交（与您发出第一个拉取请求的人）正在重新定位，并且现在具有新的提交哈希，这与仍在远程 github 存储库分支中的原始哈希不同。

Now, pushing those updates out to your personal Github feature branch will fail here, as both branches differ: the local branch tree and the remote branch tree are “out of sync”, because of those different commit hashes. Git will tell you to first git pull --rebase, then push again, but this won't be a simple fast-forward push, as your history got rewritten. Don't do that!

现在，将这些更新推送到您的个人 Github 功能分支在这里将失败，因为两个分支不同：本地分支树和远程分支树“不同步”，因为这些不同的提交哈希。Git 会告诉你先 git pull --rebase，然后再推送，但这不会是一个简单的快进推送，因为你的历史被改写了。不要那样做！

The problem here is that you would again fetch your first changed commits as they were originally, and those will get merged on top of your local branch. Because of the out of sync state, this pull does not apply cleanly. You'll get a b0rken history where your commits appear two times. When you would push all of this to your github feature branch, those changes will get reflected on the original pull request, which will get very, very ugly.

这里的问题是，您将再次获取最初更改的提交，这些提交将合并到您的本地分支之上。由于不同步状态，这种拉动不能完全适用。您将获得一个 b0rken 历史记录，其中您的提交出现了两次。当您将所有这些推送到您的 github 功能分支时，这些更改将反映在原始拉取请求中，这将变得非常非常难看。

AFAIK, there is actually no totally clean solution to this. The best solution I found is to force push your local branch to your github branch (actually forcing a non-fast-orward update):

AFAIK，实际上没有完全干净的解决方案。我发现的最佳解决方案是强制将您的本地分支推送到您的 github 分支（实际上是强制进行非快速更新）：

As per git-push(1):

根据 git-push(1)：

Update the origin repository's remote branch with local branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository.

So don't pull, just force push like this:

所以不要拉，只是像这样用力推：

git push svg +user-non-unique

or:

或者：

git push svg user-non-unique --force

This will actually plainly overwrite your remote branch, with everything in your local branch. The commits which are in the remote stream (and caused the failure) will remain there, but will be dangling commit, which would eventually get deleted by git-gc(1). No big deal.

这实际上会用本地分支中的所有内容直接覆盖您的远程分支。远程流中的提交（并导致失败）将保留在那里，但将是悬空提交，最终会被 git-gc(1) 删除。没什么大不了。

As I said, this is AFAICS the cleanest solution. The downside of this, is that your PR will be updated with those newest commits, which will get a later date, and could appear out of sync in the comment history of the PR. No big problem, but could potentially be confusing.

正如我所说，这是 AFAICS 最干净的解决方案。这样做的缺点是，您的 PR 将使用那些最新的提交进行更新，这些提交将获得较晚的日期，并且可能会在 PR 的评论历史记录中出现不同步。没什么大问题，但可能会令人困惑。

回答by cfedermann

You could also create a new pull request which is bound to masterinstead of a specific abc1234revision.

您还可以创建一个绑定到master而不是特定abc1234修订的新拉取请求。

That way, any new commit/push to your repository will be added to the pull request.

这样，任何新的提交/推送到您的存储库都将添加到拉取请求中。

回答by Forrest

Yeah - you are doing a lot more work than you need to. Just make an additional commit and then force push it. You'll see the original commit as well as then newly pushed one when you refresh github in your browser.

是的 - 你做的工作比你需要的多得多。只需进行额外的提交，然后强制推送它。当您在浏览器中刷新 github 时，您将看到原始提交以及新推送的提交。

$ git commit -m "These changes are in response to PR comments"
$ git push -f origin HEAD