git-flow 図解

## git-flow is :thinking:
- Vincent Driessen さんがブログで公開した  **A successful Git branching model** のこと
    - 元記事：[A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)
    - 日本語訳： [A successful Git branching model を翻訳しました](http://keijinsonyaban.blogspot.com/2010/10/a-successful-git-branching-model.html)
- または、**A successful Git branching model**を補助するためのツールの名称
    - [git-flow cheatsheet](https://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html)
- ブランチの運用ルール、命名規則を設けることで、<br>複数人開発時も各ブランチをわかりやすい状態に保つことができるようになる
- もっとシンプルなルールにしたものに、`GitHubFlow`がある
    - 元記事：[GitHub Flow](http://scottchacon.com/2011/08/31/github-flow.html)
    - 日本語訳：[github-flow.ja.md](https://gist.github.com/Gab-km/3705015)
    - 小さなサイクルでデプロイするケース向き

この記事では、**A successful Git branching model**に登場するブランチについて説明していきます。

※**利用する5種類のブランチ**の前に、**運用手順**に目を通したほうがイメージが付きやすいかもしれませんm(_ _)m
※**個人的な意見**には、先頭に:thinking: を入れています。


## 利用する5種類のブランチ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/c9840b24-f8b4-220a-e18d-3a8ea92a97ad.png)

git-flowは2種類の**メインブランチ** ( `master` , `develop` ) と3種類の**サポートブランチ** ( `feature` , `release` , `hotfix` )を利用します。

### メインブランチ
開発の**軸**となるブランチ

#### master ブランチ
- 分岐元：なし
- マージ先：なし
- ブランチ名の例：`master`
- 特徴
    - 本番にリリースできる状態を保つ
    - 直接コミットは行わない
    - release 、hotfix からマージを行い、タグを作成する
        -  :thinking: タグ名は `release/vX.X.X` がよいと思う

#### develop ブランチ
- 分岐元：`master`
- マージ先：なし
- ブランチ名の例：`develop`
- 特徴
    - 開発中の最新状態を反映する
    - 基本、直接コミットは行わない
    - feature , hotfix からマージを行う

### サポートブランチ
メインブランチでの開発を**補助**するためのブランチ

#### feature ブランチ
- 分岐元：`develop`
- マージ先：`develop`
- ブランチ名の例：他のブランチ名のルールと重複しないもの
    - :thinking: シンプルに `feature/*` か、 <br>　　`feature/YYYYMM_{案件名}/*` とかするのがいいと思う
    - :thinking: Githubなどを用いてissueと合わせて運用するのであれば、<br>　　`feature/{issue番号}__*` とか、`feature/YYYYMM_{案件名}/{issue番号}__*` としたほうがいいと思う
- 特徴
    - 新機能の開発を行うのに用いる
    - develop へマージする際は、Gitの `-no-ff` オプションも活用する<br>(一連のコミットを1コミットにまとめる機能)
    - リモートへPushせず、ローカルでのみ利用する
        - :thinking: Pull Requestも活用するのであれば、Pushしてもいいと思う

#### release ブランチ
- 分岐元：`develop`
- マージ先：`master` と `develop`
- ブランチ名の例：`release-*`
    - :thinking: `release/vX.X.X` がいいと思う
- 特徴
    - リリースの準備作業を行うのに用いる
        - バージョンの変更
        - **小さな**バグフィックス
    - master へマージ後、 develop へマージする<br>完了後、release を削除する

#### hotfixブランチ
- 分岐元：`master`
- マージ先：`master` と `develop`
- ブランチ名の例：`hotfix-*`
    - :thinking: `hotfix/*` がいいと思う
    - :thinking: Githubなどを用いてissueと合わせて運用するのであれば、<br>　　`hotfix/{issue番号}__*` としたほうがいいと思う
- 特徴
    - 緊急のバグフィックスを行うのに利用する
    - master へマージ後、develop へマージする<br>完了後、hotfix を削除する
        - 利用用途としては release に似ているが、<br>develop を経由せずに master へマージできるため<br>進行中の開発が影響を受けにくい

## 運用手順

### `develop` を作成する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/b46f4eb3-d18e-40ff-de42-81b4d8f8c7f6.png)

1. `master` から `develop` を作成する<br>リポジトリ作成直後のみ実施する

### 機能開発の準備を行う
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/31bf6489-7428-f8aa-6ca5-c8f7a6453cc1.png)

1. `develop` から `feature` を作成する<br>`feature` は開発する機能毎に作成する

### 機能開発を行う
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/9d4402f9-645e-4b1b-cdde-9e3650ef6b89.png)

1. `feature` で機能を開発する<br>ローカルでのみコミットし、pushは行わない<br>:thinking: 後で `feature` を削除するのであれば、Pushしてかまわないと思う<br>:thinking: Pushすれば、`WIP Pull Request`やGithubの`Draft Pull Request`が利用できる

### 開発中の最新状態を `feature` に取り込む
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/27c46726-6df9-ef08-19b2-0fccbf0cea06.png)

1. 任意のタイミングで `develop` を `feature` へマージする<br>マージ時のコンフリクトを避けるため

### 開発済みの機能を `develop` へ取り込む
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/3c66b03f-fb93-0134-32f5-fce408060759.png)

1. `feature` を `develop` へマージする<br>:thinking: Githubなどを利用している場合は、PR(Pull Request)を利用する

### リリース作業の準備を行う
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/61fca4ea-e11f-db82-443b-114410724474.png)

1. リリース準備のため、`develop` から `release` を作成する
1. `release` でバージョンの変更や、小さなバグフィックスを行う

### リリース完了
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/62edf322-3180-d20f-50f1-840557947eab.png)

1. `release` を `master` へマージし、タグを作成する
1. 製品をリリースする
1. `release` を `develop` へマージする
1. `release` を削除する

### 緊急修正対応を行う
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/a75e002d-665e-f3dd-259b-dbf4b3880a94.png)

1. `master` から `hotfix` を作成する
1. `hotfix` でバグフィックスやバージョンの変更を行う

### 緊急修正対応を完了する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/242655/0bf61229-40f6-41cd-f478-fa7801684ed0.png)

1. `hotfix` を `master` へマージし、タグを作成する
1. 製品をリリースする
1. `hotfix` を `develop` へマージする
1. `hotfix` を削除する


## まとめ
オリジナルの概念が発表されたのが、既にかなり前になります。
現在はGithubなどで様々な機能もできていますので、`feature` はPUSHしてしまったほうが、
Draft PR (WIP PR)によるレビューや作業状況の把握のためよいと思います。
また、オリジナルは使い終わったブランチは基本的に削除する方針ですが、
後続の開発の邪魔にならないようにブランチ名のルールを決めていけば、
残しておいてもいいと思います。