Git ブランチ運用の基本フロー
本記事では、Git ブランチ運用のフローを解説します。そのなかで、2つのブランチ統合手法である git merge
と git rebase
の使い分けについて説明します。
Git のブランチ運用モデルにはいくつかの代表的なパターンがあります。特に有名なのは Git Flow と GitHub Flow です。これらのうち、シンプルなモデルフローが GitHub Flow です。本記事は GitHub Flow に沿ったブランチ運用のフローを紹介します。
1. フローの全体像
-
リポジトリのクローン
リモートリポジトリをローカルに取得する
-
ブランチの作成と切り替え
新機能や修正作業用に、
main
から独立したブランチを作成する -
コードの変更とコミット
作業内容をコミットしてローカルリポジトリに記録する
-
最新の
main
の取り込み他の開発者の変更を反映するため、最新の
main
ブランチを取得する -
作業ブランチへの統合
git merge
またはgit rebase
を使ってmain
の変更を作業ブランチに取り込む -
リモートへのプッシュ
変更内容をリモートリポジトリにアップロードする
-
Pull Request (PR) の作成とレビュー
GitHub 上で PR を作成し、コードレビューを経て
main
に統合する -
ローカル
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 "コミットメッセージを記述"
main
ブランチの取得
2.4. 最新の 他の開発者の変更を反映させるため、最新の main
を取得します。
git switch main
git pull origin main
main
の統合
2.5. 作業ブランチへの ここでは、feature
ブランチに main
の変更を取り込む 2 つの方法を紹介します。
(1) Merge を使う場合
merge
はマージコミットを作成し、履歴が分かりやすいという特徴があります。
git switch feature
git merge main
コンフリクト発生時の対処:
-
git status
で衝突ファイルを確認 - 衝突部分を手動で修正
-
git add
で修正内容をステージ -
git commit
でマージコミットを作成
(2) Rebase を使う場合
rebase
は履歴を直線的に整え、よりクリーンな履歴を保ちます。ただし、コミット履歴が書き換わるため、既に共有しているブランチでは注意が必要です。
git switch feature
git rebase main
コンフリクト発生時の対処:
-
git status
で衝突箇所を確認 - 衝突部分を修正
-
git add
で修正内容をステージ -
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 の作成
- GitHub で
feature
ブランチからmain
への Pull Request (PR) を作成 - CI/CD チェックが通り、チームのレビューを経てマージを実施
-
main
ブランチに変更を統合
main
の更新と不要ブランチの削除
2.8. ローカル 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