チーム開発におけるGitブランチ運用

Git運用の基礎：ブランチ構成とワークフローの実践

Gitを使ったチーム開発におけるブランチの運用方法について、ある程度汎用的なフローをまとめてみようと思います。

チーム開発でブランチを運用する際の参考にしていただければと思います。

ブランチ戦略の基本

主要なブランチ構成

効果的なGit運用には、目的に応じたブランチ構成が重要です。
一般的には以下のようなブランチがメインかなと思います。

• feature：開発者が作成する個別の開発ブランチ。滞留期間は基本的に1日〜長くても1週間程度の短期間
• hotfix：バグ報告が上がってきたバグの修正ブランチ。滞留期間は基本的に1日〜長くても1週間程度の短期間
• develop：メインの開発ブランチ。featureブランチをマージしていく日常の開発の中心
• staging：staging環境へ展開されるブランチ
• リリース用のブランチ 主にリリースされる対象のブランチ(release-yyyymmddなどとしたり、日付をつけずに)
• master：リリースが終わったあとの本番稼働中の安定した状態を格納しておくブランチ

切り出しなど

feature/hotfix・・developから切り出す。
release-yyyymmdd・・日付がある場合は、リリース日までが生存期間なので、リリースが終わってmasterにマージされた段階で、masterから次のリリースブランチを切り出す(日付をつけずずっと運用されていることもあり)

featureブランチの運用など

追加機能ごとに以下のようなブランチを切って運用しましょう。命名はデフォルトのgit flowを使っても良いですし、チーム独自のルールでも構いません。

• feature/XXX
• feature_XXX

XXXには機能名を英字で入れても良いですが、タスク管理ツール（Redmine、GitHub、Backlog）で管理している場合は通し番号を入れるのが最適です。後から変更履歴を追うことができ、プルリクエストの発行時にも参照しやすくなるからです。

英名でつけてもいいのですが、後で振り返ったときに大体忘れているので、チケット番号が一般的だと思います。

またupdateとかcommitとか意味ないコミットメッセージも多いのですが(爆)
コミットメッセージは、どんな修正をしたかが一目でわかることが重要です。以下の情報を含めましょう。

• 修正の種類：追加仕様、バグ修正、機能改善など（ブランチの切り方やルールが曖昧な場合は特に重要）
• 参照情報：タスク管理ツールの番号やID
• 簡潔な説明：何を変更したかの概要

僕が考える最強のコミットメッセージの書き方

hotfixブランチの運用

バグ修正に関してもfeatureブランチと同様のルールでブランチを切りましょう。追加機能と比べると粒度が小さくなりがちなので、超低粒度のものに関してはコミットメッセージで分類することを推奨します。

実際のワークフロー

基本的な開発フロー

一般的なブランチ運用として下記のようにするとスムーズなのかなと思います。

1. develop ← feature(hotfix): 個別のローカル環境で修正、確認が終わり、開発環境に修正を反映
2. staging ← develop: 開発環境での確認が終わり、staging環境に修正を反映
3. release-xxxxxxx ← stagin: staging環境での確認が終わり、リリース
4. master←release-xxxxxxx: リリースが終わり、masterブランチに正式な修正を取り込み(このときにタグも発行することが一般的。)

また開発チームが複数ある場合は、以下のような階層化されたブランチ運用もあり得ると思います。
Aチームがdevelop_A、Bチームがdevelop_Bにまずマージをして、その後developにマージするパターンです。
develop_xxxx ← feature
develop ← develop_xxx
など

実際の運用で大変だったこと

以前のプロジェクトでは数ヶ月〜年単位の長期プロジェクトの修正と週次のリリースを並行して運用しており、これらの並行運用や統合が結構大変でした。

対策としては、

• 週次の変更は当然、長期プロジェクトには並行して入れていく。先ほどの運用だと週次リリースのたびにrelease-****の変更がmasterと長期プロジェクトブランチに入る
• 差分の乖離を少なくするため、長期プロジェクトのDB定義などは、週次の変更に取り込んでいく(もちろん影響がない場合。)
• なるべく長期プロジェクトのリリースの粒度を細かくして、複数ブランチの並行期間や乖離を少なくする

などですかね・・
ここら辺は最適解というようなものはないとおもわれるため、プロジェクトの実態にあわせてよりより運用方法を探っていくことになると思います。