首选Github工作流程，用于在代码审查后更新拉取请求
我已经向Github上的开源项目提交了一个更改，并收到了其中一位核心团队成员的代码审查意见。
我想在考虑审核意见的情况下更新代码并重新提交。 这样做的最佳工作流程是什么？ 从我有限的git / github知识中，我可以执行以下任何操作：
将代码更新为新提交，并将初始提交和更新提交添加到我的请求中。
不知何故（??）从我的仓库回滚旧的提交，并创建一个包含所有内容的新提交，然后为此提出一个pull请求？
git commit有一个修改功能，但是我听说你在本地存储库之外推送提交之后不应该使用它。 在这种情况下，我在本地PC上进行了更改，并将其推送到项目的github分支。 这可以用'修改'吗？
还有别的吗？
看起来选项2/3会很好，因为开源项目在他们的历史记录中只会有一个实现所有事情的提交，但我不知道如何执行此操作。
注意：我不知道这是否会影响答案，但我没有在单独的分支中进行更改，我只是在主控之上进行了提交
只需将一个新的提交添加到在pull请求中使用的分支并将分支推送到GitHub。 拉取请求会自动更新并提交额外的提交。
＃2和＃3是不必要的。 如果人们只想看到你的分支被合并到了哪里（而不是额外的提交），他们可以使用git log --first-parent仅查看日志中的合并提交。
更新拉取请求
要更新拉取请求（点＃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的历史记录以纠正您提出要集成到存储库中的更改是一件好事。 因为没有任何保留压制你的拉动请求中的“噪音”。
关于分支机构的说明
在上面，我将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
我对最佳实践的看法：一旦你准备好打包请求，它应该有一个独特的主题分支，特别是为了这个目的。 您首先将该分支推送到您的github存储库，例如
git push origin name-of-pull-request-branch
并将该请求从该分支中提取出来。 完成之后，您推送到该分支的任何提交将自动附加到该请求。 你别用那个分支。
有些人更喜欢用你的github用户名命名空间这样的分支。 这样他们可以自由地在本地检查出来，试用它，并带来诸多好处
我通常将我的拉请求分支命名为类似的名称
claybridges-do-the-things
上一篇: Preferred Github workflow for updating a pull request after code review