【技術】Gitの有名フロー3種を自分なりに理解したのでメモ
記事を書くきっかけ
社内環境がGiteaというGitサーバに変わったので、これまでのSVNライクなブランチ管理からGitライクなブランチ管理に切り替えようと思い、社内に提示するために調査しました。
そもそもなぜブランチ管理を変えようと思ったか
今後システム改修を複数案件同時並行で行う予定のため、改修時のコードを案件別にきれいに保ちたいと思ったことが第一にあります。
これまでは、案件のリリース日ごとにブランチを切っていくモデルであり、複数案件同時実施する場合は、案件の規模にかかわらず期間が最長になる案件に合わせてリリースせざるを得ない状況でした。
また、受入テストを一部案件で実施中＆継続して同ブランチで他案件作業中で受入テスト中の案件に故障が発生した場合、実施中の他案件の受入テストリリースまで、お客様に待っていただく必要がありました。
今の変化が速い時代に、こんな悠長なことはできないということで、変更を計画した次第です。
以下調査した各フローの自分なりの理解です。
Git-flow
概要
Git-flowというのは、上図のフローを実現するためのアドインの名前です。
ただ、現実問題としてGit-flowといえば上図のフローそのものを指すようになっているので、本記事でもそのように紹介します。
Git-flowでは以下の5本のブランチを使用します。
Main
Master
Masterは、プロダクトとしてリリースしているブランチを示します。
直接変更することはなく、Release/Hotfilxから変更を取り込みます。
Develop
Developは開発中のコードを管理するブランチです。
基本的には最新版はこちらになります。こちらからFeatureを切り、Featureで扱う変更が完了したらマージされたうえ、Releaseとしてリリース準備のブランチを切ります。
Hotfixから緊急修正を取り込むこともあります。
Sub
Feature
機能追加を扱うブランチです。Featureの単位は追加する機能（画面や帳票、バッチなど）の単位が良いとされています。
Developにマージした段階でブランチを削除します。
SIの案件だと機能単位で切るのはなかなか面倒な気がします。複数案件同時で全く異なる機能を扱うときも困りますね。
Release
FeatureからDevelopにマージの上、リリース準備段階に入ったコードを管理します。
リリース前の最終調整（SIなら受入テストでしょうか）での変更はこちらで管理し、適宜Developにマージします。
リリース時にMasterにマージし、ブランチを削除します。
マージ時にはタグを切ります。メジャーバージョンアップとして扱います。
Hotfix
緊急修正の場合に使用するブランチです。
このブランチは唯一Masterから分岐します。対応終了後はMasterおよびDevelopにマージして削除します。
このの場合はタグのメジャーバージョンを上げず、マイナーバージョンアップとなります。
メリット・デメリット
メリットとしては以下の通りです。
- コード管理が段階ごとに明確にできる。
- ブランチの役割は明確なので、あいまいさがない。
- 専用のツールがあり、たいていのブランチ操作は自動化できる。
デメリットは以下の通りです。
- フローが複雑で理解に時間が必要
- ツールの助けがあるとはいえ、教育コスト、管理コストがかかる
- 操作が複雑になるため、開発高速化は難しい
どんなシステムにあっているか
リリースしたら落ち着く（明確なリリーマイルストーンがある）システム
例）SIの受託開発/開発チームの人数が多い大規模プロダクトで、頻繁な変更が不要なもの など
Github-flow
概要
名前の通りGithubのプルリクエストなど、コミュニケーション機能を活用する前提のフローになっています。
小規模な機能追加が一日に何回も発生するし、テストなどが自動化されているようなシステムを想定したフローです。
構造はシンプルで、２本のブランチを使用します。
Master
プロダクトのリリースコードを管理します。
Feature
機能開発のコードを管理します。Masterマージ時には、プロダクトに含めても正常稼働することが求められます。
Pre-Mergeチェックできちんと自動テスト等で保証する必要があります。
メリット・デメリット
メリットは以下の通りです。
- 高速開発が可能
- フローがシンプルで理解しやすい
デメリットは以下の通りです。
- モダンなプロダクトでないと適用は難しい（レガシーシステムの大半は自動テストしてないんじゃなかろうか）
- コミュニケーションに依存している部分が多い
どんなシステムにあっているか
とにかく高速開発が求められる変化が速いシステム
例）SaaSなど
Gitlab-flow
概要
本家Gitlabのサイトによればいろいろ種類がありますが、「GitlabのIssue」をベースにシステム開発を行うフローです。
上図は環境ごとにメインブランチを分けるパターンです。
以下のブランチを使い分けます。
Master
開発環境など、開発中のコードを管理します。
普通のフローと逆なので困惑する部分です。
Pre-Production
検証環境など、本番環境リリース前のステージングサーバがある場合に設けるブランチです。
Masterで開発完了してDeployするタイミングでマージします。
Production
製品で使用しているコードを管理するブランチです。
Feature/Hotfix（図にはありませんが存在するパターンもあります）
機能開発/緊急バグ修正を行うブランチです。完了したらMasterにマージして開発環境にデプロイします。
メリット・デメリット
メリットは以下の通りです。
デメリットは以下の通りです。
- リリース後に他機能の開発をしてMasterが汚れてしまった場合に、どのように不具合対応するかが明確でない
- 通常のフローと異なり、Masterが開発の中心となるので、違和感を感じる人が多いかも
どんなシステムにあっているか
環境ごとに明確にコードを管理したいシステム
例）SI受託開発
ちなみに
私の担当プロジェクトでは、案件ごとのコード管理を明確化したいということで、Git-flowベースを採用することにしました。
採用はこれからですが、頑張って定着を目指します！
