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 ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う
masterブランチ †
- 現在の製品のメインブランチ
- 常にデプロイ可能な状態
featureブランチ †
- 新しい作業を開始するときに、わかりやすい名前のブランチをmasterから分岐
- ローカルでコミットして、同じ名前でリモートにもpush
- フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成
- 他のメンバーがレビューして確認したら、masterへマージする
- masterにマージしたらデプロイできる
その他 †
アピール †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
