這個(gè)頁面將描述提交補(bǔ)丁到 AOSP 的全過程，包括校驗(yàn)和 Gerrit 追蹤更改。

前提條件

• 在按照說明學(xué)習(xí)本頁面內(nèi)容之前，你需要初始化構(gòu)建環(huán)境，下載源碼，創(chuàng)建密碼和按照密碼生成頁面的說明學(xué)習(xí)。

• 可以在 developing 章節(jié)查看 Repo 和 Git 的詳細(xì)信息。
• 可以在 Project roles 章節(jié)查看你可以在開源社區(qū)扮演的各種角色信息。
• 如果你打算在 Android 平臺貢獻(xiàn)代碼，應(yīng)該先閱讀 AOSP 的權(quán)限聲明信息。
• 注意更改一些使用 Android 的上游項(xiàng)目，你應(yīng)該給這個(gè)項(xiàng)目創(chuàng)建一個(gè)目錄，像 Upstream Projects 中所說的目錄。

貢獻(xiàn)者

與服務(wù)器進(jìn)行身份驗(yàn)證

在你上傳內(nèi)容到 Gerrit 的時(shí)候，你需要創(chuàng)建一個(gè)與服務(wù)器認(rèn)證的密碼。按照 password generator 頁面的說明。你只要在第一次的使用的時(shí)候這樣做。查看 Using Authentication 補(bǔ)充說明。

從一個(gè) Repo 分支開始

在你有意向更改的地方，可以在相關(guān)聯(lián)的 git 庫中新建一個(gè)分支：

$ repo start NAME .

你可以在同一個(gè)庫同一時(shí)間新建幾個(gè)獨(dú)立的分支。這個(gè)分支的名字是在你本地的工作空間，不包含在 gerrit 或者最終的源碼分支樹中。

更改

一但你更改了源碼里面的文件（請驗(yàn)證它們），在本地庫中 commit 這個(gè)改變：

$ git add -A
$ git commit -s

在 commit 的消息中，寫上你更改信息的詳細(xì)描述。這個(gè)描述信息將會 push 到公共的 AOSP 庫，所以請按照我們的指導(dǎo)來寫更改列表的描述信息：

• 開始是一行摘要（最多 60 字），接著空一行。這樣的格式在 git 和 gerrit 中用于各種顯示。

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

• 這個(gè)描述信息應(yīng)該著重說明解決了什么問題，怎么解決的。第二部分盡管是值得滿意的，但是實(shí)現(xiàn)新功能的時(shí)候還是比較隨意的。

• 寫入一些簡短的假定或者背景信息，這些內(nèi)容可能對明年致力于這個(gè)功能的奉獻(xiàn)者很重要。

在執(zhí)行 repo init 后得到的獨(dú)特的 change ID，名稱和郵箱將會自動添加到你的 commit 信息中。

上傳到 gerrit

一旦 commit 你的更改到個(gè)人歷史，就可以上傳到 gerrit。

$ repo upload

如果你在同一個(gè)庫中選擇了多個(gè)分支，你將會得到提示，讓你選擇一個(gè)分支上傳。

上傳成功之后，repo 將會給你提供一個(gè) Gerrit 新頁面的 URL。預(yù)覽這個(gè)鏈接并在評審服務(wù)器上查看你的補(bǔ)丁，添加評論，或者給你的補(bǔ)丁請求特定的評審員。

上傳一個(gè)代替的補(bǔ)丁

假如一個(gè)評審員已經(jīng)看了你的補(bǔ)丁，并且要求你做一些小的更改。你可以通過 git 修改 commit 信息，這樣將會在 gerrit 中生成一個(gè)新的補(bǔ)丁，但是使用的是原先那個(gè) change ID。

注意，如果你在上傳補(bǔ)丁之前添加了其他 commits，你將需要手動移動你的 git HEAD。

$ git add -A
$ git commit --amend

當(dāng)你上傳了修改的補(bǔ)丁，它將在 gerrit 和本地 git 歷史中代替之前的。

解決同步?jīng)_突

如果提交到源碼中的其他補(bǔ)丁和你的有沖突，你將需要在源碼庫新 HEAD 的頂部 rebase（重新定義分支版本庫狀態(tài)）你的補(bǔ)丁。一個(gè)簡單的方法就是運(yùn)行：

$ repo sync

這個(gè)命令將會從服務(wù)器先 fetches 最新的源碼，然后會試圖自動 rebase HEAD 到新的遠(yuǎn)程 HEAD 上面。

如果自動 rebase 沒有成功，你必須手動執(zhí)行 rebase。

$ repo rebase

使用 git mergetool 可能幫助你處理 rebase 沖突。一旦你成功地合并沖突文件，

$ git rebase --continue

手動或者自動 rebase 完成之后，運(yùn)行 repo upload 來提交你 rebase 補(bǔ)丁。

提交被批準(zhǔn)之后

提交的內(nèi)容在通過檢查和驗(yàn)證過程之后，Gerrit 會自動的 merges 這個(gè)更改到公共的庫中。其他用戶可以運(yùn)行 repo sync 來 pull 這個(gè)更新到自己的本地。

檢查員和審核者

檢查一個(gè)更改

如果你被分配成這個(gè)更改內(nèi)容的批準(zhǔn)者，你需要決定接下來的內(nèi)容：

• 這個(gè)更改是不是符合項(xiàng)目一開始的目的？
• 這個(gè)更改是不是在現(xiàn)存的構(gòu)造中有效？
• 這個(gè)更改引入的設(shè)計(jì)缺陷是否會在將來出現(xiàn)問題？
• 這個(gè)更改是否遵循這個(gè)項(xiàng)目中已建立的最佳實(shí)踐？
• 這個(gè)更改是執(zhí)行描述方法的好方式？
• 這個(gè)更改是否引入任何安全或不穩(wěn)定的風(fēng)險(xiǎn)？

如果你準(zhǔn)許了這個(gè)改變，請?jiān)?Gerrit 中用 LGTM（Look Good to ME）標(biāo)記它。

審核更改

如果你被分配成這個(gè)更改內(nèi)容的審核者，你需要做接下來的內(nèi)容：

• 使用其中一種下載命令將這個(gè)更改 Patch 到自己的本地客戶端。
• 構(gòu)建和測試這個(gè)更改。
• 在 Gerrit 中，使用發(fā)布評論的方式來標(biāo)記這個(gè) commit，用“Verified”或者“Fails”，并且添加一個(gè)消息來解釋哪些問題是經(jīng)過鑒定的。

從 Gerrit 下載更改的內(nèi)容

已經(jīng)審核和合并之后的提交將會在下一次 repo sync 的時(shí)候被下載。如果你希望下載一個(gè)特定的沒有經(jīng)過檢驗(yàn)的更改，執(zhí)行：

$ repo download TARGET CHANGE

這個(gè) TARGET 就是你下載的更改將要放到本地目錄的位置，CHANGE 就是在 Gerrit 中的更改列表的數(shù)字。想要知道更多信息，請查看Repo reference。

怎么樣才能成為一個(gè)審核者或者檢驗(yàn)者？

簡單來說，需要對一個(gè)或者多個(gè) Android 項(xiàng)目貢獻(xiàn)高質(zhì)量代碼。想要了解更多關(guān)于 Android 開源社區(qū)的不同角色和都有誰參與的信息，可以查看 Project Roles。

Diffs 和評論

在 Gerrit 中點(diǎn)擊一個(gè)更改的 Id number 或者 Subject 可以打開這個(gè)更改的詳細(xì)信息。想知道現(xiàn)有的代碼和更新的代碼之間的差異，可以點(diǎn)擊文件名下的 Side-by-side diffs。

添加評論

在開源社區(qū)的任何一個(gè)人都可以使用 Gerrit 來給提交的源碼添加內(nèi)聯(lián)的評論。一個(gè)好的評論將會關(guān)聯(lián)行或者部分在 Gerrit 中的附加代碼。這或許是關(guān)于如何改進(jìn)一行代碼，簡短的或者建設(shè)性的意見，或者，這個(gè)也許是為什么作者這樣寫代碼就有意義的解釋。

想要添加內(nèi)聯(lián)評論，雙擊代碼中相關(guān)聯(lián)的行，并且在下一個(gè)打開的窗口寫上你的評論。你點(diǎn)擊保存之后，只有你可以看到你的評論。

想要發(fā)布你的評論，讓其他 Gerrit 使用者看到評論，點(diǎn)擊 Publish Comments 按鈕。你的評論內(nèi)容將會通過 email 發(fā)送給這個(gè)更改的所有當(dāng)事人，包括更改的擁有者，補(bǔ)丁更新者（如果和擁有者不是同一個(gè)人），還有所有當(dāng)前的檢查者。

Upstream 項(xiàng)目

Android 使用很多其他開源項(xiàng)目，比如，Linux 內(nèi)核和 WebKit，像在 Codelines，Branches，Releases 中描述的那樣。在 external/ 下的大多數(shù)項(xiàng)目，更改應(yīng)該被 upstream，然后 Android 維護(hù)者通知新的 upstream 版本將包括這些更改。讓我們跟蹤一個(gè)新的 upstream 版本，可能對上傳補(bǔ)丁有好處。但是如果這些項(xiàng)目被廣泛使用，像下面提到的大多數(shù)項(xiàng)目一樣，將很難做出改變，對于這樣的項(xiàng)目，我們傾向于每次發(fā)布版本都升級。

一個(gè)有趣的特殊情況是仿生（bionic）。很多代碼都是來源于 BSD，所以除非改變的是新的仿生代碼，我們寧愿看到一個(gè) upstream 修復(fù)，然后從 適當(dāng)?shù)?BSD 上 pull 一個(gè)完整的新的文件（很可悲的是我們同時(shí)有很多不同的 BSD，但是我們希望在未來解決這個(gè)問題，并且進(jìn)入一個(gè)我們更密切跟蹤 upstream 的位置）。

ICU4C

在 external/icu4c 目錄下，ICU4C 項(xiàng)目的所有改變，都應(yīng)該在 icu-project.org/ 里被 upstream。查看 Submitting ICU Bugs and Feature Requests 獲取更多信息。

LLVM/Clang/Compiler-rt

LLVM-related 項(xiàng)目（external/clang, external/compiler-rt, external/llvm）的所有更改都應(yīng)該在 llvm.org/ upstream。

mksh

external/mksh 目錄下，MirBSD Korn Shell 項(xiàng)目的所有更改要么發(fā)送 email 到 mirbsd.org（不需要訂閱提交）域名下的 miros-mksh，要么是 Launchpad 來進(jìn)行 upstream。

OpenSSL

external/openssl 目錄下的 OpenSSL 項(xiàng)目的所有更改都應(yīng)該在 openssl.org 中 upstream。

V8

external/v8 目錄下 V8 項(xiàng)目的所有更改都應(yīng)該提交到 code.google.com/p/v8 中 upstream。進(jìn)入 Contributing to V8 查看詳情。

WebKit

external/webkit 目錄下 WebKit 項(xiàng)目的所有更改都應(yīng)該在 webkit.org 中 upstream。這個(gè)過程首先是提出一個(gè) Webkit bug。這個(gè) bug 應(yīng)該是使用 Android 平臺和系統(tǒng)，并且這個(gè) bug 僅僅是針對于 Android 的。當(dāng)添加了修復(fù)提議并有測試，Bugs 將更容易引起檢查員的注意。查看 Contributing Code to WebKit 獲取更多信息。

zlib

external/zlib 目錄下 zlib 項(xiàng)目的所有更改狗應(yīng)該在 zlib.net 中 upstream。