99

我使用Fork & Edit this file file 按钮在 github 上打开了一个 pull request 到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

这工作得很好，但似乎是一个相当复杂的工作流程。也许我错了？

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

4

4 回答 4

70

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

于 2012-04-13T20:20:42.420 回答
26

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

$ git commit -m "These changes are in response to PR comments"
$ git push -f origin HEAD
于 2020-05-21T15:31:19.500 回答
10

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

我们如何使这个功能分支保持最新？合并最新的上游提交很容易，但是您希望避免创建合并提交，因为当推送到上游时不会受到赞赏：然后您将有效地重新提交上游更改，并且这些上游提交将获得一个新的哈希 (因为他们有了一个新的父母）。这一点尤其重要，因为当您将这些更新推送到您的个人 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 的评论历史记录中显得不同步。没什么大问题，但它可能会令人困惑。

于 2013-04-13T18:41:42.813 回答
8

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

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

于 2012-04-13T20:09:01.070 回答