用于在代码审查后更新拉取请求的首选Github工作流
我在Github上提交了对开源项目的更改，并收到了核心团队成员之一的代码审查意见。
我想更新代码，考虑到审查意见，并重新提交它。执行此操作的最佳工作流程是什么？根据我有限的git/github知识，我可以做以下任何一件事：
- 将代码更新为新的提交，并将初始提交和更新的提交都添加到我的拉取request.
- Somehow (??)从我的存储库回滚旧的提交，并创建一个包含所有内容的新提交，然后为that?
git commit提出一个拉取请求，它具有一个修改功能，但我听说在将提交推到本地存储库之外之后，您不应该使用它？在本例中，我在本地PC上进行了更改，并将其推送到项目的github分支。是否可以使用'amend'?- Something else?
看起来选项2/3会很好，因为开源项目在他们的历史上只有一次提交，这将实现一切，但我不确定如何做到这一点。
注意:我不知道这是否会影响答案，但我没有在单独的分支中进行更改，我只是在master上执行了一次提交
回答 2
Stack Overflow用户
发布于 2011-10-31 03:45:02
只需向pull请求中使用的分支添加一个新的提交，并将该分支推送到GitHub。拉取请求将使用额外的提交自动更新。
#2和#3是不必要的。如果人们只想查看您的分支合并到的位置(而不是其他提交)，他们可以使用git log --first-parent只查看日志中的合并提交。
Stack Overflow用户
发布于 2013-02-25 03:27:40
更新拉取请求的步骤
要更新拉取请求(point #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更改为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并且您的拉取请求将包含单个提交，将先前拆分成多个提交的所有更改合并在一起。
改变公共回购的历史是一件坏事
重写历史并在其他人可能已经克隆的分支上使用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-widgetshttps://stackoverflow.com/questions/7947322
复制相似问题