[ English | Deutsch | Indonesia | 中文 (简体, 中国) | English (United Kingdom) | español (México) | 한국어 (대한민국) ]

使用Gerrit

注解

本章节假设您已完成 设置您的Gerrit帐户 指南。

Gerrit允许您:

  • 获取有关对OpenStack仓库建议的更改的审核

  • 请求指定社区成员的审核

  • 在webui里进行你的补丁的快速更改

推进一个更改

注解

这是一个快速入门版本。 有关如何克隆,创建补丁并进行更改的更深入的说明,说明可以 found here

以下是您首次贡献时需要了解的命令列表:

克隆某个仓库的拷贝:

git clone https://opendev.org/openstack/<PROJECT_NAME>

注解

您可以在此处使用搜索功能找到相同的仓库: OpenDev git repository browser

完成了“设置和学习GIT”章节后,以下命令将配置仓库以了解Gerrit并安装 Change-Id 提交钩子(commit hook)。 您只需为每个克隆的仓库执行一次此操作:

git review -s

创建您的开发分支(用您选择的名称替换branch_name)。 最好为每个补丁创建一个新分支,而不是使用主分支:

git checkout -b <branch_name>

要检查您的分支中已更新的文件:

git status

要检查您的分支和仓库之间的差异:

git diff master

假设您还尚未添加新文件,则使用以下命令提交所有更改:

git commit -a

阅读 Summary of Git commit message structure 以获取编写提交消息的最佳实践。 当您准备好将您的更改发送以供审核时使用时:

git review

如果成功,则Git响应消息将包含一个URL,您可以使用该URL来跟踪您的更改。

如果您需要对同一审核进行进一步的更改,则可以使用:

git commit -a --amend

这将在您之前发起的同一组更改下提交更改。 请注意,要发送最新版本以供审核,您仍然需要调用:

git review

跟踪您的更改

提出更改建议后,您可以在 Code Review 处进行跟踪。 登录后,您将看到总控页面(Dashboard),其中包含您已建议更改的 “即将结束审核(Outgoing reviews)” ,您正在进行审核的 “即将到来审核(Incoming reviews)” 以及您曾经是审核人员或更改拥有者的 “最近关闭” 更改。

添加审核人员

有时候,您可能需要有人帮助权衡您的补丁,因为他们有相关的关键考量或正处于帮助指导您开发基础的阶段。 让他们知道您已上传新补丁或补丁集的最简单方法是将他们添加为gerrit web-ui中的审阅者(reviewer)。 您可以通过名字,gerrit电子邮件地址,ssh用户名或gerrit ID来查找它们。

../_images/invite-reviewers.png

通常情况,最好避免过度使用这项gerrit功能,因为与补丁的每次交互操作(新的补丁集,注释,CI系统的投票等)都会向该补丁的每位审阅者发送电子邮件通知。

注解

如果您审阅了一个补丁,则会自动被添加到审阅者列表中。

Gerrit网络编辑器

在gerrit web界面中编辑补丁并发布更改是可以的,而且无需在本地进行更改。 通常不建议进行较多的代码更新,因为它不会自动更新本地工作分支。 在某些情况下,除了一个小的pep8故障外,生成的补丁基本上已经准备好合并了 - 行末尾有空白,需要换行,等等 - 这项gerrit功能可以方便地进行快速编辑和发布更改而没有必要通过整个’git add’, ‘git commit –amend’, ‘git review’流程。

要访问Gerrit网络编辑器以编辑文件,请单击Gerrit Code Review页面顶部的补丁集编号旁边的看起来像铅笔在纸上写字的那个图标。

../_images/web-editor.png

审阅更改

审阅更改通常被建议为开始项目的一种方法。 无论您是选择开始还是不选择,这都是一项重要的社区活动。 请参阅 How to Review Changes the OpenStack Way 以获取有关何时在审阅更改中使用哪种投票的更详细指导。

行内评论

如果您对补丁的某些措辞或完成方式有疑问,或者发现了其他问题,让补丁的作者知道的最简单方法是在行内的该位置上进行评论。 当您单击“答复”按钮并在补丁集上添加投票时,这些行内评论会集体发布。

注解

在您单击“答复”并对补丁进行投票之前,您所做的任何行内评论都将作为草稿存在。

+/- 1 & 0

贡献者必须对补丁进行投票的基本值的集合是:-1、0或+1。 这些值对应了一个相对简单的系统。

../_images/regular-reviewer.png

-1 :这个补丁需要进一步的修改才能合并。 当审阅者发现合并补丁之前需要解决一些问题时,通常会给出-1。 理想情况下,除非有更大的问题,否则作者需要解决的问题应在相应的位置上添加行内评论(inline comments)。 如果总体方法有问题,您可以在投票中留下总体评论,以提出您的担忧。

注解

如果您的补丁得到了-1,这不是一个坏消息,这仅意味着您需要做更多的修改。

0 :没有分数。 这是回复补丁集时的默认分数。 通常,当有人对补丁集有疑问或尚未对补丁集有完整的意见时,它将保留表决权–需要更多时间,测试或调查。

+1 :对我来说不错,但其他人必须批准。 这并不意味着没有什么可评论的,只是不存在任何会阻碍补丁合并的问题。 如果其他人发现补丁的问题,您仍然可以对补丁所有者可能解决这个问题的一些方式发表评论。 这些评论也可能是这项补丁的后续补丁(而不是另一个补丁集)中要解决的问题。

+/- 2 & +W

核心审阅者除了基本设置外,还有其他投票选择。 像基本值的集合一样,这些数字反映了一个简单的意义系统:

../_images/core-reviewer.png

-2 :不要合并。 这个分数并不经常出现,当出现时,这是有充分的理由的:

  • 多数情况下,可能是截止日期已经过去,并且由于直到新版本开发开始之前都没有接受更多更改,所以这个补丁正在 being held

  • 补丁中采用的方法存在问题,需要与更大的小组讨论,例如在会议中。

  • 提交的补丁是重复的,或者与提交的另一个补丁不一致。

注解

只有投票了“-2”的人才能删除投票,并且投票将保留在所有新补丁集上。

+2 :对我来说看起来不错(核心审阅者)。 根据项目团队和软件仓库的不同,合并补丁至少需要一票“+2”(如果不是两票“+2”)。

+W:已批准。 现在,在将补丁合并到软件仓库之前,将对其进行最后一轮检查。

审阅最佳实践

  • 如果可以,请测试代码! 在某些情况下,您可能无权访问所需的特定硬件,但总的来说,您应该能够测试所做的更改或查看文档的zuul构建版本,因此您要做的不仅仅是查看代码或文档的更改。

签出(Check Out)其他人的更改

从gerrit中签出(check out)其他贡献者的补丁是可以的,有时候甚至可以 make changes to them ; 但是,在开始着手修改他们的补丁之前,您应该始终与贡献者讨论任何要做的更改。

git-review -d <change ID>

更改ID可以在gerrit的网络界面找到:

../_images/change-id.png

签出了补丁之后,您会被自动切换到一个新的分支,在这个分支上进行您的修改。

拣选(Cherry-picking)

如果您的提交依赖于自您开始工作以来已更新的更改,并且您需要从该更改中获取最新的补丁集,则可以在该更改之上拣选您自己的更改:

git review -x <change ID>

更改ID则和前面的情况是一致的。