GitFlowについて、軽くまとめる？

#まえがき
利用・勉強していての個人的な感想を書いている内容になります。
間違い・不足がある可能性がありますので、何かありましたら「コメント」や「編集リクエスト」頂けると助かります。

GitFlowとは？

Gitを使う上での、ブランチの使い方（ルール・方針）というのでしょうか。
GitFlowというルールを決めて、それに沿うように手伝ってくれる便利なツール（プラグイン）とでも言えば良いでしょうか。

イメージ

GitFlowの有名な図をちょっと拝借

参考：https://leanpub.com/site_images/git-flow/git-flow-nvie.png

ブランチの種類

master

リリースできる状態をキープするブランチ。
ここに開発者が修正ソースを適用（push）する事はありません。
常にクリーンな状態がキープされています。

develop

現在開発中の最新状態となっているブランチ。
ここも開発者が直接修正（push）する事はありませんが、各開発者が修正完了したソースがここに集まります。

feature

各開発者が自由に作成し、修正をするブランチ。
基本はローカルにのみ存在し、リモートには存在するのは、developにマージ待ちのものか、保留になったものといったところでしょうか。

ブランチ名は、修正内容がわかりやすい内容にするか、Redmine等でチケット駆動開発している場合はチケット番号にしておくと便利です。

release

リリースする際に作成されるブランチ。
developから作成され、リリースに関する修正があれば、このブランチで実施します。

releaseブランチ以降のブランチ名は、リリース番号（V1.0.0等）にすると便利です。

hotfix

リリース後に見つかったバグなど、developの開発が先に進んでしまっているなどして、
次のリリースを待てない！となった場合に利用されます。

開発の手順（develop→feature→develop）

1. 各開発者が自分のfeatureを作って、修正

   git flow feature start {ブランチ名}
   

2. 修正が完了したら、リモートにpush（publish）

   git flow feature publish {ブランチ名}
   

3. マージリクエスト（プルリクエスト）にて、developにマージ（コードレビューする）
   GitLabやGitHubにて、developにマージします。
   ※ここでの手順は省略します。
   個人開発など、コードレビューを省略する場合は、featureのfinishでしょうか

   git flow feature finish {ブランチ名}
   

リリースの手順（develop→release→master）

1. リリース準備に、releaseブランチの作成

   git flow release start {ブランチ名}
   

2. リリース用の修正があれば修正してコミットし、push(publish)

   git flow release publish {ブランチ名}
   

3. 作業が完了したら、リリースブランチの終了＆マージ

   git flow release finish {ブランチ名}
   

この時に、タグが作成されます。

バグ対応の手順（master→hotfix→master/develop）

1. バグフィックス用にhotfixブランチの作成

   git flow hotfix start {ブランチ名}
   

2. バグ修正してコミットし、push(publish)

   git flow hotfix publish {ブランチ名}
   

3. 修正完了したので、hotfixブランチをマージ

   git flow hotfix finish {ブランチ名}
   

※masterとdevelopの両方にマージされます

#まとめ
色々なブランチが登場してきますが、基本は、

1. 開始（start）
2. 修正
3. 公開・共有（publish）
4. 終了（finish)
   と言う感じですね。