ソフトウェア開発プロジェクトにおけるソースコード管理としてのGitの使い方を模索しています。
経緯
Gitを最初に使い始めようとして、あまりうまくいかなかったことをこの日記に書いています。
ソースコード管理ツールをSubversionからGitへ変更して感じたこと - torutkの日記
このときの運用方法は、trunkを主に使いブランチを活用していないSubversionからの単純移行で、masterブランチ一本槍です。開発者の定常作業においては、リポジトリが2つ（リモートとローカル）になって複雑度倍、pull、commitとpushと使うコマンドが増え、コンフリクトが頻発するけどその対応がさっぱり分からない、という状況で何もうれしいことがない、というGit運用アンチパターンがあれば真っ先に登場しそうなものでした。
続いて、その反省として運用方法を検討しました。
ソースコードのバージョン管理スタイルを見直す - torutkの日記
しかし、"A successful Git branching model"はやはり複雑です。
そこで、GitHub flowをベースにした運用を始めてみました。
チケット駆動と連動したGitの運用（GitHub flowを参考）
Androidアプリケーション開発のプロジェクトが始まり、その構成管理を構築する必要がありました。今回は開発拠点が分散することもあり（ネットワークはつながるので開発サーバーは一元化可能）、Gitを使うことにしました。Androidは初なので、技術課題をクリアするためプロトタイプ開発を先行して進めており、1〜2週間を1つの区切りとするイテレーションを繰り返す開発手順を取り、作業管理にRedmineを使ったチケット駆動開発をしています。
最初の１、２イテレーションを見ていると、開発者各自は自分が担当した技術事項は調査・実装するので詳しくなりますが、自分が担当していない技術事項は知らないといういわゆる蛸壺的な兆候が出てきました。このままではまずいなと思い、ペアプログラミングは地理的に実現できないのでせめてピアレビューを実施したいと考えました。
そこで、RedmineのチケットとGitの運用を次のようにしてみました。
- 実装するには必ずRedmine上でタスクチケットを作成する
- Gitではmasterからトピックブランチを作成しチケット番号にもとづく名前をつける
- 実装はトピックブランチにコミットする
- トピックブランチは共有リポジトリにもpushし、1日1回は反映する
- 実装が完了したら、ローカルのトピックブランチを共有リポジトリにpushする
- チケットのステータスを解決にして、開発チームの誰かにピアレビュー依頼する（チケットの担当者をピアレビューを依頼する人に変更）
- ピアレビューを頼まれた人は、トピックブランチをローカルのmasterにマージして内容を確認する（レビューが重いと大変なので、できる範囲で）
- 確認結果が良好であれば、ローカルのmasterを共有リポジトリにpushし、チケットを完了にする（これにて一件落着）
- 確認結果、問題があれば、チケットのステータスをフィードバックにして差し戻す
いわゆるプルリクエスト的なワークフローをRedmineチケットで泥臭く回しています。
ピアレビューは、リーダーに限定するとリーダーがボトルネックとなって回らないので、誰でもよいことにしています。また、忙しくて今レビュー対応できない、という時は、他の人にレビュー依頼を転送してしまうのもありとしています。
今のところ順調に回っているように思います。
Gitでmasterの変更を通知できるようにしたい
上述の運用では、masterの変更を随時取り入れるということを明文化していなかったので、masterとの乖離がたまに課題になっていました。そこで、masterに変更が入ったら作業中のトピックブランチに変更を取り込むことを追加しようとしています。そこでmasterの変更をどうやって知るか、まずはgitのhookスクリプトからメール通知をしようと調べてみました。
gitでmasterへのpushをhookでメール送信というよくある設定ですが、書籍を含めて調べて出てきた手順は、post-receive.sampleをpost-receiveに名前変えて、最後の行のコメントを解除すればOK、というものばかりでした。しかし、今運用しているGit環境には、その肝心のsampleがありません。
調べを進めると、何と言うことはなくpost-receive.sampleはコメントアウトされた1行だけが実体のスクリプトでした。設定内容は次のWikiに記載しています。
