GitHub
チーム開発 †
ブランチモデル †
Git-flow †
masterブランチ †
- git-flowでは master ブランチに直接コミットすることはなく、マージを行うだけのブランチになる
- 誤って直接コミットしてしまわないように注意
developブランチ †
- develop ブランチは、開発の中心となるブランチ
- 開発中は develop ブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返すことになる
- master ブランチ同様、直接このブランチにコミットすることはないので注意
- リポジトリを新規作成したときに、master ブランチから develop ブランチを切っておく
featureブランチ †
- feature ブランチは、機能の追加や変更、バグフィックスを行うブランチ
- ひとつの変更に対してひとつの feature ブランチを切ることになるため、開発中で最も使われるブランチになる
- ブランチの名前は、変更の内容がすぐに分かるような名称にする
- develop ブランチから派生させ、作業完了後に再び develop ブランチにマージする。そして、マージ完了後に削除するというのが一連の流れになる。
releaseブランチ †
- release ブランチは、その名の通り製品をリリースするために使うブランチ
- 製品のリリース時には、関連する作業が必要になる場合が多いでしょう。そういった作業は、develop ブランチから release ブランチを切って、そのブランチでリリース作業を行います。
- リリース作業が完了したら、master ブランチと develop ブランチにマージして、master ブランチのマージコミットにリリースタグ（バージョンなど）をうちましょう。その後、release ブランチは削除します。
hotfixブランチ †
製品のリリース時には、時として重大な不具合が見つかる場合があります。みなさんも経験があるのではないでしょうか？
そんなときには、master ブランチから直接 hotfix ブランチを切って緊急の修正を行いましょう。修正完了後に master ブランチと develop ブランチにマージして、リリースタグ（マイナーバージョンなど）をうちます。その後、hotfix ブランチは削除します。派生元が master になるだけで、操作的には release ブランチと同様です。
supportブランチ（オプション） †
- プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要になる
- support ブランチでは、旧バージョンの保守とリリースを行う
- サポートが必要なバージョンの master ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う
アピール †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
