Baby step - 思考と実験の足跡

日常のちょっとした、気になって試したこと集です。

Gitブランチモデルの比較と使い分け

開発

背景

開発初期のプロジェクトに参画していまして、その際に「Git FlowとGitHub Flowのどちらにします？」という質問がありました。 Git Flowの存在は知っていましたが、経験はありませんでした。

  • GitFlow以外にはどんなものがあるか？
  • それらをどう使い分けるのがいいか？

が気になったので、自分なりの結論を出そうと思いました。

調査

※ 公式リファレンスや先駆者の方々がまとめてくださっているため、個人メモ程度にまとめています。

Git Flow

develop, masterブランチを中心に、feature, release, hotfixブランチを切っていく。 feature/hotfixの役割を明確に別れておりブランチ運用のミスを軽減できるのがポイント。 ただしその分複雑。

cf.

GitHub Flow

masterからfeatureを切って開発し、終わったらmasterに対してPull Requestを出す。 レビューしてmasterにマージしたら、基本的には即本番反映。

ルールが少ないのがメリットで、masterにどのfeatureをデプロイしたか確認コストがかかるのがデメリット。

GitLab Flow

Git Flowの改良版。Git Flowのdevelopに当たる位置にmasterがあり、release, masterの位置にpre-productionとproductionがある。

hotfixもGit Flowでは(productionにあたる)masterから切っていたが、こちらでは(developにあたる)masterから切っている。 そのためmasterでのテストが通れば、下流であるpre-production, productionもテストが通る、という点がポイント。ただしブランチ数は多く複雑。

cf.

Git Feature Flow

master, feature, test-env(stg-env)で運用する。 案件ごとにfeatureを切るのが特徴で、これにより案件ごとにリリース日が設定されている場合のリリース調整がしやすくなる。

※ 他の方法だと(通常)masterにマージされてからリリース調整をすることになりがち

cf. GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ

ブランチモデルの使い分け

私の結論としては以下のとおりです。

  • 1-2人の開発チームのみの場合、GitHub Flowを使う（他だと過剰）
  • biz, CSなど他チームがいる or 狙ったタイミングでリリースする必要がある or iOS開発の場合、GitLab Flowを使う
  • 粒度の大きい開発案件が並走し、それぞれリリースタイミングが異なる場合、Git Feature Flowを使う
  • joinする現場で求められた場合、Git Flowを使う

基本的にはルールをシンプルに保ちつつ、組織体制に応じて少しずつルールを加えるのがいいかなーと。

Git Flowは複雑に見えました。自分が小規模開発を中心にしているのもあり、軽く知っておけば十分かな。