GitFlow vs GithubFlow

# GitFlowの説明
## GitFlowのグラフ
![git-model@2x.png](https://qiita-image-store.s3.amazonaws.com/0/185389/049d920a-6f1a-0eb6-68bd-eac646c84b69.png "git-model@2x.png")
## GitFlowにあるブランチの説明
* masterブランチ、developブランチがメイン
* featureブランチ、releaseブランチ、hotfixブランチが補助
* masterブランチは常にリリースできる状態
* developブランチから、featureブランチを切って開発を進める
* featureブランチは機能追加用(通常の開発用)
* releaseブランチはdevelopブランチからブランチを切ってリリース直前用（例：受入テスト、総合テストのため利用）
* hotfixブランチはリリース後の緊急対応用

## GitFlowの流れ
### フェーズ1:開発フェーズ
 1.developブランチからfeatureブランチを切って、開発
 2.他の人が開発したら自分のfeatureブランチにマージ
 3.開発が終わったらfeatureブランチをdevelopにマージして、featureブランチを削除
 
 1～3を繰り返して開発を進める

### フェーズ2: リリース前フェーズ(リリース準備作業)
 4.開発が終了したらdevelopブランチからreleaseブランチを切ってリリース準備
 5.releaseブランチでリリース前の作業を行う、releaseブランチの変更が発生場合6に行く、変更がない場合に7いく
   releaseブランチの変更が発生場合
 
  * テスト実施で不具合が出る
  * 仕様変更
  * 他の場合

6.releaseブランチを変更する
※　変更が大きいの場合：
　6.1 releaseブランチから新ブランチを切って、開発を行います。
　6.2 新ブランチで開発が完了したら、releaseブランチにマージして対象ブランチを削除。
※ 小さい変更の場合releaseブランチに直接開発すれば構いません。
 
 5～6を繰り返してreleaseブランチはコードフィックスまで進める

7.releaseブランチの編集完了後はdevelopブランチとmasterブランチにマージして、releaseブランチを削除

### フェーズ3: リリース
8.リリース(masterブランチのデプロイ)
9.リリースタグ作成

* タグ作成方法
 * Jenkinsで自動作成
 * 手動で


### フェーズ4: リリース後
10.リリース後、バグが発生した場合にはmasterブランチからhotfixブランチを切って対応
11.バグ対応が完了したらdevelopブランチとmasterブランチにマージして、hotfixブランチを削除

### 注意事項
* 作業を行うのはfeatureブランチ/releaseブランチ/hotfixブランチ上で
* developブランチ/masterブランチでは作業は行わない　 

### 目的
* チームの中にGithubのworkflowを統一する。
* 長い時間開発した後、リリースを行うようなチームに向いている

### メリット・デメリット
#### メリット

* ブランチ運用ミスを軽減できる
	* hotfix（不具合対応）とfeature（機能開発）が明確に区別できる
	* ブランチの役割は明確設定するので、マージ先のブランチを間違える等のオペレーションミスを軽減できる

* リリースタグ作成、マージ済みブランチの削除の手順があるので、githubは綺麗にみえる

#### デメリット
* 複雑
* 毎日デプロイを行うようなチームには向いていません。

# Github-Flowの説明
## Github-Flowのグラフ
![github_flow.png](https://qiita-image-store.s3.amazonaws.com/0/185389/db1699b1-2c34-87db-31ed-d87c83c10025.png "github_flow.png")

## Github-flowの流れ
1.masterブランチから説明的な名前を付けたブランチを切って、開発
2.開発が終わったら、プルリクをオープンする
3.チーム内でコードレビュー、コメントしていただき、修正してpushする
4.レビューの修正が終わったら、対象ブランチを環境(開発、受入、本番)にデプロイしてみて問題がないかを確認する

 * 問題がなければ5番に行く
 * 問題がある場合
 
 4.1 ロールバック：masterブランチをデプロイする
 4.2 問題を対応して3番に戻ります。
 
5.masterブランチにマージする。

## 注意事項
* masterブランチは常にデプロイ可能状態です。

### 目的
* チームの中にGithubのworkflowを統一する。
* 毎日リリースを行うようなチームには向いている

### メリット・デメリット
#### メリット

* 簡単に理解できる

#### デメリット
* 環境にどのブランチをデプロイしているの確認コースがかかる
* hotfix（不具合対応）とfeature（機能開発）が区別しないので、ブランチ運用ミスを発生する可能性が高い。
* リリースタグ切る、マージ済みブランチを削除の手順はまだありません。

# まとめ

* gitflowとgithubflowの比較
	* 同様 : チームの中にGithubのworkflowを統一する
	* 差異 : 下記のテーブルにて確認ください

| | gitflow | githubflow |
|---|-----  |------------|
|目的|・長い時間開発した後、リリースを行うようなチームに向いている|・毎日リリースを行うようなチームには向いている|
|メリット|・ブランチ運用ミスを軽減できる<br>・リリースタグ作成、マージ済みブランチの削除の手順があるので、githubは綺麗にみえる|・簡単に理解できる|
|デメリット|・複雑<br>・毎日デプロイを行うようなチームには向いていません|・環境にどのブランチをデプロイしているの確認コースがかかる<br>・ブランチ運用ミスを発生する可能性が高い<br>・リリースタグ切る、マージ済みブランチを削除の手順はまだありません|

# 参照リンク
* [git flowとgithub flowとは？その違いは？](http://qiita.com/mint__/items/bfc58589b5b1e0a1856a#git-flow%E3%81%A8github-flow%E3%81%A8%E3%81%AF%E3%81%9D%E3%81%AE%E9%81%95%E3%81%84%E3%81%AF)
* [GitHub Flow](http://scottchacon.com/2011/08/31/github-flow.html)
* [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/)
* [git-flow](https://danielkummer.github.io/git-flow-cheatsheet/)