Gitのブランチ戦略の基本とルールを学んで使いこなそう

はじめに
Gitを使って開発を進める際に欠かせないのが「ブランチ」の運用です。適切なブランチ戦略を採用するとチーム開発の効率が向上し、コードの管理もスムーズになります。しかし「どのブランチをいつ作るべきか」「どのようなルールを決めるべきか」など、悩むことも多いのではないでしょうか。
本記事では、Gitのブランチ戦略の基本から実践的な運用ルールまで、分かりやすく解説します。
ブランチ戦略とは
Gitのブランチ戦略とは、ソフトウェア開発において複数の開発者が効率良く作業を進めるために、ブランチ(branch)をどのように作成・管理するかのルールを定めたものです。適切なブランチ戦略を採用することで開発のスムーズな進行、品質の向上、リリースの安定化を実現できます。
ブランチは、メインとなるコードベース(通常mainやmaster)とは別に、特定の機能追加やバグを修正するために作成されます。開発が完了すると、変更をメインブランチに統合(マージ)することで正式なコードとして反映されます。
しかし、適切なルールを定めずにブランチを作成・管理すると、作業の混乱や競合(コンフリクト)が発生しやすくなります。そのため、チームで統一したブランチ戦略を策定し、運用することが重要です。
ブランチ戦略には、以下のような目的があります。
- 開発フローの明確化:どのようにブランチを作成し、統合するのかを決めることで開発の流れを整理する
- 並行開発の促進:複数の開発者が同時に作業しやすくなり生産性が向上する
- コードの品質維持:適切なレビューやテストを実施することでバグや問題の発生を防ぐ
- リリース管理の簡素化:バージョン管理を効率化して安定したリリースが実現できる
ブランチ戦略にはいくつかの種類があり、チームの規模や開発スタイルに応じて適切なものを選択することが重要です。次項では、代表的なブランチ戦略の種類について詳しく説明します。
ブランチ戦略の種類
Gitのブランチ戦略には、チームやプロジェクトの特性に応じたさまざまな種類があります。適切なブランチ戦略を選ぶことで開発フローがスムーズになり、品質の高いコードを管理しやすくなります。ここでは、代表的なブランチ戦略を紹介します。
Git Flow
「Git Flow」はGitのブランチを活用して開発を進める戦略の1つで、以下のようなブランチを使用します。
- main(またはmaster)ブランチ:本番リリースされる安定したコードを管理
- developブランチ:次のリリースに向けた開発を進めるブランチ
- featureブランチ:新機能の開発用ブランチ。開発後、developブランチに統合
- releaseブランチ:リリース準備のためのブランチ。バグ修正などを行い本番環境へ
- hotfixブランチ:本番環境の緊急修正用ブランチ
Git Flowは開発の進捗状況を明確にし、リリースを管理するために複数のブランチを使います。反面、ブランチが深くなりやすく、コンフリクトが発生しやすくなったり、管理が複雑になるというデメリットもあります。
Git Flowを使って通常の開発フローを進めると、以下のような流れになります。
- developブランチからfeatureブランチを作成し、新機能を開発する
- featureブランチの開発が完了したら、developブランチにマージする
- developブランチからreleaseブランチを切り、リリースの準備をする
- リリース準備が完了したら、releaseブランチをmainブランチにマージする
- リリース後に発生した緊急のバグはhotfixブランチを切って修正し、mainブランチにマージする
GitHub Flow
「GitHub Flow」はシンプルなブランチ戦略であり、特に継続的デリバリー(CD)を重視するプロジェクトに適しています。
- main(またはmaster)ブランチ:常にデプロイ可能な状態を維持
- featureブランチ:新機能や修正のために作成し、完成後にmainブランチへマージ
開発の流れとしては①mainブランチからブランチを切り、②新機能や修正を加えた後、③プルリクエストを作成し、④レビュー後にmainブランチへマージする、というシンプルな仕組みです。
GitHub Flowを使ってみよう
今回は、GitHub Flowのブランチ戦略を使ったときのGit操作の流れを分かりやすく説明します。
GitHub FlowはGit Flowに比べてシンプルで学習コストが低く、初心者でも始めやすいワークフローです。Git Flowでは開発(develop)、リリース(release)、ホットフィックス(hotfix)など複数のブランチを管理する必要がありますが、GitHub Flowではmainブランチと機能ブランチのみを使用するため、ブランチ操作に慣れていない人でも扱いやすく、迷わず開発を進められます。
シンプルな仕組みのため初心者でもすぐに実践でき、チーム全体でスムーズにコラボレーションできるのも大きなメリットです。
GitHub Flowの基本ルールと流れ
GitHub Flowではmainブランチをいつも安定した状態に保ち、新しい機能や修正をするたびにブランチを作って作業を進めます。基本の流れは次のとおりです。
- mainブランチから新しいブランチを作る
- 変更を加えてコミットする
- リモートリポジトリへプッシュする
- プルリクエストを作ってレビューを依頼する
- レビューが終わったらmainブランチにマージする
- mainの最新状態をローカルに反映する
- 使い終わったブランチを削除
それでは、実際にこの流れを試してみましょう。
1. 新しいブランチを作る
第2回を参考にリポジトリを作成し、ローカルにクローンします。
次に、作業を始めるために新しいブランチを作成します。feature-branch
は機能の変更や追加をするためのブランチ名です。ブランチ名は自由に決めることができますが、feature
など固定の文字列を含めておくと分かりやすいです。
$ git switch -c feature-branch Switched to a new branch 'feature-branch'
ブランチが作成できたら、git branch
コマンドで現在のブランチを確認します。
$ git branch * feature-branch main
*
が付いているのが現在のブランチです。feature-branch
が作成されて切り替わっていることが分かります。
2. コードを変更してコミットする
ブランチを作ったら実際にコードを変更し、その内容をコミットします。
$ echo "GitHub Flowを試しています" > sample.txt $ git add sample.txt $ git commit -m "Add a new file" [feature-branch 2417319] Add a new file 1 file changed, 1 insertion(+) create mode 100644 sample.txt
3. リモートリポジトリにプッシュする
変更をGitHubに反映させます。
$ git push origin feature-branch Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 10 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 322 bytes | 322.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'feature-branch' on GitHub by visiting: remote: https://github.com/VirtualTech-DevOps/github-flow-sample/pull/new/feature-branch remote: To https://github.com/VirtualTech-DevOps/github-flow-sample.git * [new branch] feature-branch -> feature-branch
4. プルリクエストを作る
GitHubのリポジトリページにアクセスし、作ったブランチを元にPull Request(PR)を作成します。画面に表示されている「Compare & pull request」をクリックします。
プルリクエストの作成画面が表示されたら、タイトルと説明を入力します。今回は簡易的に入力していますが、実際の開発プロジェクトでは変更内容や目的を分かりやすく記載するようにしましょう。
内容が記載できたら「Create pull request」をクリックします。
5. レビューを受けてマージする
チームメンバーにレビューを依頼し、問題がなければmainブランチにマージします。
「Merge pull request」をクリックすると確認画面が表示されるので、「Confirm merge」をクリックします。
6. ローカルの最新状態を更新する
mainブランチに戻り、mainブランチを最新の状態にアップデートします。
$ git switch main $ git pull origin main
これで、GitHub Flowを使ったGit操作の基本的な流れは終了です。GitHub Flowはシンプルで分かりやすいため、チーム開発でも使いやすいブランチ戦略です。
7. 使い終わったブランチを削除
最後に使い終わったブランチを削除します。
・ローカルのブランチを削除する
$ git branch -d feature-branch Deleted branch feature-branch (was 2417319).
・リモートのブランチを削除する
$ git push origin --delete feature-branch To https://github.com/VirtualTech-DevOps/github-flow-sample.git - [deleted] feature-branch
これで、GitHub Flowの一連の流れは終了です。
おわりに
Gitのブランチ戦略はチーム開発を円滑に進めるためにとても重要な要素です。適切な戦略を選ぶことで開発の効率が上がり、コードの品質も向上します。また、代表的なブランチ戦略を採用することで新メンバーのオンボーディングもスムーズになります。
ブランチ戦略の選択はプロジェクトの規模や特性によって異なりますが、GitHub Flowはシンプルで使いやすいため、はじめてブランチ戦略を導入するチームにオススメです。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- 「GitHub」にブランチ保護、Dependabot、Secret Scanningを設定してみよう
- DevOpsにおける開発者の振る舞いを理解しよう
- 「GitHub」にリポジトリを作成してみよう
- これだけは押さえておきたいGitHub Flowの基礎
- Protected Branches機能で柔軟なワークフローを構築する
- CI/CD Conference 2023、DMMのエンジニアが解説するCIを加速するトランクベースの開発とは
- RevertとBlameを使いこなして安全性の高い開発を推進しよう
- Oracle Cloud Hangout Cafe Season4 #3「CI/CD 最新事情」(2021年6月9日開催)
- DevOpsのアプリ開発にも欠かせない「Git」を活用したソースコードのバージョン管理
- GitHubとGitのおさらい