[ English | Indonesia | 한국어 (대한민국) | español (México) | English (United Kingdom) | Deutsch | 中文 (简体, 中国) ]
使用Gerrit¶
备注
本章节假设您已完成 设置您的Gerrit帐户 指南。
Gerrit允许您：
获取有关对OpenStack仓库建议的更改的审核
请求指定社区成员的审核
在webui里进行你的补丁的快速更改
推进一个更改¶
备注
This is a quick start version. For a more in depth description of how to clone, create a patch and push the change, directions can be 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来查找它们。
通常情况，最好避免过度使用这项gerrit功能，因为与补丁的每次交互操作（新的补丁集，注释，CI系统的投票等）都会向该补丁的每位审阅者发送电子邮件通知。
备注
如果您审阅了一个补丁，则会自动被添加到审阅者列表中。
Gerrit网络编辑器¶
在gerrit web界面中编辑补丁并发布更改是可以的，而且无需在本地进行更改。 通常不建议进行较多的代码更新，因为它不会自动更新本地工作分支。 在某些情况下，除了一个小的pep8故障外，生成的补丁基本上已经准备好合并了 - 行末尾有空白，需要换行，等等 - 这项gerrit功能可以方便地进行快速编辑和发布更改而没有必要通过整个’git add’, ‘git commit –amend’, ‘git review’流程。
要访问Gerrit网络编辑器以编辑文件，请单击Gerrit Code Review页面顶部的补丁集编号旁边的看起来像铅笔在纸上写字的那个图标。
审阅更改¶
审阅更改通常被建议为开始项目的一种方法。 无论您是选择开始还是不选择，这都是一项重要的社区活动。 请参阅 How to Review Changes the OpenStack Way 以获取有关何时在审阅更改中使用哪种投票的更详细指导。
行内评论
如果您对补丁的某些措辞或完成方式有疑问，或者发现了其他问题，让补丁的作者知道的最简单方法是在行内的该位置上进行评论。 当您单击“答复”按钮并在补丁集上添加投票时，这些行内评论会集体发布。
备注
在您单击“答复”并对补丁进行投票之前，您所做的任何行内评论都将作为草稿存在。
+/- 1 & 0
贡献者必须对补丁进行投票的基本值的集合是：-1、0或+1。 这些值对应了一个相对简单的系统。
-1 ：这个补丁需要进一步的修改才能合并。 当审阅者发现合并补丁之前需要解决一些问题时，通常会给出-1。 理想情况下，除非有更大的问题，否则作者需要解决的问题应在相应的位置上添加行内评论（inline comments）。 如果总体方法有问题，您可以在投票中留下总体评论，以提出您的担忧。
备注
如果您的补丁得到了-1，这不是一个坏消息，这仅意味着您需要做更多的修改。
0 ：没有分数。 这是回复补丁集时的默认分数。 通常，当有人对补丁集有疑问或尚未对补丁集有完整的意见时，它将保留表决权–需要更多时间，测试或调查。
+1 ：对我来说不错，但其他人必须批准。 这并不意味着没有什么可评论的，只是不存在任何会阻碍补丁合并的问题。 如果其他人发现补丁的问题，您仍然可以对补丁所有者可能解决这个问题的一些方式发表评论。 这些评论也可能是这项补丁的后续补丁（而不是另一个补丁集）中要解决的问题。
+/- 2 & +W
核心审阅者除了基本设置外，还有其他投票选择。 像基本值的集合一样，这些数字反映了一个简单的意义系统：
-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的网络界面找到：
签出了补丁之后，您会被自动切换到一个新的分支，在这个分支上进行您的修改。
拣选（Cherry-picking）¶
如果您的提交依赖于自您开始工作以来已更新的更改，并且您需要从该更改中获取最新的补丁集，则可以在该更改之上拣选您自己的更改：
git review -x <change ID>
更改ID则和前面的情况是一致的。
