（タイトルは釣りですが）全国３０００万のエンジニアの皆様は今日もGitの運用に頭を悩ませていることと思います。
思い悩む余りGitFlowやGithubFlowに手を出して傷を広げてしまうことも多々あるかと思います。
今から私が運用の正解をお教えしたいと思います。
正解？ ねぇよそんなもん
石を握りしめた方、ちょっとだけ待って下さい。
普遍的な正解はないですが、普遍的な失敗はあるはずです。例えば
- コンフリクト地獄
- リリースしたいブランチに紛れ込む未完成の機能
- リリースしたいブランチに紛れ込む次バージョンの機能
といったものです。
こういった失敗を生み出してしまう原因がわかれば、運用上注意しなければならない事と言うのも自ずから判明するはずです。つまり、
- コンフリクト地獄→ブランチの寿命、マージの方向
- リリースブランチに未完成機能→リリースブランチの明確化、マージ時の動作保証
- リリースブランチに次期バージョン→リリースブランチの明確化、マージタイミングの保証
などと言うことになるわけです。
では、代表的な運用フローであるGitFlow・GitHubFlowを通じて確認していきたいと思います。
GitFlow
- ブランチの寿命
- 長寿命ブランチ → develop、master
- 短寿命ブランチ → feature、release、hotfix
- develop→featureのマージを随時行う。
- リリースブランチの明確化 → 本番リリース可能なのはmasterのみ
- マージ時の動作保証 → feature→developのマージは開発終了時のみとするフローシステム上の「契約」。developからmasterへのマージ時にreleaseブランチを作成し、動作を確認する。
- マージタイミングの保証 → masterブランチは常にリリース可能であるというフローシステム上の「契約」。リリースタイミングが来ない機能はfeatureおよびdevelopに保留する。
GithubFlow
- ブランチの寿命
- 長寿命ブランチ → master
- 短寿命ブランチ → feature
- develop→featureのマージを随時行う。
- リリースブランチの明確化 → 本番リリース可能なのはmasterのみ
- マージ時の動作保証 → masterへのマージ時にpull requestを発行し、コードレビューを行う
- マージタイミングの保証 → 同上。リリースタイミングが来ない機能はfeatureに保留する。
GithubFlowはGitFlowを簡略化したものなのでよく似ています。
どちらもブランチの寿命を明確化し、長寿命ブランチへのマージに制限をつけること、本番リリースを行うブランチを１つの長寿命ブランチに縛ることによって問題を起こりにくくしています。
GithubFlowはdevelopブランチを削除し、プルリクを使用することによってGitリポジトリ上の作業の簡略化とより厳密なマージの制御を行っています。
が、先ほども言ったとおりこれらだけが正解というわけではありません。
たとえば、必ずしもmasterを唯一のリリース可能ブランチとしなければならないわけではないです。
短寿命リリースブランチを使用する
実は今私が携わっているプロジェクトは、「masterからブランチを切り、動作確認が終わり次第そのブランチをリリースする」という運用を行っています。
完全に運用フェイズであり、大規模開発を行う可能性が少ないこと、エンジニアの人数が非常に少なく、口頭での確認で十分にトラブルを避けられることにより、簡略化したフローでも十分に運用可能な状況にあり、かつ、サーバインフラがGAEであり、複数のバージョンが混在してデプロイ可能であるため、リリースブランチも併存する方が自然であるという特殊な条件によるフローですが、名前のついた立派なフローでなくても運用可能であることはおわかりいただけるかと思います。
結論
混乱を避けるため、意識すべきは、プロジェクトの寿命、許容するマージの方向、リリース可能ブランチの制限、リリース可能ブランチがクリーンであることの保証です。
あとはプロジェクトによって変化する条件次第で変化するメリットデメリットをどう評価するかでフローを使い分けるべきでしょう。
GitFlowであれば運用時の手数の多さはスピード感を重視するプロジェクトでは大きなデメリットになります。GithubFlowのプルリク・レビュー依存はレビュアーの質がよいことが前提になってしまいます。
私のプロジェクトでの運用はミニマムなチーム以外では通用しないと思われます。
GitFlow、GithubFlow、今回は亜種の多さ故にひとことでの説明が難しく、触れませんでしたがGitlabFlowなど、一通り触れておくといいかと思います。