拉取请求的生命周期#
如前所述,Arrow 项目使用 Git 进行版本控制,并采用基于拉取请求的工作流程。这意味着您通过在 Git 中创建一个分支来贡献代码更改或“补丁”,对代码进行修改,然后将这些更改推送到您的 origin(即您在 GitHub 上复刻的 Arrow 仓库),最后针对官方 Arrow 仓库创建一个拉取请求(该仓库在您的设置中保存为 upstream)。
到目前为止,您应该已经设置好了 Git,克隆了仓库,成功构建了 Arrow,并且有一个准备处理的 GitHub issue。
在对代码进行更改之前,您应该在 Git 中创建一个新分支。
使用
upstream/main更新您复刻仓库的 main 分支。在arrow目录下的 shell 中运行此命令。$ git checkout main # select the main Arrow branch $ git fetch upstream # check for changes in upstream/main $ git pull --ff-only upstream main # save the changes from upstream/main
注意:
--ff-only仅在可以快速前进而不会产生冲突或创建合并提交的情况下应用更改。创建一个新分支
$ git checkout -b <branch-name>
或(效果相同)
$ git switch --create <branch-name>
现在您可以对代码进行更改。要查看库中所做的更改,请使用这两个命令
$ git status # to see what files are changed
$ git diff # to see code change per file
创建拉取请求#
一旦您对更改感到满意,请运行测试和代码风格检查器,然后继续提交更改。
添加并提交更改
$ git add <filenames> $ git commit -m "<message>"
或者,如果所有已更改的文件都要提交,您可以在一个步骤中完成添加和提交(-a 表示添加所有文件,-m 表示消息)
$ git commit -am "<message>"
然后将您的工作推送到您的 Arrow 复刻仓库
$ git push origin <branch-name>
注意
您的工作现在仍在您的掌控之中,所以如果您发现任何想要纠正的错误,也不成问题。您可以进行额外的提交来修正,Git 有很多方法来修改、删除、修订等。更多信息请参阅 https://git-scm.cn/docs。
在您创建拉取请求之前,Arrow 仓库上什么都看不到,您可以自由地进行实验。
如果一切准备就绪,您就可以创建拉取请求了!
访问
https://github.com/<your username>/arrow,您会看到一个框,里面有您推送的分支名称,旁边有一个绿色的 Compare & pull request 按钮。点击后,您应该添加拉取请求的标题和描述。在下方,您可以再次检查您所做的更改。另请参阅
有关在 Arrow 仓库中命名拉取请求以及其他附加信息的更多详情,请参阅拉取请求和审查部分。
持续集成 (CI)#
持续集成 (CI) 是一种自动化方式,用于在不同环境中对特定拉取请求所做的代码更改运行测试和构建。它在代码被合并或集成到项目主仓库之前,充当稳定性检查的角色。
一旦创建了拉取请求,CI 将触发对代码的检查。根据代码更改的部分(例如文档、C++ 或其他语言),CI 会被配置为运行相关的检查。
您将在 GitHub 上拉取请求页面的底部看到正在运行的检查。如果出现错误,请点击详情并调查构建失败的原因。
CI 检查对文档所做的更改。#
CI 检查对 python 文件所做的更改。#
CI 检查对 R 文件所做的更改。#
除了检查 GitHub 仓库中更改(创建或合并拉取请求)的 CI 作业外,我们还使用 CI 进行 Apache Arrow 库的夜间构建和发布。
此外,您可以在拉取请求中使用扩展触发作业,例如添加一条评论 @github-actions crossbow submit python 将通过 GitHub Actions 运行 PyArrow 测试。这些主要用于在不太常见的环境中运行测试,通常在首次贡献时不需要。
要阅读有关此主题的更多信息,请访问持续集成。
拉取请求的审查和合并#
当拉取请求提交后,它会等待被审查。开源的一大优点是您的工作可以得到大量反馈,从而使其更加完善。不要因为审查和修改导致 PR 合并所需的时间而气馁。这是一个保证质量的过程,通过它您可以学到很多东西。
如果合并过程仍然耗时过长,请不要犹豫,在拉取请求的评论区提醒维护者,并在 GitHub issue 上发布提醒。
如何让您的拉取请求得到审查?#
当拉取请求被创建时,Arrow 的维护者会收到通知,他们会尽快处理。如果几天过去了仍未被审查,请继续在 GitHub 上提及该 issue 的报告者或您通过邮件列表或 GitHub 与之交流过的开发人员。
要在 GitHub 中进行提及,请在评论中插入 @ 并从列表中选择用户名。
评论拉取请求#
当仓库中有一个开放的拉取请求时,您和其他开发人员可以对提议的解决方案发表评论。
要创建一般性评论,请导航到您的拉取请求的 Conversation 选项卡,并在页面底部的评论框中开始撰写。
您还可以在文件的某个部分发表评论,以指出代码中的特定内容。为此,请导航到 Files changed 选项卡,并选择您要插入评论的行。将鼠标悬停在该行的开头,您会看到一个蓝色的加号图标。您可以点击它或拖动它以选择多行,然后点击图标插入评论。
解决对话#
您可以通过在 Files changed 选项卡中点击 Resolve conversation 来解决拉取请求审查中的对话。这样,该对话将被折叠并标记为已解决,这将使您更容易地组织已完成的工作和仍需处理的事项。
更新您的拉取请求#
收到审查意见后的流程与创建初始拉取请求类似。您需要在本地更新您的代码,进行一次提交,更新分支以与 upstream 同步,然后将您的代码推送到 origin。它将自动在您的拉取请求中更新。
更新拉取请求的步骤如下
像以前一样在本地更新代码并进行提交
$ git commit -am "<message>" #if all changed files are to be committed
重要! 如果拉取请求分支上有来自其他开发人员的提交,或者您从 GitHub 提交了建议,您需要在变基(rebase)之前用
origin更新您的代码!为此,请运行$ git pull origin <branch-name>
这里我们将新的提交与我们的本地分支合并,我们不进行变基(rebase)。
现在我们必须更新分支以与 upstream 的 main Arrow 分支同步。这样拉取请求才能被合并。在这种情况下,我们使用变基(rebase)。
$ git pull upstream main --rebase
这会将您的本地提交变基到
upstream/main的顶端。现在您可以通过运行以下命令来推送更改
$ git push origin <branch-name> --force
关于强制推送到正在审查的分支的说明: 如果您希望审查者查看您的更新,请确保您在 GitHub 上的 PR 中发表评论,因为仅仅强制推送不会在 GitHub 用户界面中触发通知。
另请参阅
有关更新分支(我们使用 rebase,而不是 merge)和压缩本地提交的更多信息,请参阅本地 git 约定。
如果审查过程顺利,您的拉取请求将被合并。