git flow rule

git flow rule.md

参考URL

• git-flow http://nvie.com/posts/a-successful-git-branching-model/
• commitメッセージ http://qiita.com/itosho/items/9565c6ad2ffc24c09364 これの簡略化バージョンつかってみましょうか
• レビューについて http://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%92%E3%82%AB%E3%83%B3%E6%97%8F_(%E3%83%8D%E3%83%83%E3%83%88%E7%94%A8%E8%AA%9E)

rule

• git flow コマンド (source treeのgit flowボタン)は基本使わない。
• 自由度が低いので。。。
• feature は develop から作成
• feature は develop に対してpull-req > review > merge > delete
• 子feature は 親feature から作成
• 子feature は 親feature に対してpull-req > review > merge > delete
• feature が長生きする場合はdevelopから適度にマージするのを忘れずに
• release は 必要であれば作成
• release は 機能実装完了後作成 > テスト待ちの状態
• release に対する修正は release から featureブランチを作成 > releaseにpull-req
• release が長生きする場合はrelease から develop に適度にマージ
• release でテスト完了後 master と developに手動でマージ > master でリリース作業を行いタグを打つ > releaseブランチをdelete
• hotfix は master から作成
• 修正が完了したらmasterとdevelopにマージしてリリース > delete

命名規則

• feature/nnnn_xxx(nnnnはJIRAチケット番号推奨)
• release/release_vX.X.X
• (hotfix_xxx developとmasterの差があるとき)

pull-req

• つくったら、開発用チャットワーク にpull-reqのURLを貼る
• 数人が見ればおk
• マージはfeatureブランチ作った人はやらない レビュアーがやる
• automatically merged でないpull-reqは作り直し

その他

• 自動生成系はそれだけfeaatureブランチつくる (できれば)
• EF関連/.metaなど
• 長生きするfeature → 1週間に1回くらいはdevelopからマージしましょう
• デザイナーと企画はdesign用feature or 関係ある親featureブランチ
• 2人以上でひとつの機能を作る場合は親featureをつくってそこから子featureをつくって、子featureを親にpull-req
• EM-launcherにチケット名
• mergeするときにffしない(rebaseしない)
• ローカルのリモートブランチはfetchすれば削除できるよ