用于在代码审查后更新拉取请求的首选Github工作流程-Java 学习之路

314

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

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

将代码更新为新提交，并将初始和更新的提交添加到我的pull请求中 .
不知怎的（??）从我的存储库回滚旧的提交，并创建一个包含所有内容的新提交，然后为此提出拉取请求？
git commit 有一个修改功能，但是've heard that you shouldn'在你修改后使用它？
别的什么？

似乎选项2/3会很好，因为开源项目在他们的历史中只有一个提交将实现一切，但我不知道如何做到这一点 .

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

3 回答

204

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

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

回复于 2024-04-27T08:02:05+08:00
5
更新拉取请求

要更新拉取请求（第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的历史记录以纠正您建议集成到存储库中的更改 - 这是一件好事 . 因为没有保留压缩你的拉动请求"noise" .

关于分支的说明

在上面我展示了来自你的fork的 master 分支的pull请求，虽然为你想要提出的每个单独的更改创建一个分支，但是更好的想法是's nothing wrong with that necessarily but it does create certain limitations such as, if this is your standard technique, only being able to have one PR open per repository. It'：
```
$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git push
# Now create PR from feature/new-widgets
```
回复于 2024-04-27T08:02:05+08:00
205
我对最佳实践的看法：一旦你准备好打包拉取请求，它应该在一开始就得到它自己独特的主题分支，特别是为此目的 . 首先将该分支推送到您的github存储库，例如
```
git push origin name-of-pull-request-branch
```
并将拉取请求基于该分支 . 完成此操作后，您推送到该分支的任何提交都将自动附加到pull请求中 . 你只使用那个分支 .

有些人更喜欢用你的github userid命名这样的分支 . 通过这种方式，他们可以在本地免费查看，以便尝试一下
- 少担心分支名称冲突
- 更容易记住它是什么
我通常将我的拉请求分支命名为
```
claybridges-do-the-things
```
回复于 2024-04-27T08:02:05+08:00

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

3 回答

更新拉取请求

可选 - 清除提交历史记录

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

关于分支的说明

相关问题