Question

我已经在Github上提交了对开源项目的更改，并收到了其中一位核心团队成员的代码审核意见。

我想考虑审核评论更新代码，然后重新提交。这样做的最佳工作流程是什么？根据我对git / github的有限知识，我可以做以下任何事情：

将代码更新为新提交，并将初始和更新提交添加到我的提取请求中。
以某种方式（??）从我的存储库中回滚旧提交，并创建一个包含所有内容的新提交，然后为此提出拉取请求？
git commit有一个修改功能，但是我听说你在本地存储库之外推送提交后不应该使用它？在这种情况下，我在我的本地PC上进行了更改并推送到我的项目的github分支。这可以使用'修改'吗？
还有别的吗？

看起来选项2/3会很好，因为开源项目在他们的历史记录中只有一个提交将实现所有内容，但我不知道如何做到这一点。

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

Answer 1

更新拉取请求

要更新拉取请求（第1点），您唯一需要做的就是检查拉取请求来自的相同分支并再次推送到它：

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

可选 - 清除提交历史记录

可能会要求您将提交压缩在一起，以便存储库历史记录清晰，或者您自己想要删除分散拉动请求中“消息”的中间提交（第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

这将提示您选择如何重写拉取请求的历史记录，以下内容将在您的编辑器中：

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

对于您希望成为之前提交的一部分的任何提交 - 将选择更改为压缩：

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的历史记录以纠正您提议将集成到存储库中的更改 - 是一件好事。因此，毫无保留地压低你的拉动请求中的“噪音”。

关于分支的说明

在上面我展示了拉取请求来自你的叉子的master分支，这没有什么不妥，但它确实会产生某些限制，例如，如果这是你的标准技术，那么只是能够在每个存储库中打开一个PR。虽然为您希望提出的每个变更创建一个分支，但这是一个更好的主意：

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

Answer 2

只需向pull请求中使用的分支添加新提交，然后将分支推送到GitHub。拉取请求将自动使用附加提交进行更新。

＃2和＃3是不必要的。如果人们只想查看合并分支的位置（而不是其他提交），则可以使用git log --first-parent仅查看日志中的合并提交。

Answer 3

我对最佳实践的看法：一旦你准备好打包拉取请求，它应该在一开始就得到它自己独特的主题分支，特别是为此目的。首先将该分支推送到您的github存储库，例如

git push origin name-of-pull-request-branch

并将拉取请求基于该分支。完成此操作后，您推送到该分支的任何提交都将自动附加到拉取请求中。你只使用那个分支。

有些人更喜欢用你的github userid命名这样的分支。通过这种方式，他们可以在本地自由检查以试用它，具有诸如

之类的好处

不太担心分支名称冲突
更容易记住它是什么

我通常将我的拉取请求命名为

claybridges-do-the-things

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

3 个答案:

更新拉取请求

可选 - 清除提交历史记录

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

关于分支的说明