1. 株式会社 ユニキャスト
ユニキャストにおける
gitの運用方針について
ver 0.9

2. 背景
現在、弊社では各案件に対し、個人で対応に当たるケースが多いです。
今後、チームで開発を行う場合に、スムーズに開発を行うための準備の一環として
本資料を作成しました。
git-flowというgit運用をベースとして、運用方針のガイドラインを作成します。
※本方針は、git-flowを強く意識して(ほぼ忠実に)作られています。
弊社に合った方法をみなで模索していきましょう！(順次アップデートします。)
※ 社内外問わず、ご意見、ご感想ある場合には
箕輪(@y_minowa)までご連絡ください！

3. git-flowとは
A successful Git branching model » nvie.com
http://nvie.com/posts/a-successful-git-
branching-model/
gitの運用ガイドラインの一つです。
git-flowをベースにして運用方針をきめ
ることにより、
・開発側としては、機能の追加に
集中できる。
・マネジメント側としては、メンバーが
複数人になったとしても安心！
といった利点があります。
（今までは、masterブランチにコミッ
トをひたすら追加していき、見通しが
悪くなっていました。）

4. git-flowの概要①
1. 基本となるブランチ
(1) masterブランチ
masterブランチは、お客様に向けてのリリース可能なソフトウェア
である必要があります。
イテレーション期間が終わった、または一定の機能がdevelopブランチに
マージされた時に、developブランチの内容をmasterブランチに
マージします。
masterブランチへのコミットは、タグ付けされて、バージョンを表します。
(2) developブランチ
developブランチは、開発者にとって大切なブランチで、各トピックブランチの
起点となり、また、マージ先になります。
基本的に、リリースするversion毎に、masterブランチに
developブランチをマージする。
開発者はdevelopブランチを起点にしてトピックブランチを
作成し、開発が完了したらdevelopブランチにマージする。

5. git-flowの概要②
1. サポートブランチ
(1) featureブランチ(トピックブランチ)
実際に機能を開発するためのブランチで、developブランチより作成されま
す。また、機能の開発が完了したら、developブランチにマージし、
ブランチは削除します。
developブランチにマージする際に注意することがあります。
それは、fast-forwardマージを行わないことです。
これにより、developブランチには、実装が完了したトピックブランチの
マージコミットのみが作成されることとなり、見通しが良くなります。
例: 検索機能を追加する
git checkout -b search develop // searchブランチを作成
...コミット追加
例: 検索機能の開発が完了したので、developブランジにマージする
git checkout develop // developブランチに戻る
git merge --no-ff search // non-fast-forwardマージ
git branch -d search // マージしたブランチの削除
git push origin develop // origin(リモートリポジトリ)へ変更をpush

6. git-flowの概要③
(2) releaseブランチ
releaseブランチは、新しくリリースするための準備をするブランチです。
(細かなバクフィクスや、メタデータの変更)
developブランチより作成し、releaseブランチで作成した内容は、develop、masterブランチにマージします。
また、命名規則は release-x.y のように、どのリリースバージョンに向けてか分かるようにします。
例: ver.1.2のリリースに向けて準備する
git checkout -b release-1.2 develop // developブランチより、releaseブランチの作成
... commit (ご指摘頂いた、細かなバクフィクス等)
(commitして、リリースの準備ができた段階で)
git checkout master // masterブランチへ復帰
git merge --no-ff release-1.2 // no-ffマージ(masterブランチも整然としておくこと！)
git tag -a 1.2 // この時点を1.2のリリースとして、タグを打つ
git checkout develop // 細かな修正事項を含むので、developブランチにも戻す
git merge --no-ff release-1.2

7. git-flowの概要④
(3) hotfixブランチ
hotfixブランチは、リリース後の不測の事態や、重度のバグ対策に用いられるブランチです。
masterブランチより作成し(=リリースしたソフトウェアに対する修正)、
hotfixブランチで対応した内容は、develop、masterブランチにマージします。
また、命名規則は hotfix-x.y のように、どのリリースバージョンに向けてか分かるようにします。
例: ver.1.2において、致命的なバグが見つかった！
git checkout -b hotfix-1.2.1 master // masterブランチより、ブランチの作成(ver1.2.1に向けて！)
... commit (修正対応)
(commitして、リリースの準備ができた段階で)
git checkout master // masterブランチへ復帰
git merge --no-ff hotfix-1.2.1 // no-ffマージ
git tag -a 1.2.1 // この時点を1.2.1のリリースとしタグを打つ
git checkout develop // developブランチにも反映
git merge --no-ff release-1.2

8. FAQ
Q1. トピックブランチに対するバグフィクスはどのブランチでやればいいの？
Q2. ステージング環境と本番環境で設定違うんだけど、どうすればいいの？
ステージ用のブランチ切るの？
現時点での解として、featureブランチと同じ要領でfixブランチを作って対策
するのが良いと思います。
例: バグxxxを対策する
git checkout -b fix-xxx develop // fix-xxxを作成(developブランチより)
git commit ....
(略)
git checkout develop
git merge --no-ff fix-xxx
git branch -d fix-xxx
git push origin develop
一時期、環境ごとに(master,staging)ブランチを作って、設定を分けて破綻しかけた時期がありました。
今となっては、環境依存のファイルは、.gitignoreに含めるべきですよね。
github/gitignore · GitHub
https://github.com/github/gitignore
また、環境ごとのデプロイ設定情報の切り分けをするためには、例えばcapistranoの場合だと、
capistrano-extという便利なgemがあります。
neerajkumar/capistrano-ext · GitHub
https://github.com/neerajkumar/capistrano-ext

9. FAQ(続き)
Q3. Redmineとの紐付けはどうしていくの？
Q4. Gitの使い方とかわからないけど？(fast-forwardって何？)
弊社では、プロジェクト管理システムとしてRedmineを使っています。
基本的に、gitのコミットは、チケットに紐付けるようにしましょう！
例: 認証機能を追加する
(1) Redmineのチケットに登録する。(種別と見積り時間をしっかり入力するクセをつけます！)
(2) チケット機能を開発するために、トピックブランチを作成。
(3) コミットメッセージは、以下のように工夫しましょう。
git commit -m refs #1120, @2h, 認証コントローラ部分を実装
※ @3.5h(=作業時間), #1120(=チケット番号)を記述することにより、Redmineと連携できます。
=> 「この機能の開発には、あのコミットが関係しているんだな！」の把握が便利！
チケットの親子関係とかありますが、最初の時点では、上述の程度で良いと思います。
資料では、以下が学びやすいと思います。
サルでもわかるGit入門 ∼バージョン管理を使いこなそう∼ ¦ どこでもプロジェクト管理バックログ
http://www.backlog.jp/git-guide/
書籍では、以下をおすすめします。
入門git｜Ohmsha
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9
※表示のおさるさんや女子高生のコンテンツを毛嫌いすると損をすることがたまにあります。

10. 提供
http://www.unicast.ne.jp/