はじめに

こんにちは！ITスクールRareTECHにてCS（Customer Support）を担当している池村です。今回の記事はGitのブランチ戦略についてです。これに関しては会社によって正解が異なります。というより、明確な正解はないのかもしれません。今回は、有名な二つのブランチ戦略について解説します。

前回の記事は👇

ここまでの記事でまだ出てきていないコマンドも紹介します。

ブランチ戦略って？

まず、ブランチ戦略とは、ブランチの切り方や統合の仕方、開発のプロジェクトにおいてどう運用していくのかについての戦略です。

ブランチ自体が、開発者によって簡単に作れてしまう、切ったブランチからさらに切ることができると言った自由度の高い機能です。チーム開発において、適当にブランチを切ったりしていると、コンフリクトの温床になります。開発においてはルール化した方がスムーズな開発を行うことができます。

特に昨今のCI/CD周りと組み合わせるには、Gitの上手な運用が必須なので押さえておきたいところです。

いくつか王道なブランチ戦略がありますので、そちらを見ていきましょう。

GitHub Flow

まずGitHub Flowです。これは小規模開発に有効で、数人でチーム開発を行う小さなアプリ作成時などに使うブランチ戦略です。ただ、中〜大規模開発系ではちょっと大雑把すぎるので推奨できません。

まず前提として、GitHubでリポジトリを作成すると、mainブランチが作成されます。

古い記事などではmasterブランチと書かれているものもありますが、現在はmainで統一されています。masterと書かれている記事はそのままmainと置き換えても良いです。

さて、このGitHub Flowは、このmainブランチをリリース用のブランチとして利用、それ以外のブランチは開発用のブランチとして利用と、極々シンプルな運用方法です。

基本的な流れは以下になります。

① `main`ブランチ（最新版）から開発用のブランチを切る

mainブランチを元に開発用ブランチを作成

# 例えばログイン機能を作成するブランチの場合
git checkout -b feature/login

# 現在はswitchコマンドが推奨されている
git switch -c feature/login

そういえば、ここまでの記事でブランチを切る際にbranchコマンドしか使っていなかったので、ついでにブランチを作りつつ移動する方法を紹介します。

git checkout -b ブランチ名：-bをつけ、ブランチを作りつつそのブランチへ移動
git switch -c ブランチ名：-cをつけ、ブランチを作りつつそのブランチへ移動

② 作業用ブランチで開発を行う

作業用ブランチに移動ができたら、機能を完成させます。
コミットを終えたら、そのままブランチをpushします。

pushする

git push origin feature/login

③ プルリクエストを作成して、レビューしてもらう

開発者はプルリクエストを作成して、レビュワーにレビューをしてもらいます。
レビュワーは機能やコードに問題がなければ、mainブランチにマージします。

プルリクの例👇（結構適当に書いてます）

④ `main`ブランチにマージされたら、ローカルの`main`を最新版に

mainブランチが最新版になったので、ローカルではpullを行います。

ローカルのmainブランチを最新版に

git pull origin main

⑤ 新しいブランチを切って次の実装へ

次はサインアップ機能を作成

git checkout -b feature/sign-up
# or
git switch -c feature/sign-up

やることはこれだけ

ここまでがGitHub Flowの手順です。
シンプルが故に、迅速な開発が可能です。運用に迷うこともあまりないでしょう。

本当に小規模なアプリ専用です。TODOアプリやシンプルなチャットアプリ程度のものならこれで良いです。

Git-flow

さて、GitHub Flowがかなりシンプルで運用をしやすいことがわかりました。ですが、中規模から大規模開発においてはこの運用では大雑把すぎます。

王道なGit-flowを見ていきましょう。名前は似てますが、内容はかなり違います。

こちらのブランチ戦略では、mainがリリース用であることは同じですが、最新版は常にdevelopブランチになります。

基本的にdevelopブランチから開発用のブランチを切ります。ここの命名はGitHub Flowとほぼ一緒です。

新規開発系

開発用ブランチを切る

開発用はGitHub Flowと一緒

# developブランチにいる前提です
git checkout -b feature/login
# or
git switch -c feature/login

開発後に`push`する

pushを行い、プルリクエストを作成する。
ここで注意点なのは、マージ先がdevelopブランチということです。

GitHub-Flowと違うので注意です！mainブランチに間違ってプルリクエストを送ると怒られちゃいます。

リリース時の準備ブランチ

新機能を実装して、リリースの準備を行う際に、リリース用のブランチを作成します。

こちらは実際に行っている会社とそうでない会社で分かれる気がしています。うちの自社開発のアプリではリリース用のブランチを作っていないので。でも外部の開発案件等では作っていたりします。

リリース用ブランチを作成

# developブランチにいる、最新版の状態になっている前提です
git checkout -b release/v1.0.0
# or
git switch -c release/v1.0.0

# pushする
git push origin release/v1.0.0

その後、プルリクエストをマージしていきます。

タグ付け

こちらが結構重要になってくるのですが、ブランチにタグ（目印のようなもの）をつけていきます。リリースのバージョン情報のようなものです。

タグ付け

# mainブランチ上で行う。
# -aで注釈付きタグをつける。（後述します）
git tag -a v1.0.0 -m "Release v1.0.0"

# タグをpushする
git push origin v1.0.0

リリースのバージョンによって、v1.1.0とか、v2.0.0などをつけます。この辺りはアプリやシステムの状況、会社の方針によってバージョン管理はさまざまです。v1.0とかv2.0など、大雑把につけるときもあります。

緊急時のバグ対応

基本的にはdevelopが最新なのですが、本番環境にバグを見つけ、その対応を緊急で行う場合は、hotfixというブランチをmainブランチから切ることになります。

hotfixの作り方

# mainブランチにいる、mainブランチが最新版である前提です
git checkout -b hotfix/login-fix
# or
git switch -c hotfix/login-fix

hotfixブランチは、修正が完了したら、mainブランチに直接マージされます。

ですので、バグ解消が完了したら、その変更をdevelopブランチにも反映させるようにしてください。

もう少し細かくブランチを切るなら

緊急時ではなく、まだ開発段階でバグが発生している箇所を発見した場合ですが、bugfixというブランチを作成するとわかりやすくなります。featureブランチ同様、マージするのはdevelopブランチです。

bugfixの作り方

# developブランチにいる、developブランチが最新版である前提です
git checkout -b bugfix/AdminLoginBug
# or
git switch -c bugfix/AdminLoginBug

ブランチの命名ルールは色々ありますので、ケバブケース、スネークケース、キャメルケースなど、調べて見てください。上記はパスカルケース（アッパーキャメルケース）で書いています。

このbugfixはGit-flowに含まれている方法ではないので注意です。

ブランチの運用一覧

ブランチ名	用途・役割
`main（master）`	安定したリリース版を管理する
`develop`	開発中の機能を集約する
`feature/機能名`	機能単位で開発
`release`	リリース準備をする
`hotfix`	緊急バグ修正

ブランチ戦略一覧

名称（英語）	名称（日本語）	特徴
Git-flow	Gitフロー	明確な役割ごとのブランチ構成
GitHub Flow	GitHubフロー	シンプルな`main`＋機能ブランチのみ
GitLab Flow	GitLabフロー	環境別（本番・ステージング）の管理に適する
Trunk-Based Development	トランクベース開発	一本のmainブランチで迅速に開発
Forking Workflow	フォーク型ワークフロー	OSS向け、外部開発者が多い場合に有効
Feature Branch Workflow	フィーチャーブランチワークフロー	機能単位でのブランチ管理

基本はGit-flowを元にしたブランチ戦略が主になっている会社が多いのかな？と思っています。

`git tag`について

git tagはコミットにタグをつけることができるコマンドです。
タグには二種類あって、以下になります。

軽量タグ
注釈付きタグ

基本的には注釈付きタグを利用した方が良いです。詳細が書かれないため。

タグの使い方

# 注釈付きタグ
git tag -a v1.0.0 -m "Release v1.0.0"

# 軽量タグ（メッセージがつかない）
git tag v1.0.0

# タグの一覧を見る
git tag

# タグの詳細を見る
git show v1.0.0

実行結果👇

タグを利用して、resetコマンドで戻ったりもできます。

タグを消したい場合

git tag -d v1.0.0

おわりに

今回はブランチの切り方、開発における戦略についてまとめました。
開発を行う上では必須な知識ですので、初心者の方はしっかり覚えていきましょう。
これらの技術を押さえる手っ取り早い方法はチーム開発を行うことです。スクールなどに在籍している方は積極的にチーム開発をしてみてください！