【2026年9月最新】Gitブランチの作り方からリモートへのプッシュ・削除まで完全解説
aikanri-admin
Gitでチーム開発をする上で、ブランチの作成・切り替え・リモートへのプッシュ・削除は、毎日のように使う基本操作です。しかし、git branchとgit checkout -bの違いや、-dと-Dの違いなど、「なんとなく」で使っていて、いざ聞かれると説明に詰まるという方も多いのではないでしょうか。
この記事では、ブランチの作成方法を複数のコマンドで比較しながら解説し、リモートブランチとの関係、ブランチの安全な削除方法、よくあるトラブルとその対処法まで一通り整理します。さらに、Git 2.23で導入された新しいコマンドgit switch / git restoreへの移行状況や、Claude Codeを使ったブランチ運用のベストプラクティスまで、2026年現在の実務目線で紹介します。
代表菅澤
AI鬼管理山崎
01 OVERVIEW ブランチとは何か 作業履歴を分岐させて、安全に並行開発するための仕組み
ブランチ（branch）とは、Gitにおいて作業の履歴を分岐させる仕組みです。プロジェクトの本流（多くの場合mainやmasterという名前のブランチ）から分かれて、独立した作業ラインを作ることで、他の人の作業に影響を与えずに新機能の開発やバグ修正を進められます。
📚 用語解説
コミット（commit）：ファイルの変更内容を記録する、Gitにおける最小の履歴の単位。ブランチは、このコミットの連なりに対して付けられた「ラベル（ポインタ）」のようなもので、ブランチを作成しても新しいコミットが増えるわけではない。
ブランチを使わずに1本の履歴だけで開発を進めると、複数人が同時に作業した際に変更が競合しやすく、また「動作確認前の未完成な変更」が本番相当のコードに混ざり込むリスクが高まります。ブランチを適切に分けることで、こうしたリスクを構造的に減らせます。
本流の
ブランチ
機能追加用の
ブランチを作成
分岐先で
独立して開発
レビュー後に
マージ
02 CREATE BRANCH ブランチの作成方法 3つのコマンドを比較しながら理解する
2-1. git branchコマンドで作成する（切り替えは別途必要）
git branch feature-login
# 現在のブランチを確認（*が付いているのが現在地）
git branch
# * main
# feature-login ← 作成はされたが、まだ移動していないgit branch [ブランチ名]は、新しいブランチという「ラベル」を作るだけで、作業対象を切り替えるところまでは行いません。作成後もカレントブランチは元のまま（多くの場合main）です。切り替えるには、後述のgit checkoutやgit switchが別途必要です。
2-2. git checkout -b：作成と切り替えを1コマンドで行う
git checkout -b feature-login
# 実行すると自動的にfeature-loginブランチに切り替わる
git branch
# main
# * feature-login ← すでに切り替わっているgit checkout -b [ブランチ名]は、ブランチの作成と切り替えを1回のコマンドで行うため、実務では最もよく使われてきた書き方です。
2-3. git switch -c：Git 2.23で導入された新しいコマンド
2019年にリリースされたGit 2.23以降では、git checkoutが「ブランチの切り替え」と「ファイルの変更取り消し」という2つの異なる役割を1つのコマンドが担っていて分かりにくいという課題を解消するため、役割ごとにgit switch（ブランチ操作用）とgit restore（ファイル復元用）に分割されました。
# 新しいブランチを作成して切り替える（checkout -b と同等）
git switch -c feature-login
# 既存のブランチに切り替える（checkout と同等）
git switch main📚 用語解説
git switch / git restore：Git 2.23（2019年リリース）で導入された比較的新しいコマンド。従来git checkoutが担っていた「ブランチの切り替え」をgit switchが、「ファイルの変更を取り消す」役割をgit restoreが、それぞれ専任で担当する。checkoutは現在も使用可能で廃止はされていないが、意図が明確になるという理由でswitch/restoreへの移行を推奨するチームも増えている。
| コマンド | 新規作成 | 切り替え | 導入時期 | 備考 |
|---|---|---|---|---|
| git branch [name] | ◯ | ×（別途必要） | 初期からある基本コマンド | ラベルを作るだけ |
| git checkout -b [name] | ◯ | ◯（同時に実行） | 初期からある基本コマンド | 広く使われてきた定番 |
| git switch -c [name] | ◯ | ◯（同時に実行） | Git 2.23（2019年〜） | 役割が明確、比較的新しい |
checkoutとswitch、どちらも現役で使えるコマンドです。既存プロジェクトが慣習的にcheckoutを使っているならそれに合わせ、新規プロジェクトやチームで統一する余地があるなら、役割が明確なswitch/restoreを採用するという判断で問題ありません。
AI鬼管理山崎
2-4. ブランチ名の付け方の慣習
ブランチ名そのものに厳密なルールはありませんが、チーム開発では「何のための変更か」がひと目で分かる命名規則を採用しているケースがほとんどです。よく使われるプレフィックス（接頭辞）を紹介します。
| プレフィックス例 | 用途 |
|---|---|
| feature/xxx | 新機能の追加 |
| fix/xxx | バグ修正 |
| hotfix/xxx | 本番環境で緊急対応が必要な修正 |
| refactor/xxx | 動作を変えないコードの整理・改善 |
| chore/xxx | ビルド設定や依存パッケージ更新など、機能に直結しない作業 |
こうした命名規則を統一しておくと、git branch -aで一覧を眺めただけで「今どんな作業が進行中か」を大まかに把握できるようになり、特にリモートリポジトリを複数人で共有するプロジェクトほど効果を発揮します。
03 FROM REMOTE リモートブランチを元にしたブランチ作成 チーム開発で他の人が作ったブランチを取得する
チーム開発では、すでにリモートリポジトリに存在するブランチを元に、自分のローカル環境でも作業したいケースがよくあります。
# リモートの最新情報を取得
git fetch origin
# リモートブランチを元にローカルブランチを作成して切り替える
git switch -c feature-login origin/feature-login
# 上記はcheckoutでも同様に書ける
git checkout -b feature-login origin/feature-login📚 用語解説
リモート追跡ブランチ（remote-tracking branch）：リモートリポジトリ（originなど）上のブランチの状態を、ローカル環境に写し取った参照情報。origin/feature-loginのような形式で表示され、実体としてローカルにコミットが複製されているが、直接編集するためのブランチではない。このリモート追跡ブランチを元に、自分が実際に作業するローカルブランチを作成する。
リモート追跡ブランチと同じ名前でローカルブランチを作成した場合、多くのGitクライアントやコマンドは自動的に「追跡関係（upstream）」を設定してくれるため、以後はgit pull / git pushを引数なしで実行できるようになります。
リモートにしか存在しないブランチ名をそのままgit checkout feature-loginやgit switch feature-loginと打つと、Gitが「同名のリモート追跡ブランチが1つだけ存在する」と判断できる場合、自動的に同名のローカルブランチを作成して追跡設定までしてくれます。
代表菅澤
04 LIST & SWITCH ブランチの一覧確認・切り替え 今どのブランチにいるかを常に把握する
| コマンド | 表示される内容 |
|---|---|
| git branch | ローカルブランチの一覧 |
| git branch -r | リモート追跡ブランチの一覧 |
| git branch -a | ローカル・リモート追跡ブランチの両方 |
| git branch -v | ブランチごとの最新コミット情報付きで一覧表示 |
git branch -a
# main
# * feature-login
# remotes/origin/main
# remotes/origin/feature-login
# remotes/origin/feature-paymentブランチの切り替えは、git checkout [ブランチ名]またはgit switch [ブランチ名]で行います。切り替え先にコミットされていない変更（作業ツリーの差分）が残っていると、変更内容によっては切り替えがブロックされることがあります。
作業途中の変更がある状態でブランチを切り替えようとすると、変更が失われる可能性がある場合はGitがエラーで止めてくれますが、変更内容によっては警告なく持ち越されてしまうこともあります。切り替え前にはgit statusで状態を確認するか、git stashで一時退避してから移動する習慣をつけると安全です。
📚 用語解説
git stash：現在の作業ツリーの変更を、コミットせずに一時的に退避させるコマンド。ブランチを切り替えたいが、まだコミットするほどまとまっていない変更がある場合に使う。git stashで退避し、git stash popで元に戻せる。
4-1. 直前のブランチにワンタッチで戻る
# 1つ前にいたブランチへ切り替える
git switch -
# checkoutでも同様の書き方ができる
git checkout -git switch -（ハイフン1つ）は、直前にいたブランチへワンタッチで戻るショートカットです。「mainで内容を確認してから、また元の作業ブランチに戻る」といった往復作業が頻繁に発生する場面で重宝します。
4-2. ブランチの分岐状況を視覚的に確認する
git log --oneline --graph --allコマンドラインでも、git log --oneline --graph --allを実行すると、どのブランチがどこから分岐し、どこで合流したかをテキストベースのグラフで確認できます。GUIツールを使わない場合でも、まずこのコマンドで全体像を把握してから作業する習慣をつけると、混乱を減らせます。
AI鬼管理山崎
05 PUSH TO REMOTE リモートへのプッシュ -uオプションが持つ本当の意味
ローカルで作成したブランチを、チームメンバーと共有するためにリモートリポジトリへアップロードする操作がプッシュ（push）です。
git push -u origin feature-login| 要素 | 意味 |
|---|---|
| git push | リモートへ変更を送信するコマンド |
| origin | リモートリポジトリの名前（クローン時に自動設定される既定名） |
| feature-login | 送信先のブランチ名 |
| -u（--set-upstream） | ローカルブランチとリモートブランチの追跡関係を設定するオプション |
-uオプションを付けて一度プッシュしておくと、2回目以降は引数なしのgit push・git pullだけで同じリモートブランチとやり取りできるようになります。これは、ローカルブランチに対して「このリモートブランチと対応しています」という追跡設定（upstream）が記録されるためです。
# 1回目: -uで追跡設定をしながらプッシュ
git push -u origin feature-login
# 2回目以降: 追跡設定済みなので引数省略でOK
git push
git pull-uを付けずにプッシュした場合でもリモートへの送信自体は成功しますが、追跡関係が設定されないため、次回以降も毎回git push origin feature-loginのようにブランチ名を明示する必要があります。忘れがちな操作なので、新しいブランチの初回プッシュ時は必ず-uを付ける習慣をつけましょう。
代表菅澤
06 DELETE BRANCH ブランチの削除 ローカル・リモートそれぞれの削除方法と-d/-Dの違い
6-1. ローカルブランチの削除：-dと-Dの違い
| コマンド | 意味 | 安全性 |
|---|---|---|
| git branch -d [ブランチ名] | 安全な削除。マージ済みのブランチのみ削除できる | 未マージの変更がある場合はエラーで削除を拒否してくれる |
| git branch -D [ブランチ名] | 強制削除。マージ済みかどうかに関わらず削除する | 未マージの変更ごと消えるため注意が必要 |
# 安全な削除（マージ済みでない場合はエラーになる）
git branch -d feature-login
# 強制削除（マージ済みでなくても削除される）
git branch -D feature-login-D（大文字）は、そのブランチにしか存在しないコミット（他のブランチにマージされていない変更）ごと削除してしまいます。一度削除すると、コミットのハッシュ値が分かっていない限り復元は困難です。基本は-d（小文字）を使い、エラーが出た場合に「本当に不要か」を確認した上で-Dに切り替えるという順序を徹底しましょう。
📚 用語解説
マージ（merge）：別のブランチで行った変更を、現在のブランチに取り込む操作のこと。git branch -dは「そのブランチの変更が、現在のブランチ（多くはmainなど）にすでにマージされているか」を判定基準にしており、マージ済みでない場合は安全のため削除を拒否する。
6-2. リモートブランチの削除
git push origin --delete feature-loginリモートブランチの削除は、ローカルブランチの削除とは別のコマンドです。ローカルでgit branch -dを実行しても、リモート側のブランチはそのまま残ります。
6-3. 削除されたリモートブランチをローカルの表示からも消す
git fetch --prune
# または短縮形
git fetch -p📚 用語解説
git fetch --prune（-p）：リモート側ですでに削除されたブランチに対応する「リモート追跡ブランチ」を、ローカル環境からも削除するオプション。他のメンバーがリモートブランチを削除しても、自分のローカル環境のgit branch -aには古い情報が残り続けることがあり、これを解消するために使う。
git branch -d
（マージ済みのみ）
git push origin
--delete
git fetch --prune
で最新化
07 TROUBLESHOOTING よくあるトラブルと対処法 初心者が最初につまずきやすい5つの場面
7-1. コミットしていない変更があって切り替えられない
「error: Your local changes to the following files would be overwritten by checkout」というエラーは、コミットされていない変更が、切り替え先のブランチの内容と衝突するために発生します。git stashで一時退避するか、変更をコミットしてから切り替えましょう。
7-2. detached HEAD状態になってしまう
ブランチ名ではなく特定のコミットのハッシュ値やタグを直接チェックアウトすると、「detached HEAD（HEADが分離した状態）」になります。この状態でコミットをしても、どのブランチにも属さない孤立したコミットになり、他のブランチに切り替えると変更を見失う可能性があります。
📚 用語解説
detached HEAD：HEAD（現在の作業位置を示すポインタ）が、ブランチではなく特定のコミットを直接指している状態。この状態で新しいコミットを作ると、ブランチに属さない孤立したコミットになりやすく、他のブランチへ切り替えた際に見失われる可能性がある。作業を続ける場合は、detached HEADの状態から新しいブランチを作成（git switch -c 新ブランチ名）して退避させるのが安全。
7-3. プッシュしようとしたら拒否される（rejected）
「! [rejected] ... (fetch first)」というエラーは、リモート側に自分のローカルにはない新しいコミットが存在するため発生します。git pull（またはgit fetch + git merge/rebase）で最新の状態を取り込んでから、改めてプッシュします。
7-4. ブランチ名を間違えて作成してしまった
# ブランチ名を変更する（現在のブランチをリネーム）
git branch -m 新しいブランチ名
# 別のブランチを指定してリネームする場合
git branch -m 古いブランチ名 新しいブランチ名7-5. どのブランチで作業しているか分からなくなる
ターミナルのプロンプトに現在のブランチ名を常時表示するよう設定しておくと、「気づかないうちに違うブランチで作業していた」という事故を防げます。多くのシェル設定用フレームワークやターミナルアプリに、この機能が標準またはプラグインとして用意されています。
代表菅澤
7-6. ブランチを長期間放置してmainと乖離してしまう
作成したブランチを長期間マージせずに放置すると、その間にmainブランチが更新され続け、ブランチ同士の差分がどんどん大きくなっていきます。差分が大きいほど、後からマージする際のコンフリクト（変更内容の衝突）が発生しやすく、解消にも時間がかかるようになります。
git merge mainやgit rebase mainで最新の変更を取り込んでおく📚 用語解説
コンフリクト（conflict）：複数のブランチで同じ箇所に異なる変更が加えられ、マージ時にGitがどちらを採用すべきか自動で判断できない状態のこと。手動でどちらの変更を残すか（または両方を組み合わせるか）を編集して解消する必要がある。ブランチの生存期間が長く、差分が大きいほど発生しやすくなる。
08 AI-ASSISTED WORKFLOW 【独自】Claude Codeを使った安全なブランチ運用 AIエージェントに変更を任せるときの設計判断
Claude CodeのようなAIコーディングアシスタントにコードの変更を任せる機会が増えてくると、「AIが行った変更をどう管理するか」という新しいブランチ運用の論点が出てきます。
基本的な考え方は、人間同士のチーム開発と同じです。AIに作業を依頼する前に、専用のブランチを切っておくことで、変更内容を安全にレビューし、問題があればそのブランチごと破棄してmainブランチへの影響をゼロに保てます。
| 運用パターン | メリット | 注意点 |
|---|---|---|
| mainブランチで直接AIに作業させる | 手順がシンプル | 想定外の変更が本流に混ざるリスクがある |
| 作業ごとに専用ブランチを切ってからAIに依頼する | 変更範囲が明確、レビュー・ロールバックが容易 | ブランチの作成・切り替えという一手間が増える |
| AIに複数タスクを1ブランチで並行させる | 手軽だが変更の切り分けが難しくなる | レビュー時にどの変更がどのタスクのものか分かりにくい |
タスクごとに
専用ブランチを作成
Claude Codeに
作業を依頼
git diffで
変更内容をレビュー
問題なければ
マージ、NGなら破棄
1つのブランチに複数の目的が混ざった変更を任せてしまうと、後から「この変更のうち、どこまでを採用してどこを差し戻すか」の判断が難しくなります。AIに依頼するタスクは、可能な限り1ブランチ・1目的に分解しておくと、レビューの負担が大きく下がります。
AI鬼管理山崎
09 GENAI CASE STUDY 【独自データ】GENAI社内でのgit・Claude Code運用実例 Claude Max 20xプランでの開発・LP制作の実態
弊社（株式会社GENAI）では、Claude Max 20xプラン（月額$200・約30,000円）を契約し、営業・広告運用・記事制作・経理・秘書業務に加えて、Webサイト・LPの開発・保守にもClaude Codeを活用しています。
| 作業内容 | 運用ルール |
|---|---|
| 新しいLPの追加 | 専用ブランチを作成してからClaude Codeに実装を依頼 |
| 既存サイトの軽微な修正 | 影響範囲が小さい場合のみ、確認の上でmain相当に直接反映することもある |
| 複数ページにまたがる大きな改修 | ページ単位・機能単位でブランチを分け、個別にレビュー |
この記事で紹介したブランチの基本操作は、AIを活用した開発フローにおいても変更の安全性を担保する土台になっています。「AIに任せているから細かい部分は気にしなくていい」ではなく、むしろ「AIに任せるからこそ、変更の区切り方を人間が設計する」という意識が重要だと感じています。
例えば、あるLPのCTA文言だけを差し替えたい場合と、フォームの入力項目そのものを追加したい場合とでは、影響範囲がまったく異なります。弊社では前者のような小さな変更は都度ブランチを切らずに素早く反映することもありますが、後者のようにフォームの挙動やデータ送信先に関わる変更は、必ず専用ブランチを切ってから作業し、動作確認を経てから本番相当の環境へ反映するというルールを徹底しています。
運用ルールは案件の重要度・規模によって調整しています。あくまで弊社での実践例としてご覧ください。
代表菅澤
10 CONCLUSION まとめ ブランチ操作の基本を正しく理解する
git fetchしてからswitch -c [名前] origin/[名前]git push origin --delete、表示の同期はgit fetch --pruneGitのブランチ操作は、コマンド自体はシンプルですが、リモートとの追跡関係や削除時の安全性など、仕組みを理解しているかどうかで実務でのトラブル対応力に大きな差が出ます。AIコーディングアシスタントの活用が広がる今、変更を安全に区切って管理するというブランチ運用の基本は、以前にも増して重要になっています。
弊社では、こうした開発の基礎的な運用設計から、Claude Codeを活用した業務効率化の伴走支援まで行っています。「AIに開発を任せる際の安全な運用ルールを整えたい」という方は、ぜひ一度ご相談ください。
Claude Codeを使った開発・業務自動化の運用設計も、AI鬼管理が伴走します
ブランチ運用のような基礎的なルール整備が、AI活用の安全性を大きく左右します。
AI鬼管理では、Claude Codeを活用した開発フローの設計から、社内への定着支援まで対応しています。
AI鬼管理山崎
ここから先の進め方は、大きく2つあります。
自社で回せるようになりたい方は、AI鬼管理でClaude Code／Codexの使い方から業務設計・社内定着まで伴走を受けながら、社内に仕組みを作る道があります。
覚えるより任せたい方は、AI社員AIKATAでこの記事のような定型業務を丸ごと預ける道があります。料金は月30万円の月額定額、追加費用は0円です。
どちらが合うかは、業務量と社内体制次第です。無料相談・無料適合診断で、貴社の場合はどちらが向くかからご相談いただけます。
NEXT STEP
この記事の内容を、あなたのビジネスで
実践してみませんか？
よくある質問
Q. git branchとgit checkout -bの違いは何ですか？
A. git branch [名前]は新しいブランチを作成するだけで、作業対象は元のブランチのままです。一方git checkout -b [名前]は、ブランチの作成と、そのブランチへの切り替えを1コマンドで同時に行います。実務では後者がよく使われます。
Q. git switchとgit checkoutはどちらを使うべきですか？
A. どちらも現役で使用できます。git switchはGit 2.23（2019年）で導入された比較的新しいコマンドで、ブランチ操作の役割に特化しているため意図が明確という利点があります。既存プロジェクトの慣習に合わせつつ、新規プロジェクトではswitch/restoreへの移行を検討する価値があります。
Q. git branch -dで削除できないのはなぜですか？
A. -d（小文字）は安全のため、そのブランチの変更がまだ他のブランチにマージされていない場合、削除を拒否する仕様になっています。エラーが出た場合は、本当に削除して問題ないかを確認した上で、強制削除の-D（大文字）を使うかどうか判断してください。
Q. リモートブランチを削除してもローカルの一覧に残っているのはなぜですか？
A. リモート側の削除と、ローカル環境が持つ「リモート追跡ブランチ」の情報は別物だからです。他のメンバーがリモートブランチを削除しても、自分のローカル環境には古い追跡情報が残り続けます。git fetch --pruneを実行することで、削除済みの情報をローカルからも同期して消せます。
Q. push -uを忘れた場合はどうすればいいですか？
A. プッシュ自体は成功しているので、後から改めて`git push -u origin ブランチ名`を実行すれば追跡関係を設定できます。一度設定すれば、以降は引数なしのgit push/git pullが使えるようになります。
Q. Claude Codeなど、AIに開発を任せる場合もブランチを分けるべきですか？
A. 分けることを推奨します。専用ブランチで作業を任せることで、変更内容をgit diffなどで安全にレビューでき、問題があった場合もそのブランチを破棄するだけでmainブランチへの影響をゼロに抑えられます。人間同士のチーム開発と同じ考え方がそのまま活きる場面であり、タスクを小さく分割してブランチも合わせて分けておくほど、後から見返したときに「どの変更が何のためのものか」を追いやすくなります。
Q. ブランチはどのくらいの頻度でmainにマージすべきですか？
A. 目安として、数日以内に完結する単位でこまめにマージするのが理想です。ブランチの生存期間が長くなるほどmainとの差分が大きくなり、マージ時のコンフリクト解消に余計な時間がかかります。大きな機能追加であっても、可能な範囲でタスクを分割し、小さなブランチを積み重ねる方が結果的にトラブルを減らせます。
Claude Codeで業務自動化を90日で叩き込む
経営者向けの伴走型パーソナルトレーニング
AI鬼管理／AI社員AIKATAへのお問い合わせ
この記事を読んで気になった方へ。
専門スタッフが、御社に最適な
業務自動化・業務代行プランを無料でご提案します。
- AI業務自動化サービス「AI鬼管理」を運営 — Claude Code を活用し、経営者の業務を「AIエージェントに任せる仕組み」へ転換するパーソナルトレーニングを 伴走構築 で提供。日報・採用・問い合わせ対応・経費精算・議事録・データ集計・営業リスト等の定型業務を、AIに代行させる体制を経営者と一緒に作り込む
- Claude Code 実装ノウハウを 経営者・法人クライアント に直接指導。生成AIを「便利ツール」ではなく 「業務を任せる存在」 として運用する手法を体系化
- 「やらせ切る管理」メソッドの開発者。シンゲキ株式会社（2021年設立・鬼管理専門塾運営）にて累計3,000名以上の学習者を志望校合格に導いた管理メソッドを、AI × 経営者支援 に転用
- 著書『3カ月で志望大学に合格できる鬼管理』(幻冬舎)、『親の過干渉こそ、最強の大学受験対策である。』(講談社)
- メディア出演: REAL VALUE / カンニング竹山のイチバン研究所 / ええじゃないかBiz 他
- 明治大学政治経済学部卒
