日本語 ▾ トピック ▾ 最新バージョン ▾ git-switch は 2.44.0 で最終更新されました

名前

git-switch - ブランチを切り替える

概要

git switch [<options>] [--no-guess] <branch>
git switch [<options>] --detach [<start-point>]
git switch [<options>] (-c|-C) <new-branch> [<start-point>]
git switch [<options>] --orphan <new-branch>

説明

指定されたブランチに切り替えます。作業ツリーとインデックスはブランチに合わせて更新されます。すべての新しいコミットはこのブランチの先端に追加されます。

オプションとして、`-c`、`-C` を使用するか、同じ名前のリモートブランチから自動的に（`--guess` を参照）、または`--detach` で作業ツリーを任意のブランチからデタッチして、新しいブランチを作成できます。

ブランチの切り替えにクリーンなインデックスと作業ツリー（つまり、`HEAD`との違いがない状態）は必要ありません。ただし、`--discard-changes`または`--merge`で指示しない限り、ローカルの変更が失われる操作の場合、処理は中止されます。

このコマンドは実験的です。動作が変更される可能性があります。

オプション

<ブランチ>

切り替えるブランチ。

<新しいブランチ>

新しいブランチの名前。

<開始点>

新しいブランチの開始点。`<開始点>` を指定することで、HEADが現在指している場所とは異なる履歴の時点に基づいてブランチを作成できます。（または、`--detach` の場合は、別の時点を検査し、そこからデタッチできます。）

`@{-N}` 構文を使用して、「git switch」または「git checkout」操作で切り替えたN番目に前のブランチ/コミットを参照できます。また、`@{-1}` の同義語である `-` を指定することもできます。これは、2つのブランチ間を素早く切り替えたり、誤って行ったブランチ切り替えを元に戻したりするためによく使用されます。

特別なケースとして、マージベースが1つだけの場合、`A...B` を `A` と `B` のマージベースのショートカットとして使用できます。`A` と `B` のうち最大1つを省略でき、その場合はデフォルトで `HEAD` になります。

-c <新しいブランチ>
--create <新しいブランチ>

`<新しいブランチ>` という名前の新しいブランチを `<開始点>` から作成し、そのブランチに切り替えます。これは、以下と同等のトランザクション操作です。

$ git branch <new-branch>
$ git switch <new-branch>

つまり、「git switch」が成功しない限り（例えば、ブランチが別の作業ツリーで使用されている場合など）、ブランチはリセット/作成されません。現在のブランチが同じままであるだけでなく、ブランチも開始点にリセットされません。

-C <新しいブランチ>
--force-create <新しいブランチ>

`--create` と似ていますが、`<新しいブランチ>` がすでに存在する場合、`<開始点>` にリセットされます。これは、以下の便利なショートカットです。

$ git branch -f <new-branch>
$ git switch <new-branch>
-d
--detach

検査および破棄可能な実験のためにコミットに切り替えます。詳細については、git-checkout[1] の「DETACHED HEAD」セクションを参照してください。

--guess
--no-guess

もし `<ブランチ>` が見つからないが、ちょうど1つのリモート（それを `<リモート>` と呼ぶ）に一致する名前の追跡ブランチが存在する場合、以下と同等に扱われます。

$ git switch -c <branch> --track <remote>/<branch>

ブランチが複数のリモートに存在し、そのうちの1つが `checkout.defaultRemote` 設定変数で指定されている場合、`<ブランチ>` がすべてのリモートで一意でなくても、あいまいさを解消するためにそのリモートを使用します。例えば、`checkout.defaultRemote=origin` に設定すると、`<ブランチ>` があいまいでも *origin* リモートに存在する場合、常にそこからリモートブランチをチェックアウトするようになります。git-config[1] の `checkout.defaultRemote` も参照してください。

`--guess` がデフォルトの動作です。無効にするには `--no-guess` を使用します。

デフォルトの動作は `checkout.guess` 設定変数で設定できます。

-f
--force

`--discard-changes` のエイリアスです。

--discard-changes

インデックスまたは作業ツリーが `HEAD` と異なっていても処理を続行します。インデックスと作業ツリーの両方が切り替えターゲットと一致するように復元されます。`--recurse-submodules` が指定された場合、サブモジュールの内容も切り替えターゲットと一致するように復元されます。これはローカルの変更を破棄するために使用されます。

-m
--merge

現在のブランチと切り替え先のブランチ間で異なるファイルにローカルの変更がある場合、コマンドは変更をコンテキスト内に保持するためにブランチの切り替えを拒否します。ただし、このオプションを使用すると、現在のブランチ、作業ツリーの内容、新しいブランチの間で3-wayマージが行われ、新しいブランチに移動します。

マージコンフリクトが発生した場合、競合するパスのインデックスエントリーは未マージのまま残され、コンフリクトを解決し、解決済みのパスを `git add` (または、マージがパスの削除をもたらす場合は `git rm`) でマークする必要があります。

--conflict=<スタイル>

上記の `--merge` オプションと同じですが、競合するハンクの表示方法を変更し、`merge.conflictStyle` 設定変数をオーバーライドします。可能な値は「merge」（デフォルト）、「diff3」、「zdiff3」です。

-q
--quiet

静かに、フィードバックメッセージを抑制します。

--progress
--no-progress

ターミナルに接続されている場合、デフォルトで標準エラー出力ストリームに進捗状況が報告されます（`--quiet` が指定されていない限り）。このフラグは、ターミナルに接続されていない場合でも、`--quiet` の有無にかかわらず進捗報告を有効にします。

-t
--track [direct|inherit]

新しいブランチを作成する際、「upstream」設定をセットアップします。`-c` は暗黙的に含まれます。詳細については、git-branch[1] の `--track` を参照してください。

`-c` オプションが指定されていない場合、新しいブランチの名前は、対応するリモート用に設定されたrefspecのローカル部分を見て、先頭の「*」までの部分を削除することで、リモート追跡ブランチから派生します。これにより、`origin/hack`（または`remotes/origin/hack`、あるいは`refs/remotes/origin/hack`）からブランチを作成する際に、`hack` をローカルブランチとして使用するようになります。指定された名前にスラッシュがない場合、または上記の推測によって空の名前になった場合、推測は中止されます。そのような場合は、`-c` で明示的に名前を指定できます。

--no-track

`branch.autoSetupMerge` 設定変数がtrueであっても、「upstream」設定をセットアップしません。

--orphan <新しいブランチ>

`<新しいブランチ>` という名前の新しいアンボーンブランチを作成します。追跡されているすべてのファイルは削除されます。

--ignore-other-worktrees

目的のrefがすでに別のワークツリーによってチェックアウトされている場合、`git switch` は拒否します。このオプションを使用すると、それでもrefをチェックアウトします。つまり、refは複数のワークツリーによって保持される可能性があります。

--recurse-submodules
--no-recurse-submodules

`--recurse-submodules` を使用すると、すべてのアクティブなサブモジュールの内容がスーパープロジェクトに記録されたコミットに従って更新されます。何も指定しない（または `--no-recurse-submodules` を使用する）場合、サブモジュールの作業ツリーは更新されません。git-submodule[1] と同様に、これによりサブモジュールの `HEAD` はデタッチされます。

例

以下のコマンドは「master」ブランチに切り替えます

$ git switch master

間違ったブランチで作業した後、正しいブランチに切り替えるには次のようにします。

$ git switch mytopic

ただし、ローカルで変更したファイルに関して、あなたの「間違った」ブランチと正しい「mytopic」ブランチが異なる場合があります。その場合、上記の切り替えは次のように失敗します。

$ git switch mytopic
error: You have local changes to 'frotz'; not switching branches.

コマンドに `-m` フラグを指定すると、3-wayマージを試行します。

$ git switch -m mytopic
Auto-merging frotz

この3-wayマージ後も、ローカルの変更はインデックスファイルに登録されないため、`git diff` を実行すると、新しいブランチの先端から行った変更が表示されます。

mytopic に切り替える前の前のブランチ（つまり「master」ブランチ）に戻るには

$ git switch -

任意のコミットから新しいブランチを作成できます。例えば、「HEAD~3」に切り替えて「fixup」ブランチを作成します。

$ git switch -c fixup HEAD~3
Switched to a new branch 'fixup'

同じ名前のリモートブランチから新しいブランチを開始したい場合

$ git switch new-topic
Branch 'new-topic' set up to track remote branch 'new-topic' from 'origin'
Switched to a new branch 'new-topic'

新しいブランチを作成せずに、一時的な検査または実験のためにコミット `HEAD~3` をチェックアウトするには

$ git switch --detach HEAD~3
HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'

行った作業が残す価値があると判明した場合、いつでも新しい名前を付けることができます（切り替えずに）。

$ git switch -c good-surprises

設定

このセクションのこの行より下の内容は、git-config[1] ドキュメントから選択的に含まれています。内容はそちらにあるものと同じです。

checkout.defaultRemote

`git checkout <何か>` または `git switch <何か>` を実行し、リモートが1つしかない場合、暗黙的に例えば `origin/<何か>` をチェックアウトして追跡するようフォールバックする可能性があります。`<何か>` 参照を持つリモートが複数あると、これは機能しなくなります。この設定により、あいまいさの解消の際に常に優先されるリモートの名前を設定できます。一般的な使用例としては、これを `origin` に設定することです。

現在、これは `git checkout <何か>` または `git switch <何か>` が別のリモート上の `<何か>` ブランチをチェックアウトする場合に git-switch[1] と git-checkout[1] で使用され、`git worktree add` がリモートブランチを参照する場合に git-worktree[1] で使用されます。この設定は、将来的には他のチェックアウトに類似するコマンドや機能にも使用される可能性があります。

checkout.guess

`git checkout` および `git switch` の `--guess` または `--no-guess` オプションのデフォルト値を提供します。git-switch[1] および git-checkout[1] を参照してください。

checkout.workers

作業ツリーを更新する際に使用する並行ワーカーの数。デフォルトは1、つまり順次実行です。1未満の値に設定すると、Gitは利用可能な論理コアの数と同じ数のワーカーを使用します。この設定と `checkout.thresholdForParallelism` は、チェックアウトを実行するすべてのコマンド（例: checkout、clone、reset、sparse-checkoutなど）に影響します。

注記: 並行チェックアウトは、SSD上またはNFS経由で配置されたリポジトリの場合、通常、より良いパフォーマンスを発揮します。スピニングディスク上またはコア数が少ないマシン上のリポジトリの場合、デフォルトの順次チェックアウトの方がパフォーマンスが良いことがよくあります。リポジトリのサイズと圧縮レベルも、並行バージョンのパフォーマンスに影響を与える可能性があります。

checkout.thresholdForParallelism

少数のファイルで並行チェックアウトを実行する場合、サブプロセス生成とプロセス間通信のコストが並列化による利点を上回る可能性があります。この設定により、並行チェックアウトを試みるべき最小ファイル数を定義できます。デフォルトは100です。

関連項目

git-checkout[1], git-branch[1]

GIT

git[1] スイートの一部

scroll-to-top