Edited at

Git利用時のフローはどれを使うか

More than 3 years have passed since last update.


Git, GitHub, GitLabそれぞれの特徴

*注意事項:当初は、GitHub Flowを入れる想定で調べていましたので少しGitHub Flowとの比較の観点が強いです


Git Flow



  • 使用するブランチ


    • master マイルストーン用のブランチ

    • develop 開発用のブランチ

    • feature 機能追加用

    • (hot)fix 不具合修正用

    • release リリース準備用




  • Git Flowの良さ




  • Git Flowのまずさ


    • ほとんどのツールがデフォルトでmasterブランチを表示するが、わざわざdevelopブランチに切り替えないといけない

    • hotfixブランチをdevelop, master共に反映しなければならない点が面倒

    • 参考:【翻訳】GitLab flowから学ぶワークフローの実践内、Git-flowとその問題点

    • 参考:GitLab Flow




  • GitHub Flowと比べると


    • ブランチ間の移動や、複数ブランチへのマージの発生量が多くなりがち

    • 一定期間終了した後に全ブランチの遷移などを俯瞰すると開発の様子がわかりやすくて良いかもしれない

    • 一方で、開発中は開発者の負担が少し多くなるかもしれない




GitHub Flow



  • 使用するブランチ


    • master 開発用のブランチ、masterはテスト済で本番環境へのデプロイ可能

    • topic 機能追加用/不具合修正用のブランチ




  • Git Flow、GitLab Flowと比べた特徴的な点




GitLab Flow



  • 使用するブランチ


    • master 開発用のブランチ

    • topic 機能追加用/不具合修正用のブランチ

    • production テスト済で本番環境へのデプロイ可能なブランチ(自動テストの対象にしたりする)

    • release リリース準備用




  • GitLab Flowでのfix(不具合修正)の扱い


    1. masterから修正用のトピックブランチを切る

    2. 修正内容を実装後、Merge Request(Pull Request)

    3. masterにマージ(トピックブランチは削除)

    4. cherry-pickでfix部分のみをreleaseへ反映




どれを使うか


  • リリースをどう考えるか(例:"リリース"というイベントはあるか, あるならGitHubは使いづらいか)

  • 規模の大きなチームか(例:大きい場合、GitHubではない方が開発とテストを分けやすい)

  • チームメンバの好みはなにか


    • 使う人がどう思うか、が一番大事、な気がします




例:あるモバイル向けアプリ開発プロジェクトの場合


  • 自動テストの実施は今のところない、テストはmaster上のものに対して実施(=Production不要)

  • 実装後、レビュー済のものをマージ、定期的に実機でのテスト、実機でのテスト済のものをリリース

  • GitHub Flow + Releaseブランチ or GitLab Flow - Productionブランチ、というのが現状のフローを前提にすると親和性が高い


その他参考になりそうな情報

Github-flowを分かりやすく図解してみた