git - 用于在代码审查后更新 pull 请求的首选 Github 工作流

标签 git version-control github pull-request

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

我想根据审稿意见更新代码,重新提交。执行此操作的最佳工作流程是什么?根据我对 git/github 的有限了解,我可以执行以下任何操作:

  1. 将代码更新为新提交,并将初始提交和更新后的提交添加到我的 pull 请求中。

  2. 以某种方式(??)从我的存储库回滚旧提交,并创建一个包含所有内容的新提交,然后为此提出 pull 请求?

  3. git commit 具有修改功能,但我听说在将提交推送到本地存储库之外后不应该使用它?在这种情况下,我在我的本地 PC 上进行了更改,并推送到项目的 github 分支。这样可以使用“修改”吗?

  4. 还有别的吗?

选项 2/3 似乎不错,因为开源项目在其历史记录中只有一次提交可以实现所有内容,但我不确定如何执行此操作。

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

最佳答案

更新 pull 请求

要更新 pull 请求(第 #1 点),您唯一需要做的就是 checkout pull 请求所在的同一分支,然后再次推送到该分支:

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

可选 - 清理提交历史

您可能会被要求将您的提交压缩在一起,以便存储库历史是干净的,或者您自己想要删除中间提交,这些中间提交会分散您的 pull 请求中的“消息”(第 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 

这将提示您选择如何重写 pull 请求的历史记录,以下内容将出现在您的编辑器中:

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

将它推到你的 fork 上:

$ 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 请求将包含单个提交,将之前拆分为多个提交的所有更改 merge 。

改变公共(public) repo 的历史是一件坏事

重写历史记录并在可能已被其他人克隆的分支上使用 git push -f 是一件坏事 - 它会导致存储库的历史记录和 checkout 的历史记录发生分歧。

但是,修改您的复刻历史以更正您提议集成到存储库中的更改是一件好事。因此,毫无保留地从您的 pull 请求中消除“噪音”。

关于分支的说明

在上面,我将 pull 请求显示为来自您的分支的 master 分支,这不一定有任何问题,但它确实造成了某些限制,例如,如果这是您的标准技术,每个存储库只能打开一个 PR。为您希望提出的每个单独更改创建一个分支是一个更好的主意:

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

关于git - 用于在代码审查后更新 pull 请求的首选 Github 工作流,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7947322/

相关文章:

git - 如何将原始 GitHub 项目的分支克隆到您的复刻中?

linux - git push 两步验证失败的解决方法(linux)

ruby-on-rails - 如何在 Heroku 部署期间运行 "grunt build"(angular 和 ruby​​-on-rails 应用程序)

Git rebase 失败

php - 如何将 packagist.org 中的版本 (dev-master) 更改为 v1.0.2 之类的版本?

ms-access - Microsoft Access 开发的版本控制?

git - Jenkins checkout GIT 项目失败,权限被拒绝致命 : unable to fork

git 子模块在 git status 中显示为文件

linux - 如何使用 codecommit 设置 git,这样我就不必每次都添加 ssh key ID?

git - 在服务器端复制 git 客户端 Hook