GitHub Advent Calendar 2024の14日目の記事です。昨日はwa-chan222さんの未経験から始めたGitHub活用の基本と学びでした。
はじめに
フューチャー社内の有志メンバーでGitブランチフローの規約を作成しました。
ひとまずは形になったので紹介します。
Gitブランチフロー規約 | Future Enterprise Coding Standards
※GitHub/GitLabを利用し、トランクベース開発を採用しないアプリケーション開発を想定しています。
内容へのフィードバックは、Issueかツイッター宛にメンションを入れてコメントを貰えると幸いです。
なぜ今更Git？
Gitは2005年に公開され、2007年のGitHub登場以降、バージョン管理ツールとして爆発的に普及しました。現在では、業界のデファクトスタンダードと呼べるほどの地位を確立しています。
公開から約20年が経過し、その間にGitFlowやGitHubFlowに代表されるGitブランチ戦略が開発され、Gitの使用方法が定義されてきており、その議論はしつくされていると言っても過言では無いでしょう。
一方で、前述のとおり、Gitの取り扱いに関する資料は世の中に数多く存在しますが、実際のプロジェクトでどの戦略を採用すべきかについて言及している資料は比較的少ないのが現状です。
フューチャーにおいても、各プロジェクトでどのブランチ管理戦略を使用するかの検討や、リリース戦略の認識合わせなど、プロジェクトごとに繰り返し行われてきた経緯があります。
そこで、本規約にて実際のプロジェクトで培われたGit運用の現実的なアプローチを、その理由とともにまとめることにしました。
規約のポイント
基本的なブランチ種別やブランチ命名規則、コミットメッセージ規約の他、本規約では特に以下について言及しています。
- ブランチ戦略の選定
git-flow、GitHub flow、GitLab Flowなどブランチ戦略がある中で、どのケースでどのブランチ戦略を使用すればよいのか？について、具体的な指針と推奨戦略を示しています。
また、複数の大型開発が並行する場合や、過去バージョンをサポートする場合のブランチ戦略の拡張についても言及しています。
- マージ戦略の選定
変更を取り込む方法として「マージコミット」「リベース」「スカッシュマージ」を紹介し、以下のケースごとの推奨操作を示しています。- developブランチからfeatureブランチへ変更を取り込む場合
- featureブランチからdevelopブランチへ変更を取り込む場合
- developブランチやmainブランチ等の永続ブランチ間で変更を取り込む場合
 |
 |
その他、アンチパターンの紹介や、git config、GitHub/GitLabの推奨設定についても触れています。
今後
Git運用の規約化については一旦完了ですが、内外からのフィードバックを受けて継続的にアップデートをしていく予定です。
また、今後も様々な設計方針をOSS化していく予定です。