branch_strategy.md

これはなにか

Gitブランチ戦略のメモです。

基本戦略

ファーストバージョンリリースまで

• masterブランチに対して直接コミットを行う。
  • ここで言うファーストバージョンとは、アプリ全体が一通り揃った段階の状態を指す。世間にリリースしているかどうかは不問。
    • SIerの用語で言えば、結合テストが終わり総合テストに入る段階ぐらい。
• masterブランチ自身がデプロイ可能でなくても、テストが通らなくてもこの段階ではあまり気にしない。それよりも日々の作業をコミットしてpushすることのほうが大事。
  • とは言っても、「Javaならコンパイルできること」「テストが失敗したまま帰宅しないこと」など最低限のルールはチーム内で定めておく。
• しかしながら、適切なタイミングでmasterブランチがデプロイ可能である状態・テストが通っている状態を作り出しておくこと。
  • 個人的には、毎週水曜日の正午の段階では確実にmasterブランチがデプロイ可能である状態・テストが通っている状態としたい。
  • 週末や定時後だと翌週や翌日に持ち越されて状態が曖昧なままになるため。週の真ん中ぐらいがよいかなと思っている。
  • イテレーション会議や進捗会議などがある場合は、そこでデモできる状態にする。
• 個人がブランチを作成したり作成したブランチをpushすることを咎めるものではない。

ファーストバージョンリリース後

• masterブランチに対して直接コミットをすることは止め、masterブランチは常にデプロイ可能である状態、テストが通っている状態とする。
• 何らかの修正が必要な場合は、Issueを作成しブランチを作成してPull Request経由でプログラムを修正を行う。
• ブランチ名は「適切な英語名」としたいところであるが、英語が苦手で意図が伝わりづらい名前をつけられるぐらいならfix_<Issue番号>としたほうがよいと思う。