我已在 Github 上提交了对开源项目的更改,并收到了一位核心团队成员的代码审查意见。
我想根据审稿意见更新代码,然后重新提交。执行此操作的最佳工作流程是什么?根据我对 git/github 的有限了解,我可以执行以下操作:
将代码更新为新提交,并将初始提交和更新提交添加到我的拉取请求中。
不知何故(?)从我的存储库回滚旧提交,并创建一个包含所有内容的新提交,然后提出拉取请求?
git commit
有修改功能,但我听说你在将提交推送到本地存储库之外后不应该使用它?在本例中,我已在本地 PC 上进行了更改,并将其推送到项目的 github 分支。使用“修改”可以吗?还有什么吗?
选项 2/3 似乎不错,因为开源项目在其历史记录中只有一次提交,可以实现所有功能,但我不确定如何执行此操作。
注意:我不知道这是否会影响答案,但我没有在单独的分支中进行更改,我只是在 master 之上进行了提交
要更新拉取请求(第 1 点),您唯一需要做的就是签出拉取请求所在的同一分支并再次推送到它:
cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git push
您可能会被要求将您的提交压缩在一起,以便存储库历史记录是干净的,或者您自己想要删除分散拉取请求中“消息”注意力的中间提交(第2点)。例如,如果您的提交历史记录如下所示:
$ git remote add parent [email protected]: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 更改为挤压:
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 [email protected]:me/my-fork.git
f1238d0..9de3202 HEAD -> master
并且您的拉取请求将包含单个提交,其中包含之前拆分为多个提交的所有更改。
重写历史记录并在其他人可能已经克隆的分支上使用
git push -f
是一件坏事 - 它会导致存储库的历史记录和签出历史记录出现分歧。
但是,修改您的分叉历史记录以纠正您提议集成到存储库中的更改 - 是一件好事。因此,不要保留从拉取请求中消除“噪音”的想法。
在上面,我将拉取请求显示为来自您的分叉的
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。拉取请求将自动更新为附加提交。
#2 和 #3 是不必要的。如果人们只想查看您的分支合并的位置(而不是其他提交),他们可以使用
git log --first-parent
仅查看日志中的合并提交。
只需将新更改推送到新提交中的同一分支,解决您收到的反馈。
我喜欢为每条反馈执行 1 个新提交,然后使用包含更改/改进/修订的提交的哈希值回复 PR 评论。
PR 获得批准后,您可以“压缩并合并”它,将所有提交合并到主分支上的一个新提交中 - 这篇文章解释了合并提交与 rebase 与压缩的优缺点。