GerritWorkflow/ja

Gerrit ワークフロー　クイックリファレンス

このセクションは新しいリポジトリで作業を始める為に必要なコマンドの クイックリファレンスとして意図されています。使用中のワークフローを 理解する為にこの文書全体を読んで、あなたが新しい OpenStack プロジェ クト上で作業を開始する必要がある時、このセクションを参照して下さい。

セットアップのより完全な説明は、GerritJenkinsGithub を参照して下さい。

<<TableOfContents()>>

アカウントのセットアップ

Make sure you have a launchpad account, and you have uploaded your ssh public keys to it.

Visit https://review.openstack.org/ and click the Sign In link at the top-right corner of the page. Log in with your Launchpad ID.

Because Gerrit uses Launchpad OpenID single sign-on, you won't need a separate password for Gerrit, and once you log in to one of Launchpad, Gerrit, or Jenkins, you won't have to enter your password for the others.

Gerrit accounts are automatically synchronized with Launchpad, so your Gerrit account should already have the same username, full name, email address, ssh keys, and group membership.

Some information in Launchpad is not publicly available and so may not be copied over. The first time you log into Gerrit, you should click the Settings link at the top of the page, and then make sure that your Contact Information, SSH Public Keys, and Groups look correct. If not, please register your email address and SSH keys.

Ensure that you have run these steps to let git know about your email address:

git config --global user.name "Firstname Lastname"
git config --global user.email "your_email@youremail.com"

To check your git configuration:

git config --list

Git Review インストール

私たちは、OpenStack 開発で使用されるコードレビューシステム 「Gerrit」を使った作業の詳細全てを扱う git のサブコマンドである 「git-review」ツールの使用をお勧めします。作業を開始する前に、あな たのシステムに git-review がインストールされている事を確認して下さ い。

On Ubuntu, or most other Unix-like systems, it is as simple as:

pip install git-review

On Ubuntu Precise (12.04) and later, git-review is included in the distribution, so install it as any other package:

apt-get install git-review

On Fedora 16 and later, git-review is included into the distribution, so install it as any other package:

yum install git-review

On Fedora 15 and earlier, or on Red Hat Enterprise Linux, you have to install pip (its package name is `python-pip`), then install git-review using pip in a conventional way. %%Fedora では、最初に「python-pip」パッケージがインストールされてな %%ければなりません。その後、「git-review」をインストールするコマンド %%は以下の通りです。 %% %%

%%$ sudo pip-python install git-review
%%

git-review による gerrit との全てのやりとりは、通常の git コマンド のシーケンスです。ここで何が行われているかをもっと知りたい場合 は、-v をオプションに付けて下さい。実行中のコマンド全てが表示され るようになります。

プロジェクトのセットアップ

通常の方法でプロジェクトを複製します。例：

git clone git://github.com/openstack/nova.git

この時点で Gerrit について知るために、あなたのプロジェクトを設定す るようgit-review に依頼したいかも知れません(そうでないとしても、最 初にレビューの為に変更をサブミットする際にはこのようになります)。 この為には(もう一度、Nova を例に取ると):

cd nova
git review -s

git-review は、あなたの ssh キーであなたが gerrit にログイン出来る 事をチェックします。本コマンドは あなたの gerrit/launchpad ユーザ 名が現在実行中のユーザと同じであると仮定しています。もし(ssh キー が)機能しない場合、本コマンドはあなたに gerrit/launchpad ユーザ名 を問い合わせるでしょう。

In the project directory, you have a `.git` hidden directory and a `.gitreview` hidden file. You can see them with:

ls -la

通常のワークフロー

一度あなたのローカルリポジトリが上記のようにセットアップされたら、 以下のワークフローを使用しなければなりません。

アップストリームの最新の変更が反映されている事を確認します。

git remote update
git checkout master
git pull origin master

あなたの作業を保持する為の トピックブランチを作成し、そ こに切り替えます。 もしあなたがブループリント(機能案)上で作業している場合、あなたのト ピックブランチ名をbp/BLUEPRINTにして下さい(BLUEPRINT の部分 は launchpad 中のブループリント名、例：「bp/authentication」)。そ うでない場合、Gerrit 中であなたの変更がトピックとして表示されるの で、意味のある名前を付けて下さい。

git checkout -b TOPIC-BRANCH

変更のコミット

git のコミットメッセージは短い 50 文字以下の単一段落の概要で始まる 必要があります。その下の段落はより詳細な変更を説明すべきです。

もしあなたの変更があるブループリントまたはバグを参照している場合、 以下の書式を使用してコミットメッセージ中でそれらに言及する事を忘れ ないで下さい。

blueprint BLUEPRINT
bug #######

例：

Adds keystone support.

Implements blueprint authentication.  Fixes bug 123456.

(Long description of the change).

変更を作成し、コミットして、レビューの為にサブミットして下さい。

git commit -a
git review

#!wiki caution
'''注意'''

あなたのマスターブランチに変更をチェックインしないで下さい。これを
やってしまうと、新しいアップストリームの変更を pull する際、マージ
コミット(merge commits)を引き起こしてしまい、マージコミットが
Gerrit によって受け入れ(accept)られなくなります。

チェックインの前に「./run_tests.sh -p」を実行する事を忘れないで下
さい。

Review

Once the code is committed, it appears at https://review.openstack.org. Please refer http://wiki.openstack.org/GerritJenkinsGithub for more information. If the link corresponding to your code is clicked, it will show the status and other information. Automatic testing will be done and the results will be displayed once they are complete. Reviewers will come and review and leave comments in the comment box or in the code itself.

If there is an in-line comment, you can see it from expanded "Patch Set." "Comments" column will show how many comments are in each file. If you click a file name that has comments, the new page will show a diff page with the reviewer's name and comments. Click "Reply" and write your response. It will be saved as a draft if you click "Save." Now, go back to the page that shows a list of patch sets and click "Review," and then, click "Publish comments."

If your code is not ready for review, click "Work in Progress" to indicate that a reviewer does not need to review it for now. Note that the button is invisible until you login the site.

Drafts

A change can be submitted as a draft if, for example, it's not ready for merging, or even general code review, but you would like to share it selectively to get early comments. If you upload a change as a draft, by default, no one else can see it. You must explicitly add each person you would like to share it with as a reviewer. Reviewers you add can leave comments, but cannot vote at this stage. You can continue to upload new patchsets to the change as it evolves, and once it is ready for general review, you can click the "Publish" button. It will then become a normal change in Gerrit that everyone can see, including the earlier reviews from the draft stage. This is a one way transition; once a draft is published, it can't be made a draft again.

A draft change is uploaded by adding the "-D" option. Simply make changes, commit them, and submit them as a draft:

git commit -a
git review -D

#!wiki caution
'''Note:'''

Earlier versions (prior to 1.16) of git-review may also have the "-D" option, but the git ref that Gerrit uses to indicate a change should be a draft was changed; so if using "-D" results in an error, you may need to upgrade to latest.

長寿のトピックブランチ

あなたがより大きなプロジェクトで作業をしている場合、あなたは暫くの 間あなたのトピックブランチで作業をしたいかも知れません。この場合、 あなたは

開発中にあなたの変更をしばしばチェックインし、コードレビューの為に サブミットする前にあなたの変更をマスターリポジトリの最新状態をベー スにする(rebase)必要があるかも知れません。

あなたが作業を開始してからマスターリポジトリが変更された場合、あな たはあなたの変更を最新の状態にリベースすべきです。そして、あなたが 細かなコミットを多数行った場合、あなたはそれらを１まとめにして、細 かなコミットが公式リポジトリに現れないようにすべきです。

覚えておいて下さい：各コミットは Gerrit の中で１つの変更になり、個 別に了承される必要があります。あなたがプロジェクトに対して１つの 「変更」を行った場合、表向きはあなたの多数の「チェックポイント」コ ミットは１つのコミットにまとめられます。以下がそれら両方を行う方法 です。

git checkout master
git pull origin master
git checkout TOPIC-BRANCH
git rebase -i master

エディタを使用して、公式の履歴に現れるべきではない任意のコミットを １まとめにします。もしあなたがたった１つの変更を Gerrit にサブミッ トしたい場合、あなたはこのプロセスの最後に１つの「pick」行を書くだ けとなります。完了後、あなたはエディタで公式のコミットメッセージを 用意する事が出来るようになります。あなたは pick したコミットからコ ミットメッセージを書き始める事が出来、そしてメッセージには Change-Id 行が含まれるべきです。編集時にメッセージに Change-Id 行 を残すことを忘れないで下さい。

一度、あなたのブランチ中のコミット履歴が正しいようであれば、「git review」を実行してあなたの変更を Gerrit にサブミットして下さい。

変更の更新

コードレビュープロセスが追加の変更を提案する場合、それらの変更を行っ て既存のコミットを修正(ammend)して下さい。コミットメッセージ中の既 存の Change-Id: フッターをそのまま残すと、Gerrit はそれが既存の変 更に対する更新パッチとして扱います。

git commit -a --amend
git review