株式会社 ユニキャスト

ユニキャストにおけるgitの運用方針について

ver 0.9

背景現在、弊社では各案件に対し、個人で対応に当たるケースが多いです。今後、チームで開発を行う場合に、スムーズに開発を行うための準備の一環として本資料を作成しました。

git-flowというgit運用をベースとして、運用方針のガイドラインを作成します。

※本方針は、git-flowを強く意識して(ほぼ忠実に)作られています。　弊社に合った方法をみなで模索していきましょう！(順次アップデートします。)

※ 社内外問わず、ご意見、ご感想ある場合には　 箕輪(@y_minowa)までご連絡ください！

git-flowとは

A successful Git branching model » nvie.comhttp://nvie.com/posts/a-successful-git-branching-model/

gitの運用ガイドラインの一つです。

git-flowをベースにして運用方針をきめることにより、

・開発側としては、機能の追加に　集中できる。・マネジメント側としては、メンバーが　複数人になったとしても安心！

といった利点があります。（今までは、masterブランチにコミットをひたすら追加していき、見通しが悪くなっていました。）

git-flowの概要①1. 基本となるブランチ

(1) masterブランチ　masterブランチは、お客様に向けてのリリース可能なソフトウェア　である必要があります。　イテレーション期間が終わった、または一定の機能がdevelopブランチに　　　マージされた時に、developブランチの内容をmasterブランチに　マージします。　masterブランチへのコミットは、タグ付けされて、バージョンを表します。

(2) developブランチ　developブランチは、開発者にとって大切なブランチで、各トピックブランチの　起点となり、また、マージ先になります。

基本的に、リリースするversion毎に、masterブランチにdevelopブランチをマージする。開発者はdevelopブランチを起点にしてトピックブランチを作成し、開発が完了したらdevelopブランチにマージする。

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

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

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

FAQQ1. トピックブランチに対するバグフィクスはどのブランチでやればいいの？

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 · GitHubhttps://github.com/github/gitignore

また、環境ごとのデプロイ設定情報の切り分けをするためには、例えばcapistranoの場合だと、capistrano-extという便利なgemがあります。neerajkumar/capistrano-ext · GitHubhttps://github.com/neerajkumar/capistrano-ext

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｜Ohmshahttp://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9

※表示のおさるさんや女子高生のコンテンツを毛嫌いすると損をすることがたまにあります。

提供

http://www.unicast.ne.jp/