Edited at

GitFlow vs GithubFlow

More than 1 year has passed since last update.


GitFlowの説明


GitFlowのグラフ

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


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

目的
・長い時間開発した後、リリースを行うようなチームに向いている
・毎日リリースを行うようなチームには向いている

メリット
・ブランチ運用ミスを軽減できる
・リリースタグ作成、マージ済みブランチの削除の手順があるので、githubは綺麗にみえる
・簡単に理解できる

デメリット
・複雑
・毎日デプロイを行うようなチームには向いていません
・環境にどのブランチをデプロイしているの確認コースがかかる
・ブランチ運用ミスを発生する可能性が高い
・リリースタグ切る、マージ済みブランチを削除の手順はまだありません


参照リンク