顯示具有 gerrit 標籤的文章。 顯示所有文章
顯示具有 gerrit 標籤的文章。 顯示所有文章

2012年9月18日 星期二

Git and Gerrit installation

this memo references following url:
http://scmforge.com/?p=1
http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup
http://www.infoq.com/cn/articles/Gerrit-jenkins-hudson

also based on my trial to setup gerri,git on 64 bit ubuntu server as guest OS of vmware virtual machine runs on 64 bit win 7 host OS

First step – Git installation:

As I use Ubuntu – this task is very simple. Just run one command like below:
root@scmforge:~# sudo apt-get -y install git-core
and verify installation:
root@scmforge:~# git --version
git version 1.7.5.4

git setup:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Second step – Gerrit installation:

I prefer to use functional accounts for each of services on my servers so first I create gerrit user:
root@scmforge:~# adduser gerrit
root@scmforge:~# su - gerrit
gerrit@scmforge:~$

To build Gerrit war package – Maven and some Java JDK is necessary as Gerrit is Java based tool, in my case I used the following command to install both:
root@scmforge:~# apt-get install maven2 openjdk-6-jdk
After gerrit user is already created and all prerequisites to build and run Gerrit are installed – now is the time to get Gerrit sources and prepare executable package:
root@scmforge:~# su - gerrit
wget
http://gerrit.googlecode.com/files/gerrit-2.4.2.war
gerrit@scmforge:~$ git clone https://gerrit.googlesource.com/gerrit
Cloning into gerrit...
remote: Counting objects: 60865, done
remote: Finding sources: 100% (60865/60865)
remote: Getting sizes: 100% (22864/22864)
remote: Compressing objects: 100% (22858/22858)
remote: Total 60865 (delta 34139), reused 60677 (delta 34056)
Receiving objects: 100% (60865/60865), 11.74 MiB | 4.36 MiB/s, done.
Resolving deltas: 100% (34237/34237), done.
gerrit@scmforge:~$ cd gerrit/
gerrit@scmforge:~/gerrit$ mvn package

When Maven finished building, WAR file was created in gerrit-war/target/ directory, in my case it was exactly: ./target/gerrit-2.3.war

Some database will be needed (MySQL, PostgreSQL, or simple H2 can be used) so we can create it as usually, by:
postgres=# CREATE ROLE gerrit LOGIN ENCRYPTED PASSWORD 'gerrit' NOINHERIT VALID UNTIL 'infinity';
CREATE ROLE
postgres=# CREATE DATABASE gerrit_playground WITH ENCODING='UTF8' OWNER=gerrit;
CREATE DATABASE


Third step – creating Gerrit environment:

Now we can create playground environment by invoking Gerrit with init parameter and answering few simple questions:
gerrit@scmforge:~$ java -jar gerrit-2.3.war init -d playground
java -jar /home/gerrit/gerrit-2.4.2.war init -d playground
 *** Gerrit Code Review 2.3
Create '/home/gerrit/playground' [Y/n]? Y
*** Git Repositories
Location of Git repositories [git]: git
*** SQL Database
Database server type [H2/?]: H2

mysql
*** User Authentication
Authentication method [OPENID/?]: development_become_any_account
*** Email Delivery
SMTP server hostname [localhost]:
SMTP server port [(default)]:
SMTP encryption [NONE/?]:
SMTP username :
*** Container Process
Run as [gerrit]: gerit
Java runtime [/usr/lib/jvm/java-6-openjdk/jre]: /usr/lib/jvm/java-6-openjdk/jre
Copy gerrit.war to /home/gerrit/playground/bin/gerrit.war [Y/n]?
Copying gerrit.war to /home/gerrit/playground/bin/gerrit.war
*** SSH Daemon
Listen on address [*]: *
Listen on port [29418]: 29418
Gerrit Code Review is not shipped with Bouncy Castle Crypto v144
If available, Gerrit can take advantage of features
in the library, but will also function without it.
Download and install it now [Y/n]?
Downloading http://www.bouncycastle.org/download/bcprov-jdk16-144.jar ... OK
Checksum bcprov-jdk16-144.jar OK
Generating SSH host key ... rsa... dsa... done
*** HTTP Daemon
Behind reverse proxy [y/N]? N
Use SSL (https://) [y/N]? N
Listen on address [*]: *
Listen on port [8080]: 8080
Initialized /home/gerrit/playground
Executing /home/gerrit/playground/bin/gerrit.sh start

/home/gerrit/gerrit/playground/bin/gerrit.sh start
Starting Gerrit Code Review: OK
Waiting for server to start ... OK
Opening browser ...
Please open a browser and go to http://scmforge.com:8080/#/admin/projects/

g.s:8080/#/admin/projects/
As I had some serious issues with PostgreSQL connection I chose H2 as backbone database because it was the fastest workaround in my case and I do not need nothing more right now.
After opening suggested URL – I could see the following screen:

Become option allows You to create admin user account and look around at all Gerrit functionality (which is not integrated with Git yet). After that You can create Your fist Sandbox project with default settings proposed by Gerrit.
Remember to add Your SSH public key to Your account/settings – without it working with Gerrit is not possible. In Your settings You have to also specify Your Username. (which is actually SSH user)
If all setup is ok, You should be able to see similar server response after trying to log in:
szwed@vaio:~$ ssh -p 29418 szwed@scmforge.com
ssh -p 29418 d68fbe50@g.s
**** Welcome to Gerrit Code Review ****
Hi Piotr Szwed, you have successfully connected over SSH.
Unfortunately, interactive shells are disabled.
To clone a hosted Git repository, use:
git clone ssh://szwed@scmforge.com:29418/REPOSITORY_NAME.git
Connection to scmforge.com closed.

If You have similar results – it means that basic setup is OK and We can jump to the further steps.


Fourth step – Gerrit integration with GIT:

So.. We have already Gerrit setup and working, We have already created first project, our SSH connection is working well – now is the time to clone Sandbox repository and make some test commit. I tried the following waycd
szwed@vaio:~$ git clone ssh://szwed@scmforge.com:29418/Sandbox.git
git clone ssh://d68fbe50@g.s:29418/symfonyproject.git
Cloning into 'Sandbox'...
remote: Counting objects: 2, done
remote: Finding sources: 100% (2/2)
remote: Total 2 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (2/2), done.
szwed@vaio:~$ cd Sandbox/

cd symfonyproject
szwed@vaio:~/Sandbox$ echo "Test text." > test.txt
cp -r Symfony/* symfonyproject/
szwed@vaio:~/Sandbox$ git add test.txt

git add .
szwed@vaio:~/Sandbox$ git commit -a -m "First test commit."

git commit -m 'initial symfony project version'
[master 44ca585] First test commit.
Committer: Piotr Szwed <szwed@vaio.(none)>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
1 file changed, 1 insertion(+)
create mode 100644 test.txt


create a group for your project

go to
g.s:8080/#/admin/projects/
click admin
click groups
click hyperlink  Create New Group 
enter the name of your project.
e.g.:
symfonyproject
 


give this group with push permission of your project

go to
g.s:8080/#/admin/projects/
click on projects
click on list
click on hyperlink with name of your project
click access
click edit
click on Add Reference
click on drop down menu with text:Add permission
click on push in that menu
enter the name of group you create
e.g.:
symfonyproject
click add
click Save changes




And push our changes to the Gerrit server:

szwed@vaio:~/Sandbox$ git push ssh://szwed@scmforge.com:29418/Sandbox.git 
git push ssh://d68fbe50@g.s:29418/symfonyproject.git
HEAD:refs/for/master
Counting objects: 4, done.
Writing objects: 100% (3/3), 256 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://szwed@scmforge.com:29418/Sandbox.git
* [new branch] HEAD -> refs/for/master
szwed@vaio:~/Sandbox$

After that my change was ready for review as on the picture presented below:

As a result I am able to review and approve the change. Some simple Project groups and access modifications may be needed here as by default Gerrit does not provide useful setup and Workflow.
Now is the time to invite developers and encourage Them to use Gerrit

上述的推送,沒有經過 code review 的流程


採用 code review 流程的推送方式,

需經過以下設定後推送,

 「 Gerrit不希望我們直接覆寫Git代碼庫中的任何分支,而是將變更推送到另一個refspec中,這讓Gerrit有機會在代碼審查中修改代碼。最簡單的方法是為推送配置一個默認的refspec:

$ git config remote.origin.push refs/heads/*:refs/for/*
$ git push origin


前段引文,引用自 URL :
http://www.infoq.com/cn/articles/Gerrit-jenkins-hudson

git 資料轉移至 gerrit server

舊有的 git 資料,
如欲增加 code review 機制,要採用 gerrit 作為 code review server 時,
需進行以下設定後,
方可將舊有 git 資料傳至 gerrit server

新增 project

可透過 gerrit server 提供的網頁介面
(example url:
http://g.s:8080/#/admin/projects/
)
新增 project (e.g.:fromsvn)

給予上傳者 permission

以 gerrit server 提供的網頁介面,給予上傳者所屬的 group (e.g.:Administrators)如下的permission:

Reference:
refs/heads/*

Push Exclusive



Reference:
refs/*

Create Reference Exclusive

Forge Committer Identity Exclusive

git 須設定 remote


git remote add test_git ssh://g.s:29418/fromsvn.git

push to gerrit


http://www.infoq.com/cn/articles/Gerrit-jenkins-hudson

Git、Gerrit與Jenkins/Hudson CI服務器

作者 Alex Blewitt 譯者 丁雪豐 發佈於 2011年9月6日
領域
過程 & 實踐,
語言 & 開發
主題
團隊協作 ,
Java ,
協作 ,
分佈式團隊 ,
團隊工作 ,
敏捷
本文講述了如何為基於團隊的代碼審查系統配置Git、Gerrit與Jenkins/Hudson,正如我在《Git, Gerrit and Jenkins for iOS development》《Gerrit Git Review with Jenkins CI Server》演講(以及第一次提出這種做法的《Someday...》)中所倡導的那樣。 文中的範例假定你所使用的操作系統是OS X或Linux,但是如果你願意,也可以在Windows上運行它們。

配置Git

很多系統(例如Linux)已經默認提供了Git,在Git主頁也可以找到安裝程序。對於Windows用戶,最好的選擇是MsysGit。請注意,如果你安裝了Apple Developer Tools (for Xcode 4),那麼其中已經自帶Git二進制包了。如果遇到了問題,help.github.com中可以找到很多非常出色的指南。
因為所有的Git提交都帶有作者和電子郵件地址,如果你還沒有設置過這些內容,請執行以下命令進行配置:
$ git config --global user.name "Alex Blewitt"
$ git config --global user.email Alex.Blewitt@example.com
最好有一個Git代碼庫。Gerrit在初始化階段會自動掃瞄Git代碼庫,這樣做比在後期配置代碼庫容易一些,因此最好在初始化Gerrit前準備好Git代碼庫。
如果還沒有Git代碼庫,可以創建一個:
git init --bare /path/to/gits/example.git

Gerrit

可以從http://code.google.com/p/gerrit/下載到Gerrit,那是一個WAR文件。Gerrit有很好的文檔(目前的最新文檔是2.2.1,但也可用於2.1.7)和安裝指南
Gerrit在運行時需要用到數據庫(用於存儲代碼審查的信息)。目前支持的數據庫包括H2、PostgreSQL和MySQL。在沒有進行額外配置的情況下,它默認使用H2。
請注意,Gerrit 2.2.x正把項目配置、權限和其他元數據移到Git存儲中,這樣就可以通過Git進行訪問和版本控制。在2.2.x中,這個轉變會慢慢擴展到其他類型的元數據上,包含代碼評審內容。詳見2.2.0版本的發布說明
要初始化Gerrit,運行java -jar gerrit.war init -d /path/to/location會在指定路徑上安裝Gerrit運行時。
如果是在交互終端中運行的,安裝程序會提幾個問題,例如:
  • Git代碼庫的位置 [git]
  • 導入現有代碼庫 [Y/n]
  • 數據庫服務器類型 [H2/?]
  • 身份驗證方法 [OPENID/?]
  • SMTP服務器主機名 [localhost]
  • SMTP服務器端口 [(default)]
  • SMTP加密 [NONE/?]
  • SMTP用戶名
  • 以何種身份運行 [you]
  • Java運行時 [/path/to/jvm]
  • 將gerrit.war複製到/path/to/location/bin/gerrit.war [Y/n]
  • 監聽地址 [*]
  • 監聽端口 [29418]
  • 下載並安裝Bouncy Castle [Y/n]
  • 位於HTTP反向代理之後 [y/N]
  • 使用SSL [y/N]
  • 監聽地址 [*]
  • 監聽端口 [8080]
其中大部分可以保留默認值,但是有幾個需要重點關注。
  • Git代碼庫的位置要指向正確的位置。默認值是位於安裝目錄中的'git'目錄,也可以是其他不同位置(例如/var/gits等等)。應該先配置好這個路徑,因為在Gerrit啟動時它會先掃瞄該目錄來添加新項目。
  • 監聽地址對有多個地址(例如IPv4和IPv6)的主機很有用,它可以限定使用哪個地址。*表示本地主機上的任意地址。
  • 監聽端口是一個端口號。29418是默認的Gerrit SSH端口,而8080是默認的Gerrit Web端口。但是如果8080已經被別的應用程序佔用了,那麼你可能會想修改第二個端口。
  • 身份驗證方法確定了如何登錄Gerrit。如果你想掛入某個現有的身份驗證提供方(例如Google Accounts),那麼可以使用OpenID。但對測試而言(還有上面提到的範例),可以使用 development_become_any_account。鍵入?會顯示一個可用方法的列表。
Gerrit啟動後,會打開一個瀏覽器,顯示Gerrit主頁。登錄的第一個用戶將自動成為管理員;所有後續登錄的用戶都是無權限用戶。如果你選擇 了development_become_any_account,在頁面頂端會有一個Become鏈接,通過它可以進入註冊/登錄頁面。

註冊用戶

為了使用Gerrit,你需要一個賬號,生成一個SSH密鑰對。在命令行中運行 ssh-keygen -t rsa -b 2048可以生成密鑰對,將其放到你的.ssh目錄中。如果你需要更多信息,可以訪問這篇博文,這是我六年前寫的SSH密鑰相關文章。此外,GitHub 幫助頁面中也有更多相關信息。
默認文件名為id_rsa(這是私鑰)和id_rsa.pub(這是公鑰)。你只能給別人公鑰,千萬別給別人私鑰。
有了密鑰,你就可以在Gerrit中註冊新賬戶了。點擊頂部右端的「Become」鏈接,然後再點擊「New account」按鈕,輸入Git知道的名稱和電子郵件(即上面用git config配置的),這些內容要完全匹配(包括大小寫)。保存變更,然後選擇一個唯一的用戶名(填入了名稱後點擊'select username',例如demo)。
頭痛的電子郵件 就算是development_become_any_account模式,Gerrit也會給你發送電子郵件以驗證郵件地址。不通過驗證的話就無法使用該電子郵件地址,你也無法提交代碼。
我們可以很快處理掉這個問題,因此如果Gerrit目前不讓你註冊你的郵箱地址,請不用擔心。
在'add SSH public key'文本框中,添加.pub文件中的公鑰。如果你使用的是OS X,pbcopy < ~/.ssh/id_rsa.pub就可輕鬆搞定。記住要點擊「Add」保存公鑰。
點擊Continue後應該就能登錄到Gerrit的主窗口了。到目前為止一切還不錯,現在可以測試SSH的連通性了。
鍵入ssh -p 29418 demo@localhost會嘗試連接Gerrit服務器,會出現以下三者之一:
  1. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
    
    這並沒有看上去那麼糟。它只是說你的~/.ssh/known_hosts文件中有舊的密鑰。最懶的一種修複方法是刪除這個文件(這是GitHub推薦的做法)。更好的方法是找到提示出錯的那一行,把它刪了:
    Offending key in /Users/demo/.ssh/known_hosts:123
    
    你可以用任何文本編輯器來刪除known_hosts文件中的第123行。在標準UNIX配置下,可以用以下命令自動刪除:
    sed -i '' '123d' ~/.ssh/known_hosts
  2. The authenticity of host '[localhost]:29418 ([::1]:29418)' can't be established.
    RSA key fingerprint is e8:e2:fe:19:6f:e2:db:c1:05:b5:bf:a6:ad:4b:04:33.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '[localhost]:29418' (RSA) to the list of known hosts.
    Permission denied (publickey).
    
    如果看到這個消息,說明Gerrit沒有識別出你提交的任何密鑰。ssh默認會發送id_rsa,要確認它的確發送了該值,可以查看.ssh/config,文件頭上有一行IdentityFile ~/.ssh/id_rsa。可以運行ssh -v查看發送的內容:
    debug1: Next authentication method: publickey
    debug1: Trying private key: /Users/demo/.ssh/id_dsa
    debug1: Offering public key: /Users/demo/.ssh/id_rsa
    
    假設已經發送了正確的密鑰,那麼在settings - ssh public keys菜單項中檢查該密鑰是否關聯了Gerrit中的用戶。如果沒有的話點擊'Add Key'並和之前一樣粘貼公鑰。
    如果Gerrit還是說你未經身份驗證,檢查用戶名和配置頁面裡的用戶名是否一致。如果用戶名不同,試試ssh -p 29418 username@localhost。
    最後,要驗證具體的密鑰,可以運行ssh -i ~/.ssh/id_rsa顯式地選擇要使用的密鑰,而不是讓它自動選擇密鑰。如果這樣可以工作,但不帶-i參數卻不行的話,那麼問題出在你的~ /.ssh/config文件裡──你需要保證選擇了合適的IdentityFile。
  3.   ****    Welcome to Gerrit Code Review    ****
    
      Hi demo, you have successfully connected over SSH.
    
      Unfortunately, interactive shells are disabled.
      To clone a hosted Git repository, use:
    
      git clone ssh://demo@localhost:29418/REPOSITORY_NAME.git
    
    Connection to localhost closed.
    
    如果看到這個提示,說明Gerrit已經正常工作了。

修正電子郵件地址

如果之前你無法在Gerrit中註冊電子郵件地址,那麼可以手工進行註冊。我們可以停止Gerrit,運行GSQL工具更新特定數據字段。
$ bin/gerrit.sh stop
$ java -jar bin/gerrit.war gsql
Welcome to Gerrit Code Review 2.1.6.1
(H2 1.2.134 (2010-04-23))

Type '\h' for help.  Type '\r' to clear the buffer.

gerrit> select * from ACCOUNT_EXTERNAL_IDS;
 ACCOUNT_ID | EMAIL_ADDRESS          | PASSWORD | EXTERNAL_ID
 -----------+------------------------+----------+------------------------------------------
 1000000    | NULL                   | NULL     | uuid:ac1b8a08-2dd1-4aa1-8449-8b2994dffaed
 1000000    | NULL                   | NULL     | username:demo
(2 rows; 23 ms)
gerrit> update ACCOUNT_EXTERNAL_IDS set EMAIL_ADDRESS='alex.blewitt@example.com' where ACCOUNT_ID=1000000;
UPDATE 2; 5 ms
gerrit> select * from ACCOUNT_EXTERNAL_IDS;
 ACCOUNT_ID | EMAIL_ADDRESS          | PASSWORD | EXTERNAL_ID
 -----------+------------------------+----------+------------------------------------------
 1000000    | alex.blewitt@example.com | NULL     | uuid:ac1b8a08-2dd1-4aa1-8449-8b2994dffaed
 1000000    | alex.blewitt@example.com | NULL     | username:demo
(2 rows; 23 ms)
gerrit> \q
Bye
$ bin/gerrit.sh start

創建項目,克隆並推送代碼

開始前,我們需要先在Gerrit中創建一個項目。如果Gerrit沒有在你的範例目錄中檢測到項目,在它運行時,我們可以創建一個項目。
$ ssh -p 29418 demo@localhost gerrit create-project --name example.git
上述命令會創建一個名為example的項目,在之前指定的Git目錄裡初始化一個空的代碼庫。如果已經有一個代碼庫了,Gerrit不允許創建同名代碼庫——但你可以先對它進行臨時重命名,隨後再把名字改回來。
隨後,可以創建一個克隆:
$ git clone ssh://demo@localhost:29418/example.git
Cloning into example...
warning: You appear to have cloned an empty repository.
我們可以向代碼庫進行提交和推送,就和其他Git系統一樣:
$ cd example
$ echo hello > world
$ git add world
$ git commit -m "The World"
[master (root-commit) 06bf85e] The World
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 world
$ git push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 217 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://me@localhost:29418/example.git
 ! [remote rejected] master -> master (prohibited by Gerrit)
error: failed to push some refs to 'ssh://demo@localhost:29418/example.git'
這是什麼情況?Gerrit不希望我們直接覆寫Git代碼庫中的任何分支,而是將變更推送到另一個refspec中,這讓Gerrit有機會在代碼審查中修改代碼。最簡單的方法是為推送配置一個默認的refspec:
$ git config remote.origin.push refs/heads/*:refs/for/*
$ git push origin
Counting objects: 3, done.
Writing objects: 100% (3/3), 217 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://demo@localhost:29418/example.git
 * [new branch]      master -> refs/for/master

gerrit OpenID authentication


192.168.200.143:8080/Documentation/access-control.html

If the Gerrit instance is configured to use OpenID authentication, an account’s effective group membership will be restricted to only the Anonymous Users and Registered Users groups, unless all of its OpenID identities match one or more of the patterns listed in the auth.trustedOpenID list from gerrit.config.

gerrit.config auth.trustedOpenID

To trust only Google Accounts:
git config --file $site_path/gerrit.config auth.trustedOpenID 'https://www.google.com/accounts/o8/id?id='

sudo git config --file /home/gerrit/playground/etc/gerrit.config auth.trustedOpenID 'https://www.google.com/accounts/o8/id?id='

2012年9月14日 星期五

gerrit push branch permission

gerrit push branch permission

https://review.typo3.org/Documentation/access-control.html#category_create

Create reference

The create reference category controls whether it is possible to create new references, branches or tags. This implies that the reference must not already exist, it’s not a destructive permission in that you can’t overwrite or remove any previosuly existing references (and also discard any commits in the process).
It’s probably most common to either permit the creation of a single branch in many gits (by granting permission on a parent project), or to grant this permission to a name pattern of branches.
This permission is often given in conjunction with regular push branch permissions, allowing the holder of both to create new branches as well as bypass review for new commits on that branch

Push

This category controls how users are allowed to upload new commits to projects in Gerrit. It can either give permission to push directly into a branch, bypassing any code review process that would otherwise be used. Or it may give permission to upload new changes for code review, this depends on which namespace the permission is granted to

2012年9月11日 星期二

gerrit introducation


http://gerrit-documentation.googlecode.com/svn/Documentation/2.4.2/intro-quick.html

Any team with more than one member has a central source repository of some kind (or they should). Git can theoretically work without such a central location but in practice there is usually a central repository. This serves as the authoritative copy of what is actually in the project. This is what everyone fetches from and pushes to and is generally where build servers and other such tools get the source from.
Authoritative Source Repository
Figure 1. Central Source Repository
Gerrit is deployed in place of this central repository and adds an additional concept, a store of pending changes. Everyone still fetches from the authoritative repository but instead of pushing back to it, they push to this pending changes location. A change can only be submitted into the authoritative repository and become an accepted part of the project once the change has been reviewed and approved.
Gerrit in place of Central Repository
Figure 2. Gerrit in place of Central Repository
Like any repository hosting solution, Gerrit has a powerful access control model. Users can even be granted access to push directly into the central repository, bypassing code review entirely. Gerrit can even be used without code review, used simply to host the repositories and controlling access. But generally it’s just simpler and safer to go through the review process even for users who are allowed to directly push.

The Life and Times of a Change

The easiest way to get a feel for how Gerrit works is to follow a change through its entire life cycle. For the purpose of this example we’ll assume that the Gerrit Server is running on a server called gerrithost with the HTTP interface on port 8080 and the SSH interface on port 29418. The project we’ll be working on is called RecipeBook and we’ll be developing a change for the master branch.

Cloning the Repository

Obviously the first thing we need to do is get the source that we’re going to be modifying. As with any git project you do this by cloning the central repository that Gerrit is hosting. e.g.
$ git clone ssh://gerrithost:29418/RecipeBook.git RecipeBook
Cloning into RecipeBook...
Then we need to make our actual change and commit it locally. Gerrit doesn’t really change anything here, this is just the standard editing and git. While not strictly required, it’s best to include a Change-Id in your commit message so that Gerrit can link together different versions of the same change being reviewed. Gerrit contains a standard Change-Id commit-msg hook that will generate a unique Change-Id when you commit. If you don’t do this then Gerrit will generate a Change-Id when you push your change for review. But because you don’t have the Change-Id in your commit message you’ll need to manually copy it in if you need to upload another version of your change. Because of this it’s best to just install the hook and forget about it.

Creating the Review

Once you’ve made your change and committed it locally it’s time to push it to Gerrit so that it can be reviewed. This is done with a git push to the Gerrit server. Since we cloned our local repository directly from Gerrit it is the origin so we don’t have to redefine the remote.
$ <work>
$ git commit
[master 9651f22] Change to a proper, yeast based pizza dough.
 1 files changed, 3 insertions(+), 2 deletions(-)
$ git push origin HEAD:refs/for/master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 542 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: New Changes:
remote:   http://gerrithost:8080/68
remote:
To ssh://gerrithost:29418/RecipeBook.git
 * [new branch]      HEAD -> refs/for/master
The only different thing about this is the refs/for/master branch. This is a magic branch that creates reviews that target the master branch. For every branch Gerrit tracks there is a magic refs/for/<branch_name> that you push to to create reviews.
In the output of this command you’ll notice that there is a link to the HTTP interface of the Gerrit server we just pushed to. This is the web interface where we will review this commit. Let’s follow that link and see what we get.
Gerrit Review Screen
Figure 3. Gerrit Code Review Screen
This is the Gerrit code review screen where someone will come to review the change. There isn’t too much to see here yet, you can look at the diff of your change, add some comments explaining what you did and why, you may even add a list of people that should review the change.
Reviewers can find changes that they want to review in any number of ways. Gerrit has a capable search that allows project leaders (or anyone else) to find changes that need to be reviewed. Users can also setup watches on Gerrit projects with a search expression, this causes Gerrit to notify them of matching changes. So adding a reviewer when creating a review is just a recommendation.
At this point the change is available for review and we need to switch roles to continue following the change. Now let’s pretend we’re the reviewer.

Reviewing the Change

The reviewer’s life starts at the code review screen shown above. He can get here in a number of ways, but for some reason they’ve decided to review this change. Of particular note on this screen are the two "Need" lines:
* Need Verified
* Need Code-Review
Gerrit’s default work-flow requires two checks before a change is accepted. Code-Review is someone looking at the code, ensuring it meets the project guidelines, intent etc. Verifying is checking that the code actually compiles, unit tests pass etc. Verification is usually done by an automated build server rather than a person. There is even a Gerrit Trigger Jenkins Plugin that will automatically build each uploaded change and update the verified score accordingly.
It is important to note that Code-Review and Verification are different permissions in Gerrit, allowing these tasks to be separated. For example, an automated process would have rights to verify but not to code-review.
Since we are the code reviewer, we’re going to review the code. To do this we can view it within the Gerrit web interface as either a unified or side-by-side diff by selecting the appropriate option. In the example below we’ve selected the side-by-side view. In either of these views you can add comments by double clicking on the line (or single click the line number) that you want to comment on. Once published these comments are viewable to all, allowing discussion of the change to take place.
Adding a Comment
Figure 4. Side By Side Patch View
Code reviewers end up spending a lot of time navigating these screens, looking at and commenting on these changes. To make this as efficient as possible Gerrit has keyboard shortcuts for most operations (and even some operations that are only accessible via the hot-keys). At any time you can hit the ? key to see the keyboard shortcuts.
Hot Key Help
Figure 5. Gerrit Hot Key Help
Once we’ve looked over the changes we need to complete reviewing the submission. To do this we click the Review button on the change screen where we started. This allows us to enter a Code Review label and message.
Reviewing the Change
Figure 6. Reviewing the Change
The label that the reviewer selects determines what can happen next. The +1 and -1 level are just an opinion where as the +2 and -2 levels are allowing or blocking the change. In order for a change to be accepted it must have at least one +2 and no -2 votes. Although these are numeric values, they in no way accumulate; two +1s do not equate to a +2.
Regardless of what label is selected, once the Publish Comments button has been clicked, the cover message and any comments on the files become visible to all users.
In this case the change was not accepted so the creator needs to rework it. So let’s switch roles back to the creator where we started.

Reworking the Change

As long as we set up the Change-Id commit-msg hook before we uploaded the change, re-working it is easy. All we need to do to upload a re-worked change is to push another commit that has the same Change-Id in the message. Since the hook added a Change-ID in our initial commit we can simply checkout and then amend that commit. Then push it to Gerrit in the same way as we did to create the review. E.g.
$ <checkout first commit>
$ <rework>
$ git commit --amend
$ git push origin HEAD:refs/for/master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 546 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://gerrithost:29418/RecipeBook.git
 * [new branch]      HEAD -> refs/for/master
Note that the output is slightly different this time around. We don’t get told about a new review because we’re adding to an existing review. Having uploaded the reworked commit we can go back into the Gerrit web interface and look at our change.
Reviewing the Rework
Figure 7. Reviewing the Rework
If you look closely you’ll notice that there are now two patch sets associated with this change, the initial submission and the rework. Rather than repeating ourselves lets assume that this time around the patch is given a +2 score by the code reviewer.

Trying out the Change

With Gerrit’s default work-flow there are two sign-offs, code review and verify. Verifying means checking that the change actually works. This would typically be checking that the code compiles, unit tests pass and similar checks. Really a project can decide how much or little they want to do here. It’s also worth noting that this is only Gerrit’s default work-flow, the verify check can actually be removed or others added.
As mentioned in the code review section, verification is typically an automated process using the Gerrit Trigger Jenkins Plugin or similar. But there are times when the code needs to be manually verified, or the reviewer needs to check that something actually works or how it works. Sometimes it’s just nice to work through the code in a development environment rather than the web interface. All of these involve someone needing to get the change into their development environment. Gerrit makes this process easy by exposing each change as a git branch. So all the reviewers need to do is fetch and checkout that branch from Gerrit and they will have the change.
We don’t even need to think about it that hard, if you look at the earlier screen shots of the Gerrit Code Review Screen you’ll notice a download command. All we need to do to get the change is copy paste this command and run it in our Gerrit checkout.
$ git fetch http://gerrithost:8080/p/RecipeBook refs/changes/68/68/2
From http://gerrithost:8080/p/RecipeBook
 * branch            refs/changes/68/68/2 -> FETCH_HEAD
$ git checkout FETCH_HEAD
Note: checking out 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at d5dacdb... Change to a proper, yeast based pizza dough.
Easy as that, we now have the change in our working copy to play with. You might be interested in what the numbers of the refspec mean.
  • The first 68 is the id if the change mod 100. The only reason for this initial number is to reduce the number of files in any given directory within the git repository.
  • The second 68 is the full id of the change. You’ll notice this in the URL of the Gerrit review screen.
  • The 2 is the patch-set within the change. In this example we uploaded some fixes so we want the second patch set rather than the initial one which the reviewer rejected.

Manually Verifying the Change

For simplicity we’re just going to manually verify the change. The Verifier may be the same person as the code reviewer or a different person entirely. It really depends on the size of the project and what works. If you have Verify permission then when you click the Review button in the Gerrit web interface you’ll be presented with a verify score.
Verifying the Change
Figure 8. Verifying the Change
Unlike the code review the verify check doesn’t have a +2 or -2 level, it’s either a pass or fail so all we need for the change to be submitted is a +1 score (and no -1’s).

Submitting the Change

You might have noticed that in the verify screen shot there are two buttons for submitting the score Publish Comments and Publish and Submit. The publish and submit button is always visible, but will only work if the change meets the criteria for being submitted (I.e. has been both verified and code reviewed). So it’s a convenience to be able to post review scores as well as submitting the change by clicking a single button. If you choose just to publish comments at this point then the score will be stored but the change won’t yet be accepted into the code base. In this case there will be a Submit Patch Set X button on the main screen. Just as Code Review and Verify are different operations that can be done by different users, Submission is a third operation that can be limited down to another group of users.
Activating the Publish and Submit or Submit Patch Set X button will merge the change into the main part of the repository so that it becomes an accepted part of the project. After this anyone fetching the git repository will receive this change as a part of the master branch.