# ブランチ戦略

ブランチ戦略はパターン化された下記パターンから選定する。

- リンク
https://qiita.com/trsn_si/items/cfecbf7dff20c64628ea

### pattern1. git-flow

- 取り入れたさ：中
- masterの直接編集を許可しない
- masterの直前にdevelopブランチを導入し、リリース前のコードを安定化させる
- 無駄ブランチが増えない（developに統合するときに削除）
- ×　開発者が２人の前提だと重厚長大すぎるかも！？

### pattern2. GitHub Flow
- 取り入れたさ：高
- masterからブランチを作成し、コードの改修を行う。
- masterの更新が頻繁に入るが、開発者２人だとちょうどいいかも。

### pattern3. gitworkflows
- 取り入れたさ：低
- ×　開発者が２人の前提だと重厚長大すぎるかも！？

### pattern4. 安定trunkパターン
- 取り入れたさ：低
- 期間を軸にした開発を行わないため、取り入れるメリット薄い。
- アジャイル開発の場合は、成果が見やすくていいかも。

### pattern5. メインラインモデル
- 取り入れたさ：低
- 開発規模はマッチしていそう
- 最新を終えなくなるため個人的に嫌い

### pattern6. Git Lab Flow
- 取り入れたさ：低
- ステージング環境を意識したブランチ戦略
- 小規模の開発には向かないかも。

## まとめ

`GitHub Flow`を採用する。
決めごとは下記の通り。

- masterは常にデプロイできる状態とする
- 作業ブランチはmasterから作業内容がわかるような名前のブランチを作成する
- 統合ブランチは原則設けないが、開発分野の結合が必要な場合のみ、統合ブランチを設け、結合試験を行う。
- masterへのマージ前に、PullRequestを作成し他の開発者からレビューを受ける

###### tags: `検討`