プログラマの思索

GitコードレビューツールGerritの情報をリンクしておく。
以下ラフなメモ書き。

【元ネタ】
Gerritを約1年運用してみて | ちとろぐ

Lhaz開発課 - ちとらソフト開発部

gerrit - Gerrit Code Review - Google Project Hosting

Google製のGit用ソースコードレビューシステム「Gerrit」 - MOONGIFT|オープンソース・ソフトウェア紹介を軸としたITエンジニア、Webデザイナー向けブログ

Twiwt:Blog / jugyo : 僕が Gerrit について理解している数少ないこと

Jenkins Gerrit Trigger Plugin の使い方 | Aiming 開発者ブログ

GerritはGitだけのためのコードレビューツール。
上記の記事の感想で面白い点は、addやcommitのような基本的コマンドだけでなく、rebaseやmergeなどのGitコマンドの使い方が分かったという点。

トピックブランチ上で修正したパッチがコードレビューされてOKの後、trunkへマージされる時に、どのような方法でマージすべきなのか？
コンフリクトが起きた場合、rebaseを使えば過去の修正履歴も保持したままturnkの最新の修正履歴も反映させてマージしてくれる。
Mercurialでもrebaseはあるし、mqやtransplantのようにMercurial特有のコマンドもある。
この辺りの機能は、複数のブランチを保守しながら開発していく並行開発で必要。
特に、基本的な仕様は似通っているが細部の仕様が微妙に違う製品ファミリーの開発、組込製品の派生開発で重要なテクニックになるだろうと思う。

Gerritで興味深いのは、コードレビューのステータスとして、+1 Verified，+2 Looks good to me, approvedがあること。
単にパッチが動くものだけではなく、ソースとして綺麗だよ、と言うレベルまでレビューできるか？

Jenkins＋Git＋Gerritを連携させた仕組みも興味深い。
チケット駆動開発とJenkinsの連携: プログラマの思索にも書いたけれども、turnkへトピックブランチで作ったパッチをマージさせたら、自動テスト・ビルド・デプロイまでの一連の流れを自動化した方が楽だ。
これがビルドパイプラインの考え方であり、継続的デリバリーの概念へつながっていく。

色々考えてみる。