[ English | 한국어 (대한민국) | Indonesia | 中文 (简体, 中国) | español (México) | English (United Kingdom) | Deutsch ]
使用 Gerrit¶
注意
本节假定您已完成 设置您的 Gerrit 帐户 指南。
Gerrit 允许您
获取对 OpenStack 仓库提出的更改的评审
向特定社区成员请求评审
在 WebUI 中快速更改您的补丁
推送更改¶
注意
这是一个快速入门版本。有关如何克隆、创建补丁和推送更改的更详细描述,请参见 此处
以下是您首次贡献需要了解的命令列表
要克隆某个仓库的副本
git clone https://opendev.org/openstack/<PROJECT_NAME>
注意
您可以使用此处的搜索功能找到相同的仓库:OpenDev git 仓库浏览器
在完成“设置和学习 GIT”部分后,以下命令将配置仓库以了解 Gerrit 并安装 Change-Id 提交钩子。您只需要对您克隆的每个仓库执行一次此操作
git review -s
要创建您的开发分支(将 branch_name 替换为您选择的名称)。为每个补丁创建新分支比从 master 分支工作更好
git checkout -b <branch_name>
要检查已更新的分支中的文件
git status
要检查分支与仓库之间的差异
git diff master
假设您没有添加新文件,您可以使用以下命令提交所有更改
git commit -a
请阅读 Git 提交消息结构摘要,了解编写提交消息的最佳实践。准备好提交您的更改以供评审时,请使用
git review
如果成功,Git 响应消息将包含一个 URL,您可以使用该 URL 跟踪您的更改。
如果您需要对相同的评审进行进一步的更改,可以使用以下命令提交它们
git commit -a --amend
这将把更改提交到您之前发出的相同更改集下。请注意,为了发送您最新的版本以供评审,您仍然需要调用
git review
跟踪您的更改¶
在提出更改后,您可以在 代码评审 上跟踪它们。登录后,您将看到“传出评审”仪表板,用于您提出的更改,“传入评审”仪表板,用于您正在评审的更改,以及“最近关闭”仪表板,用于您是评审者或所有者的更改。
添加评审者¶
有时可能有人需要对您的补丁发表意见,因为他们对此有既得利益或正在帮助指导您。让他们知道您已上传新补丁或补丁集的 easiest 方法是在 Gerrit WebUI 中将他们添加为评审者。您可以按姓名、Gerrit 电子邮件地址、ssh 用户名或 Gerrit ID 查找他们。
通常,最好避免过度使用此 Gerrit 功能,因为与补丁的每次交互——新的补丁集、评论、CI 系统投票等——都会向每位补丁评审者发送电子邮件通知。
注意
如果您评审了补丁,您将自动添加到评审者列表中。
Gerrit Web 编辑器¶
可以在 Gerrit Web 界面中编辑您的补丁并发布更改,而无需在本地进行更改。通常不建议对较大的代码更新执行此操作,因为它不会自动更新您的本地工作分支。在某些情况下,如果补丁基本上已经准备好合并,除了一个小的 pep8 错误——行尾的空格、需要换行等——此 Gerrit 功能可以方便地进行快速编辑并发布更改,而无需经过整个“git add”、“git commit –amend”、“git review”过程。
要访问 Gerrit Web 编辑器,请单击 Gerrit 代码评审页面顶部文件补丁集编号旁边的看起来像铅笔写在纸上的图标。
评审更改¶
评审更改通常被建议作为开始参与一个项目的方式。无论您选择以这种方式开始还是不开始,它都是一项重要的社区活动。请参阅 OpenStack 评审方式,了解有关在更改评审中使用哪些投票的更详细指导。
内联评论
如果您对某些内容的措辞或完成方式有疑问,或者发现其他问题,让补丁作者知道的最简单方法是在内联评论中进行评论。内联评论在您单击“回复”按钮并添加对补丁集的投票时集体发布。
注意
在您单击“回复”并对补丁进行投票之前,您所做的任何内联评论都存在为草稿。
+/- 1 & 0
贡献者必须使用的基本投票集是:-1、0 或 +1。这些值对应于一个相对简单的系统。
-1:此补丁在合并之前需要进一步的工作。通常,当评审者看到需要修复才能合并补丁的问题时,会给出 -1。作者需要解决的问题应该在内联评论中发布,除非存在更大的问题。如果对整体方法有疑问,您可以留下总体评论并进行投票以提出您的担忧。
注意
如果您的补丁收到 -1,这并不是坏消息,只是意味着您需要再做一些工作。
0:无分数。这是回复补丁集时的默认分数。通常,当某人对补丁集有疑问或尚未形成补丁集的完整观点时,会将其保留为投票——需要更多时间、测试或调查。
+1:看起来不错,但其他人必须批准。这并不意味着没有评论,只是没有阻止合并补丁的问题。您可以对补丁所有者可以解决的微不足道的问题发表评论,其他人可能会发现这些问题。
+/- 2 & +W
核心评审者除了基本集之外,还有额外的投票选项。与基本集一样,数字映射到一个简单的含义系统
-2:不要合并。此分数并不常见,但出现时是有充分理由的
通常,某个截止日期已过,并且由于不再接受更改直到新的发布开发开始,因此补丁正在 被保留。
补丁中采用的方法存在问题,需要与更大的团队讨论,可能是在会议中。
提交的补丁是重复的或与另一个提交的补丁冲突。
注意
只有投票 -2 的人才能删除投票,并且它将保留在所有新的补丁集中。
+2:看起来不错(核心评审者)。根据项目团队和仓库,合并补丁可能需要至少一个 +2 投票,甚至两个 +2 投票。
+W:已批准。此补丁现在将通过最后一轮检查,然后合并到仓库中。
评审最佳实践
如果可以,请测试代码!在某些情况下,您可能无法访问所需的特定硬件,但通常您应该能够测试更改或查看文档的 zuul 构建,以便您不仅仅是查看代码或文档更改。
签出其他人的更改¶
可以从 Gerrit 签出其他贡献者的补丁,甚至 对其进行更改;但是,您应该始终在开始处理他们的补丁之前与贡献者讨论任何更改。
git-review -d <change ID>
可以在 Gerrit 的 Web UI 上找到更改 ID
签出补丁后,您将自动切换到一个新分支,您可以在该分支上进行更改。
Cherry-picking¶
如果您的提交依赖于自您开始工作以来已更新的更改,并且您需要从该更改获取最新的补丁集,您可以将自己的更改 cherry-pick 到其上
git review -x <change ID>
更改 ID 与前一种情况相同。
Backports¶
为了将已合并到 master 的提交 backport,该提交必须 backport 到 master 和目标分支之间的所有 开放分支(即使其中一些分支是 Unmaintained)。如果必须将提交 backport 到多个分支,则每个 backport 都应从下一个最新的 backport cherry-pick。例如,要将更改 I06b19044 和更改号 946581 从 master (2025.2) backport 到 stable/2024.1
git fetch --all
git checkout -b bug/123 gerrit/stable/2025.1
git review -X 946581
git review -f # Uploads change number 950213
git checkout -b bug/123 gerrit/stable/2024.2
git review -X 950213
git review -f # Uploads change number 950215
git checkout -b bug/123 gerrit/stable/2024.1
git review -X 950215
git review -f # Uploads change number 950217
最终更改 应该在提交消息的底部有几个 (cherry picked from <sha>)。
有关更多信息,请参阅 稳定分支。