💭

Git ブランチ運用の基本フロー

2025/02/20に公開

本記事では、Git ブランチ運用のフローを解説します。そのなかで、2つのブランチ統合手法である git mergegit rebase の使い分けについて説明します。

Git のブランチ運用モデルにはいくつかの代表的なパターンがあります。特に有名なのは Git Flow と GitHub Flow です。これらのうち、シンプルなモデルフローが GitHub Flow です。本記事は GitHub Flow に沿ったブランチ運用のフローを紹介します。

参考: GitHub フロー - GitHub Docs


1. フローの全体像

  1. リポジトリのクローン

    リモートリポジトリをローカルに取得する

  2. ブランチの作成と切り替え

    新機能や修正作業用に、main から独立したブランチを作成する

  3. コードの変更とコミット

    作業内容をコミットしてローカルリポジトリに記録する

  4. 最新の main の取り込み

    他の開発者の変更を反映するため、最新の main ブランチを取得する

  5. 作業ブランチへの統合

    git merge または git rebase を使って main の変更を作業ブランチに取り込む

  6. リモートへのプッシュ

    変更内容をリモートリポジトリにアップロードする

  7. Pull Request (PR) の作成とレビュー

    GitHub 上で PR を作成し、コードレビューを経て main に統合する

  8. ローカル main の更新と不要ブランチの削除

    PR マージ後、ローカルの main を最新に更新し、作業ブランチを削除する

以下では、各ステップの詳細を解説します。


2. 各ステップの詳細

2.1. リポジトリのクローン

まず、リモートリポジトリからコードを取得します。

git clone <repository URL>

クローン後は、通常デフォルトブランチ(多くの場合 main)に切り替わっているので、状況を確認しておきます。

git branch
# 出力例: * main

2.2. 新しいブランチの作成と切り替え

新しい機能や修正作業は、main から分岐させた独自ブランチ上で行います。ここでは例として feature ブランチを作成します。

git branch feature
git switch feature

ヒント:

git switch は Git 2.23 以降で推奨される切り替えコマンドです。

代替として git checkout -b feature も利用可能です。


2.3. コードの変更とコミット

ブランチ上でコードを修正します。そのあと、変更内容をコミットします。

git add .
git commit -m "コミットメッセージを記述"

2.4. 最新の main ブランチの取得

他の開発者の変更を反映させるため、最新の main を取得します。

git switch main
git pull origin main

2.5. 作業ブランチへの main の統合

ここでは、feature ブランチに main の変更を取り込む 2 つの方法を紹介します。

(1) Merge を使う場合

merge はマージコミットを作成し、履歴が分かりやすいという特徴があります。

git switch feature
git merge main

コンフリクト発生時の対処:

  1. git status で衝突ファイルを確認
  2. 衝突部分を手動で修正
  3. git add で修正内容をステージ
  4. git commit でマージコミットを作成

(2) Rebase を使う場合

rebase は履歴を直線的に整え、よりクリーンな履歴を保ちます。ただし、コミット履歴が書き換わるため、既に共有しているブランチでは注意が必要です。

git switch feature
git rebase main

コンフリクト発生時の対処:

  1. git status で衝突箇所を確認
  2. 衝突部分を修正
  3. git add で修正内容をステージ
  4. git rebase --continue でリベースを再開
    ※ 問題が解決できない場合は git rebase --abort でリベースを中断可能

2.6. リモートリポジトリへのプッシュ

作業ブランチの変更をリモートに送信します。

git push origin feature

※ Rebase 後の場合:

リベースによって履歴が書き換わるため、通常のプッシュが拒否されることがあります。その場合は強制プッシュを利用します。

git push --force-with-lease origin feature

2.7. GitHub 上で Pull Request の作成

  1. GitHub で feature ブランチから main への Pull Request (PR) を作成
  2. CI/CD チェックが通り、チームのレビューを経てマージを実施
  3. main ブランチに変更を統合

2.8. ローカル main の更新と不要ブランチの削除

PR マージ後は、ローカルリポジトリを最新状態に更新します。

git switch main
git pull origin main

ローカルブランチの削除

作業が完了したブランチは、ローカルから削除します。

git branch -d feature

※ 未マージの変更がある場合は、強制削除が必要です。

git branch -D feature

リモートブランチの削除

リモートに残っている不要なブランチも削除します。

git push origin --delete feature

3. まとめと注意点

本記事では、GitHub Flow に基づいた Git の基本的な運用手順を解説しました。注意点は以下です。

  • 常に最新の状態を保つ: 定期的に main の更新を取り込み、コンフリクトの早期解決を心がける
  • ブランチの使い分け: 作業は必ず main から分岐したブランチで行い、不要になったら削除する
  • 統合方法の選択:
    • Merge: 履歴が明示的になり、分かりやすいがマージコミットが増える
    • Rebase: 履歴がシンプルになるが、既に共有されているブランチでは注意が必要
  • 強制プッシュ: Rebase 後のプッシュでは、-force-with-lease オプションを用いて安全に履歴を書き換える

以上です。Happy Branching!

Discussion