我通过使用Fork＆Edit this file file按钮在github上打开了对rails repo的拉取请求。
现在，在获得有关我的PR的反馈之后，我想添加更多提交。所以这就是我结束时所做的
$ git clone git@github.com: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
这工作正常，但似乎是一个复杂的工作流程。也许我在这里错了吗？
我的问题是：我这样做正确吗？如果没有，那么正确的方法是什么？
Answers:
我最近才在这个话题上写过博客：
我们如何使此功能分支保持最新状态？合并最新的上游提交很容易，但是您要避免创建一个合并提交，因为将其提交到上游时不会被欣赏：您随后将有效地重新提交上游更改，并且那些上游提交将获得新的哈希值（因为他们有了新父母）。这一点特别重要，因为当您将这些更新推送到个人GitHub功能分支时，这些合并的提交将反映在GitHub拉取请求中（即使您在发出拉取请求后执行了这些操作）。
这就是为什么我们需要重新设置基础而不是合并：
git co devel #devel is ansible's HEAD aka "master" branch
git pull --rebase upstream devel
git co user-non-unique
git rebase devel
git的rebase选项和rebase命令都可以使您的树保持整洁，并避免合并提交。但是请记住，这些是您正在重新建立基础的第一次提交（您发出了第一个拉取请求），现在这些提交具有新的提交哈希，这与仍在远程github repo分支中的原始哈希不同。
现在，将这些更新推送到您的个人GitHub功能分支将在这里失败，因为两个分支都不同：由于那些不同的提交哈希，本地分支树和远程分支树“不同步”。Git会告诉您先进行git pull --rebase，然后再次进行推送，但这绝非易事，因为您的历史记录已被重写。不要那样做！
这里的问题是，您将再次获取原始更改的第一次提交，并且这些提交将合并到本地分支的顶部。由于处于不同步状态，这种拉动并不适用。您将获得一个破碎的历史记录，其中您的提交出现两次。当您将所有这些推送到GitHub功能分支时，这些更改将反映在原始的请求中，这将非常非常丑陋。
AFAIK，实际上没有完全干净的解决方案。我发现的最佳解决方案是强制将本地分支推送到GitHub分支（实际上是强制进行非快速更新）：
根据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.
所以不要拉，只需要像这样强制推：
git push svg +user-non-unique
要么：
git push svg user-non-unique --force
实际上，这实际上将覆盖本地分支中的所有内容，并覆盖您的远程分支。远程流中的提交（并导致失败）将保留在那里，但将是悬空的提交，最终将被git-gc（1）删除。没什么大不了的。
正如我所说，这是AFAICS最干净的解决方案。不利的一面是，您的PR将使用这些最新的提交进行更新，这将获得较晚的日期，并且可能与PR的注释历史记录不同步。没什么大问题，但可能会造成混乱。
是的-您要做的工作远远超出您的需要。只需再进行一次提交，然后强行推送即可。在浏览器中刷新github时，您将看到原始提交以及新提交的提交。
$ git commit -m "These changes are in response to PR comments"
$ git push -f origin HEAD