Help us understand the problem. What is going on with this article?

GitFlow vs GithubFlow

More than 3 years have 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は綺麗にみえる
・簡単に理解できる
デメリット ・複雑
・毎日デプロイを行うようなチームには向いていません
・環境にどのブランチをデプロイしているの確認コースがかかる
・ブランチ運用ミスを発生する可能性が高い
・リリースタグ切る、マージ済みブランチを削除の手順はまだありません

参照リンク

linksports
「スポーツをしている人を幸せにする」ことをコンセプトに、スポーツ関連サービスの企画・開発を行っているスタートアップです。
https://linksports.co.jp/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away