在代码审查后更新拉请求的首选Github工作流

我在Github上向一个开源项目提交了一个变更，并收到了一个核心团队成员的代码评审意见。

我想根据评审意见更新代码，并重新提交。做这件事的最佳工作流程是什么?从我有限的git/github知识，我可以做以下任何一个:

  1. 将代码更新为一个新的提交，并将初始的和更新后的提交添加到我的pull请求中。

  2. 以某种方式(??)从我的存储库回滚旧的提交，并创建一个包含所有内容的新提交，然后提出一个拉请求?

  3. git commit有一个修改功能，但我听说你不应该使用它后，你已经推动提交外部你的本地存储库?在这种情况下，我已经在我的本地PC上进行了更改，并推送到我的github项目分支。用“amend”可以吗?

  4. 别的吗?

看起来选项2/3会很好，因为开源项目在他们的历史中只有一次提交，它将实现所有的东西，但我不确定如何做到这一点。

注意:我不知道这是否会影响答案，但我没有在一个单独的分支中进行更改，我只是在master上做了一个提交

92070 次浏览
小开
最佳答案

只需添加一个新的提交到拉请求中使用的分支，并将分支推到GitHub。pull请求将随着额外的提交而自动更新。

第二条和第三条是不必要的。如果人们只想看到你的分支被合并到哪里(而不是额外的提交)，他们可以使用git log --first-parent来只查看日志中的合并提交。

小开

更新一个拉请求

要更新一个拉请求(第1点)，你唯一需要做的就是签出拉请求来自的同一个分支，并再次推到它:

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push

可选-清理提交历史记录

您可能会被要求将提交压缩在一起，以便存储库历史记录干净，或者您自己想要删除中间提交，它会分散您的pull请求中的“消息”(第2点)。例如，如果你的提交历史是这样的:

$ git remote add parent git@github.com:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

把这些东西压缩在一起是个好主意，这样它们看起来就像一个单独的提交:

$ git rebase -i parent/master

这将提示你选择如何重写你的pull请求的历史，下面将在你的编辑器中:

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

对于任何你想要成为前一个提交更改的一部分的提交，选择squash:

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

并关闭编辑器。Git将重写历史记录，并提示您为一次合并提交提供一个提交消息。相应地修改，你的提交历史现在将是简洁的:

$ git log --oneline parent/master..master
9de3202 fixing actual problem

把它推到你的叉子上:

$ git push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To git@github.com:me/my-fork.git
f1238d0..9de3202  HEAD -> master

并且您的pull请求将包含一个单独的提交，将之前分裂为几个提交的所有更改合并在一起。

改变公共回购的历史是件坏事

重写历史记录并在其他人可能已经克隆的分支上使用git push -f是一件坏事——它会导致存储库的历史和签出的历史背离。

然而，修改你的fork的历史来纠正你提出要集成到存储库中的更改是一件好事。因此，毫无保留地挤压“噪音”从你的拉请求。

关于分支的说明

在上面的例子中，我将pull请求显示为来自fork的master分支，这并没有什么问题，但它确实产生了一定的限制，例如，如果这是你的标准技术，那么每个存储库只能打开一个PR。不过，为你想要提出的每个单独的更改创建一个分支是个更好的主意:

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets

提交答案