前置き

前回、git 運用のモデルとして git flow を見てみました。

github のメンバーはこれに対してこのような事を述べています

git flow は良いものだと思う
ただ、多くの開発者やプロジェクトが要求するよりも複雑すぎやしないか。
その複雑さ故にヘルパースクリプトなども開発されたが、コマンドラインでの使用を期待しているため、すべてのGUIに強制はできない。
なのでCLIに不慣れなメンバーほどしっかりと複雑なフローを学ばなければならない。

前回デメリットに上げた「複雑すぎる」という点についてやはり言及しています。

そして、GitHub では git-flow を使用していないことを述べ、
GitHub flow と銘打ち彼らが使用しているブランチワークについて説明しました。

というわけで今回は GitHub flow です。

git flow
github flow ← ココ
gitlab flow

github flow

GitHub 社が提唱するブランチワークフロー

登場するブランチ

名称	役割	分岐元	マージ先	備考
master	デプロイ可能な環境を保持する。	-	-	削除しない。
feature	機能ごとの開発用	master	master	Pull Request 無しに master へマージしない。

基本運用

master から作業内容を示唆する名称の作業ブランチを作成する。
作業ブランチで開発を行う
開発が終わったら master へ Pull Request を出す。
Pull Request が承認されたら master へマージする。

git-flow 複雑じゃね？を提唱のきっかけにしているのでさすがに簡潔
ただし、git操作以外にも厳密には以下のルールに従って運用される。

ルール

master は常にリリース可能な状態である。
master ブランチはデプロイ済みの内容、あるいは最低でも数時間以内にデプロイされる内容ということを意味する。
master ブランチが古いコミットへロールバックすることは非常に稀である。
問題が発生した場合、リバートが行われるか、問題への修正が速やかに master へマージされることで解決される。
必ずテストが行われたものが master へ取り込まれる。
これがこのフローにおいての一番大きなルール
必ず master から作業内容がわかる名称で作業ブランチを切る
ブランチのリストを見ると作業状況もわかる。
どんな機能が作られているのか、どの機能の開発が進行していてどれが滞っているのか。
ブランチリストの一覧性のためにも名称は説明的であるべきである。
前項の作業ブランチにコミットを行い、その内容は定期的に push する。
マージの瞬間にまとめて push は非推奨。
コミットだけ満足せずに push を細かく行うこと。
コミットすらしないのは論外。
Pull Request を使用し、master への取り込み前にはレビューが行われる。
GitHub の提唱するものなので Pull Request となっていますが、同等の機能を類するサービスを利用したり、制度を布けばよいでしょう。
フィードバック、助言が欲しい場合。マージを行っても良いと自分が思った場合にを作成します。
実際、master へマージを行いたいと思うタイミングのずいぶん前からレビューのために Pull Request を作成することもあるようだ。
ほとんどコードに進捗が無くてもスクショやアイデアだしのレビューのために Pull Request が開く場合もあるらしい。
あまりにも作業ブランチが長くなってきたら master との乖離を防ぐために master を時折取り込んで作業を続けよう。
Pull Request が承認されたら master へマージして良い。
Pull Request 上でのレビューが行われ、変更が承認されたのちにのみ master へマージすることができる。
未承認のマージ、master への直接の commit, push は行わない。
master へマージを push したら直ちにデプロイを行う。

また、master へのマージ前に複数の開発を統合するブランチを用意しても良いとの記述もあった。
GitHub 内で使用されている(らしい)ブランチワークのため、継続的デプロイを前提としており
機能が次々提供される継続的デプロイなプロジェクト進行ではなく、一定期間ごとのバージョンリリースを主軸にしている場合これが活用できるかもしれない。

git-flow が純粋にブランチ運用モデルなのに対し、こちらは開発運用やレビューなどのコミュニケーション部分に言及しています。

長所

git-flow に比べて明らかに作業が単純
開発も修正も同一のプロセスで自動デプロイまで接続する。

以上のことから早いサイクルのデプロイに堪え、所謂 CI/CD との親和性が高いと思われる。

短所

複数環境をサポートするシステムの場合、何がデプロイされているかの管理が必要になる。
デプロイ不能なタイミングのあるプロジェクトにはそのまま使用できない。

デプロイ作業によってダウンタイムが想定され、それが容認できないプロジェクトにはそのまま適用できない。

そのようなプロジェクトの場合、おそらくいくつかの開発内容をまとめたリリース行為やバージョン管理を行っていると思います。
この時、各々の作業内容が各人の作業ブランチにとどまってしまいいざ master へマージというときにコンフリクトを多発してしまってはいけないため、前述の通り master と作業ブランチの間に develop や release など適当な名称を付けた統合ブランチを用意しておく必要があるでしょう。

とまあいろいろ書きましたが、GitHub flow に関しては原文や訳文を直接参照してもわかりやすいでしょう。

参考

GitHub Flow
GitHub Flow (Japanese translation)
GitFlow vs GithubFlow