ブランチ戦略とは
- Gitの特徴である分散とブランチを活用して、スムーズな並行開発と壊れにくリリースビルドを実現するための手法
よく目にする戦略
- Git-Flow
- GitHub-Flow
- GitLab-Flow
よく目にする戦略
・・・は複雑！！
Gitによるソース管理の現実
- SIerに集まってくる技術者はGitに不慣れな場合も多い
- 意味のある名前付けにはセンスが必要
- 製造と保守が分かれていてブランチの意味合いが混じることが少ない
現実的なブランチ戦略(1/3)
- 最小限のブランチ種類
- 機械的なブランチ名
- チケットやタスク番号と確実に連動させたい
現実的なブランチ戦略(2/3)
- main：リリース対象のブランチ
本番環境の最新と一致
管理者しか触らない - dev：開発完了した機能をすべて含む最新仕様の状態
デプロイして実際に触れるようにしておくべき
管理者しか触らない - 開発ブランチ：各開発者がdevから派生して作成するブランチ
現実的なブランチ戦略(3/3)
- 各開発者は開発を終えたらdevに対してマージを依頼
出来ればスクオッシュしておきたい - 管理者は差分を確認しながらマージを実施
- 可能なら、ここでテストを実行（NGになったらマージ依頼を差し戻し）
- devにプッシュ、各開発者に周知
- 各開発者はdevの最新状態をローカルに反映
mainブランチをいつリリースするか
- リリース計画に従って実施
- devブランチをマージ
- リリースノートがあるなら、編集
- リリース実施
- devブランチにリリースノートの内容を反映
- リリースタグを切る ←★重要★
開発ブランチの名付け
<派生元ブランチ名>-<担当者名>-<チケットorタスク番号>
<派生元ブランチ名>-<チケットorタスク番号>-<担当者名>
- 管理者としては後者がありがたい。番号順に並んだほうが探しやすいので
- 作業に番号が振られている前提
ITSかせめてタスク管理表を作成する必要あり
最後に
- いろんな戦略がありますが、シンプルなのがやっぱり強いです
- 要所でタグを切っておくのは非常に大事です