ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。
前提
まず始めに、現在のプロジェクトの状況は下記のようになっています。
- 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる
- メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態
- サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあり、作業途中でサポートコミッタからメインコミッタに作業を引き継ぐ場合もある
git-flow によるブランチ管理
git の運用についてググっていると、「git-flow」と言う単語をぽつぽつ目にしました。git-flow とは「ブランチモデル（ブランチの切り方）」を表しているそうです。これに関しては、Git flowの活用事例 によくまとまっている図が掲載されていました。
2 系統ブランチと命名規則
Git flow の活用事例（17/63）
上記を参考に、自分のプロジェクトでのブランチの運用指針を記載します。基本的な指針として、開発時はメインブランチを develop とします。何らかの機能を追加・修正する際には develop ブランチから派生ブランチを作成し、作成したブランチ上で作業を行います。develop ブランチ上では、決して作業を進めてはいけません。
- サポートコミッタは、開発作業としてチケット*2を割り当てられたら、まず feature/
と言う形（ は修正する機能を表す適当な名前）で develop ブランチから派生ブランチを作成します。
git checkout -b feature/<ticket> develop
複数のチケットを 1 日で終了させるケースも考えられますが、1 日の作業は基本的には 1 つの派生ブランチで行う事とします（名前は適当に考える）。 - サポートコミッタは、1 日の作業の終わりの際には、どんなに不完全であったとしても作業していた派生ブランチをリモートリポジトリへ push します。
git push origin feature/<ticket>
作業が完結しなかった場合は、未実装項目や問題点等を該当チケットのコメント欄、または口頭等で報告して作業を終了します。 - メインコミッタは、リモートリポジトリに push された派生ブランチを取得し、レビュー・修正等を行った後、develop ブランチにマージします。作業が完了した場合は、該当ブランチは削除します。
git checkout develop
git merge feature/<ticket>
git branch -d feature/<ticket>
git push origin :feature/<ticket> - サポートコミッタは、次回の勤務時に前回 push したブランチがリモートリポジトリにまだ残っていた場合は、引き続きそのブランチで作業を行います。
その際、作業の開始時に develop ブランチの内容を比較し、コミットが進んでいた場合は rebase してから作業を再開します。rebase する、と言う部分は保留とします。
git fetch
git checkout develop
git merge origin/develop
git checkout feature/<ticket>
git merge origin/feature/<ticket>git rebase develop
リモートリポジトリから各ブランチの最新の内容を反映した後、develop ブランチを rebase できればいいです。git pull でも良いのですが、変なブランチにマージしてしまいそうなので上記としています（後述）。
その他
現時点で自分が気になっている点について記述していきます。精査している訳ではないので、内容は随時、加筆・修正されていきます。
git merege
git merge に関するメモ - Life like a clown を参照して下さい。
git rebase
git rebase に関するメモ - Life like a clown を参照して下さい。
git add
よくあるのが「git add . ってやったらサイズの大きなゴミファイルがリポジトリに紛れ込んでしまった」と言うものがあります。この運用方針を決めようと思ったのも、これに近い事例が原因でした。一応、.gitignore でいろいろフィルタリングしてるので多くの場合では適当に add しても大丈夫なのですが、漏れがあったりする事もあるので、add する際には必要なファイルのみを新たに追加 (git add) すると言う事を心掛けて下さい。
git pull
git pull の挙動がよく分かってなかったのですが、下記の記事を読んで何となく分かってきました。
上記でも少し触れましたが、複数のブランチを用いて開発を進める場合、現在のローカルブランチの確認を怠ってうっかり「git pull origin feature/<ticket>」とかやったりすると、develop ブランチとかにマージしてしまったりして阿鼻叫喚になりそうな予感がしました。そう言えば、新しいリモートブランチを持ってくる際には、私もよく嵌っていました……
$ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。
$ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら
$ git checkout -b hoge origin/hogeこう。
git pullの詳細な挙動を追ってみる - hokaccha hamalog v3
事故を防ぐ意味でも、いったん git fetch でダウンロードした後、git branch -av 等でブランチ状況を確認しながら、git checkout, git merge, git rebase 等のコマンドを利用して適切にマージ（または、rebase）して下さい。
参考 URL
基本的な内容として、ひとまず以下に目を通してみると良いかと思います。
- Git - Book
- こわくない Git
- Git初心者が絶対に覚えておくべきコマンド - idesaku blog
- http://blog.layer8.sh/ja/2013/04/08/best-git-commands-for-the-lonely-programmer/
その他（随時、更新予定）。
- Git ユーザマニュアル (バージョン 1.5.3 以降用)
- Community Blog - git-flow によるブランチの管理
- Git flowの活用事例
- GitHub Flow (Japanese translation) · GitHub
- Git と GitHub を体験しながら身につける勉強会行ってきた - ぐるぐる～
書籍情報。
