提交补丁_submitting-patches-CSDN博客

提交补丁Submitting Patches

这页介绍全部提交一个补丁到 AOSP 的过程，包括检阅和追踪改变用 Gerrit。

先决条件

你先跟着这页的介绍，你将需要建立你的本地工作环境和获取 Android 源文件，介绍跟着"获得开始" 部分，这里。
关于 Repo 和 Git 的细节，看版本控制。
关于不同角色的信息，你能在 Android 开源社区内发挥，看工程角色。
假如你计划贡献代码到 Android 平台，确认读了 AOSP 的授权信息。
注意，改变一些上游工程使用 Android 应该直接被制造到这个工程，描述在上游工程。

贡献者

鉴定服务

你能上传到 Gerrit 前，你需要建立一个密码，将标识你用这服务。你仅仅需要做这一次。

登录在AOSP Gerrit 服务。
转到 Settings -> HTTP Password -> Obtain Password
跟着随后（译者注：原为subsquent）页的介绍，和复制粘贴你的密码到 ~/.netrc 里，假如这些是两个密码行，复制两个。

开始一个 repo 分支

每个改变你打算制作，开始一个新分支用有关 git 知识库：

$ repo start NAME .

你能开始几个独立分支在相同时间在相同知识库。分支 NAME 是在本地的你的工作空间和将不被包括 gerrit 或最后的源树。

制作你的改变

一旦你修改源文件(请同时验证它们)保证改变到你的本地知识库：

$ git add -A
$ git commit -s

提供一个细节描述这个改变在你的承诺信息。这个描述将被推到公共 AOSP 知识库，所以请跟着我们的指引写改变明细表描述：

开始于一行总结(最大 60 个字符)，接着一个空行。这个格式是用于 git 和 gerrit 各个显示。

short description on first line

more detailed description of your patch,
which is likely to take up multiple lines.

描述将聚焦在它解决什么问题，和如何解决。第二部分是有些可选的当实施新特性，通过可取的。
包括一个简短的任何假设或背景信息的笔记，可能是重要的，当另一个贡献者这个特征下一年。

一个独特的改变 ID 和你的名字和 email 作为提供 repo init 期间将被自动添加你的承诺信息。

上传到 gerrit

一旦你承诺你的改变你私人历史，上传它到 gerrit 用

$ repo upload

假如你开始多个分支在相同的知识库，你将被提示选择上传哪些。

一个成功的上传只有，repo 将提供你一个 Gerrit 新页面的 URL。访问这个链接浏览你的补丁在评论服务器，添加评论，或要求具体评论者为你的补丁。

上传一个替换补丁

支持一个评论这看你的补丁和要求一个小修改。你能修改你的承诺用 git，将导致一个新包 gerrit 上有相同的改变 ID 作为原文。

注意，假如你使其它承诺自从上传这个补丁，你将需要手动移动你的 git HEAD。

$ git add -A
$ git commit --amend

当你上传修改补丁，他将替换原本在 gerrit 上和在你的本地 git 历史。

解决 sync冲突

假如其它补丁是提交到源树，和你的冲突，你将需要 rebase 你的补丁在源知识库新 HEAD 顶部。简单的方法做这是运行

$ repo sync

这命令首先取更新从源服务器，然后企图自动 rebase 你的 HEAD 到新的远程 HEAD。

假如自动 rebase 是不成共，你将不得不实施一个手工 rebase。

$ git rebase master

用 git mergetool 可能帮助你处理 rebase 冲突，一旦你成功合并冲突文件，

$ git rebase --continue

自动或手工 rebase 两者之一成功后，运行 repo upload 提交你的 rebased 补丁。

一个提交被批准之后

一个提交使他通过评论和校验过程后，Gerrit 自动合并改变到公共知识库。其它用户将能运行 repo sync 拉这更新到他们的本地客户端。

评论家和验证者

评论一个改变

假如你被分配成一个改变的批准者，你需要确定下面的：

这个改变适合这工程的声明目的？
这个改变是有效的在这个工程的存在的架构？
这个改变介绍设计缺陷将导致问题在将来？
这个改变跟着最好的做法已经既定到这个工程？
这个改变是一个好的方法实施描述的功能？
这个改变是描述一个安全或不稳定风险？

假如你批准这改变，标记它用 LGTM ("我看好")用 Gerrit。

校验一个改变

假如你被分配为一个改变的校验者，你需要做下面的：

打补丁这个改变到你的本地客户端用一个下载命令。
构建和测试这改变。
用 Gerrit 使用公共评论标记这承诺作为"已校验"或"失败"，并且添加一个信息解释问题为什么是确定的。

下载改变从 Gerrit

一个已经被校验和合并的提交经被吓在用 nextrepo sync。假如你希望下载一个具体但不被批准的改变，运行

$ repo download TARGET CHANGE

TARGET 是改变应该被下载到的本地目录和 CHANGE 是改变号在 Gerrit 里的表。更多信息，看Repo 参考。

我如何成为一个验证者或批准者？

简短讲，贡献高品质代码到一个或多个 Android 工程，细节关于不同角色在 Android 开源社区和饰演他们，看工程角色。

差异和评论

打开改变的细节用 Gerrit，点击一个改变的"Id 号"或"主题"。比较既定代码用更新代码，点击"Side-by-side 差异"下的文件名。

添加评论

社区里的任何人能用 Gerrit 添加内联评论到代码提交。一个好的评论将被应用到行或部分代码，它是附在 Gerrit。它可能是一个短的和建设性的建议，关于一行代码可以如何被改善，或它可以是一个解释从作者关于这样的方法代码为什么有意义。

添加内联评论，双击代码有关的行和写你的评论在打开的文本框。当你点击保存，仅仅你能看到你的评论。

发布你的评论以便其他人用 Gerrit 将能看它们，点击发布评论按钮。你的评论将被电子邮件发到这个改变所有有关的各方，包括改变的拥有者，补丁设置上传(假如不同于拥有者)，并且所有当前评论者。

上游工程

Android 利用一些其它的开源工程，例如 Linux 内核和 WebKit，描述在分支和发布。多数工程在 external/ 下。改变应该被上游制作和然后 Android 维护者通知新的上游发布包含这些改变。上传补丁也可以是有用的，移动我们追踪一个新的上游发布，虽然制作改变是困难的，假如工程是广泛的用在 Android 像大多数较大的下面提到的一些。

一个有趣的特别的情况是仿生。许多代码来自 BSD，所以除非改变是编写新的仿生，我们将比较多的看一个上游修理和然后拉到一个全新文件从适当的 BSD。(可悲的是我们有相当一个混合不同的 BSD 在此刻，但是我们希望讲话在未来，和进入一个位置，我们追踪上游更密切。)

ICU4C

所有的改变 ICU4C 工程在 external/icu4c 应该被制作由上游在 icu-project.org/。更多看提交 ICU Bugs 和需要的特征。

OpenSSL

所有的改变 OpenSSL 工程在 external/openssl 应该被制作由上游在 openssl.org。

V8

所有的改变 V8 工程在 external/v8 应该被制作由上游在 code.google.com/p/v8。。细节看贡献到 V8。

WebKit

所有的改变 WebKit 工程在 external/webkit 应该被制作由上游在 webkit.org。过程开首先备案一个 WebKit bug。这个 bug 应该用于 Android 平台和 OS 领域，仅仅假如 bug 是具体的 Android。Bug 更有可能接收评论者的注意，一旦一个建议修理被添加和测试被包含。细节看贡献代码到 WebKit。