gitのブランチ運用ルールについてのご紹介
はじめに
こんにちは！AITPの壱岐です！
今回はgitのブランチ運用ルールについて紹介したいと思います。
他にも派生系を含めるといくつものブランチ運用はありますが、今回は有名所の
・GitFlow
・GitHubFlow
・GitLabFlow
について紹介します。
GitFlow
GitFlowはmain(master)、develop、feature、release、hotfixブランチを使った運用になります。
main(master)ブランチ
このブランチでは作業は行いません。 releaseまたはhotfixブランチからマージされることで進みます。 本番環境にリリースされるもの ＝ mainブランチの最新のものとなるようにしておきます。
releaseブランチ
developブランチからmainブランチへマージする準備のためのブランチです。 バージョン表記の変更や細かい文言の変更等に使用されることが多いです。 ブランチの終了時(≒リリース準備が完了したら)mainブランチとdevelopブランチへマージします。 mainブランチへマージしたときにマイナーバージョンやメジャーバージョンを上げてタグを作成します。
developブランチ
開発用ブランチです。このブランチでの直接作業は基本的には行わず、developブランチを派生元としてfeatureブランチを派生させて開発を進めて行きます。コードが安定しリリースできるような状態となったらreleaseブランチを派生させます。
featureブランチ
1つの改修ごとにdevelopブランチからfeatureブランチを派生させて対応します。 改修が完了したらdevelopブランチへマージします。 大きな開発をする場合にはfeatureブランチからfetureブランチを派生させることもあります。
hotfixブランチ
リリース後のクリティカルなバグフィックスを行うためにmainブランチから派生させます。 修正が完了したらmainブランチとdevelopブランチへマージします。 mainブランチへマージしたときにパッチバージョンを上げてタグを作成します。
メリット
- 比較的知れ渡っているブランチ運用なのでメンバー全員に認識がある場合には導入が容易
- git flowコマンドやそれと同じ動作をするSourceTreeやVSCodeの拡張機能もあるので、慣れると便利
デメリット
- 少し複雑なため習熟者が少ないチームの場合、学習コストがかかってしまう
- releaseブランチの終了時とhotfixブランチの終了時にmain/developブランチへマージする必要があり、慣れていない場合手順漏れに繋がりやすい
git flowコマンドでmain/developブランチへのマージ、タグの作成までを1コマンドで行うことも可能ですが、その場合はプルリクエストでの承認フローが行えないデメリットもあります。
チームごとにどこまで容認するかに寄りますが、以下のようなカスタマイズ運用でも良いと思います。
・release/hotfixブランチの終了時はプルリクエストは通さずにgit flowコマンドで処理をしてmain/developブランチへのマージ漏れが無いようにする。
・featureブランチの終了時のみプルリクエストによる承認フローを通し、このときにレビューを行う。
(releaseブランチは開発が行われるわけでは無いのでレビューは必要ないという考えと、hotfixブランチは複数人で集まって対応を行い認識のすり合わせを行った上で対応を行い急ぎで対応をしたいという考えから、そのタイミングでのプルリクエストは不要であると決定して運用しているチームも有りました。)
GitHubFlow
公式ドキュメント: GitHub フロー
GitHub共同創設者の一人であるScott Chacon さんのGitFlowの問題点とGitHubFlowについて: GitHub Flow
(日本語訳をされている方もいらっしゃったので引用させていただきます: GitHub Flow日本語訳 )
GitHubFlowは(ブランチ名の明言はされていませんが) MainブランチとFeatureブランチのみのシンプルな運用となります。
ざっくり概略を表すと下図のようになります。
以下のようなルールの元、運用を行います。
- mainブランチは常にデプロイ可能な状態にしておく
- 新しいことに取り組む際はMainブランチから説明的な名前の(feature)ブランチを作成する
- featureブランチは定期的にプッシュする
- フィードバックや助けが必要なとき、もしくはブランチをマージする準備ができたらプルリクエストをオープンする
- 他の誰かがレビューし、その機能を承認したらmainブランチにマージすることができる
- mainブランチへマージ・プッシュしたら、すぐにデプロイする
メリット
- ブランチの種類がmainブランチとfeatureブランチの2種類しかなく理解しやすく、シンプルであるため学習コストが低い
デメリット
- 2種類のブランチしか無く、mainブランチは常にリリース可能な状態を保ち続ける必要があるため、競合が発生しやすく、競合の解決→動作確認→プルリクエストによる再レビューの手順が増えがちになってしまう
- リリース前の検証がfeatureブランチのみなので、改修を確実に行う必要がある
GitLab Flow
公式ドキュメント: GitLab Flowの紹介
GitLab Flowではmain(master)、Pre-Production、Productionブランチを主体とした運用方法です。
それらに加えてGitFlowと同じくfeatureブランチやhotfixブランチで開発やバグ対応を行います。
メインとなるブランチがGitFlowはdevelopブランチであることに対し、GitLabFlowではmainブランチとなっています。
機能開発時はmainブランチからfeatureブランチを派生させ、機能の実装が完了したときにマージリクエスト(※)を行い、mainブランチへマージします。
※GitLabではGitHubのプルリクエストに該当するものがマージリクエストというのでこの表現にしています。
Pre-ProductionブランチはGitFlowのreleaseブランチに似たブランチです。
Productionブランチはリリースが完了したコードが保管されるブランチになります。
開発フロー
- 機能開発はmainブランチからfeatureブランチを派生させて対応し、開発が完了したらmainブランチへマージリクエストを作成し、問題なければmainブランチへマージする。
- リリースを行う前にmainブランチからPre-Productionブランチへマージリクエストを作成し、マージ後、ステージング環境等で動作確認を行う。
- 動作確認を行った資材をリリースし、リリースが完了したらPre-ProductionブランチからProductionブランチへマージリクエストを作成し、マージしてリリース作業完了。
ホットフィックス対応
- mainブランチからhotfixブランチを派生し、改修完了後mainブランチへマージリクエストを作成し、マージする。
- その後、開発フローと同じようにmainブランチからPre-Production→Productionブランチへとマージリクエスト・マージを行いリリースを行う
メリット
- GitHub Flowと同じく開発/バグフィックスのマージ先ブランチが常にmainブランチである
- (GitFlowのようにmainとdevelopの2箇所にマージしない)
- Production(本番適用済み)とPre-Production(本番適用直前)とわかりやすい構成になっている
デメリット
- (GitFlowと同じく)慣れるまでは少し複雑
- (資料が少なく、それぞれの理解に違いがありそう)
おわりに
簡単な説明となりますが以上となります。
冒頭でも説明しましたが、gitの運用についてはいくつもあり、今回紹介したものはその一部分です。
また、どの運用方法が一番良いというものでもなく、チームに合った運用を探し出して、状況に応じてカスタマイズしつつ運用していくと良いと思います。