日本語 ▾ トピック ▾ 最新バージョン ▾ git-switch は 2.50.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 で指定しない限り、操作は中止されます。

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

オプション

<branch>

切り替えるブランチ。

<new-branch>

新しいブランチの名前。

<start-point>

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

@{-<N>} 構文を使用すると、git switch または git checkout 操作を使用して切り替えた <N> 番目の最新のブランチ/コミットを参照できます。- も指定でき、これは @{-1} と同義です。これは、2つのブランチ間を素早く切り替えたり、間違ってブランチを切り替えてしまった場合に元に戻したりするのに頻繁に使用されます。

特殊なケースとして、<rev-a> と <rev-b> の間にマージベースが正確に1つだけある場合、<rev-a>...<rev-b> をマージベースのショートカットとして使用できます。<rev-a> と <rev-b> のうち、多くとも1つを省略でき、その場合は HEAD がデフォルトになります。

-c <new-branch>
--create <new-branch>

<start-point> から始まる <new-branch> という名前の新しいブランチを作成してから、そのブランチに切り替えます。これは、次のトランザクションと等価です。

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

つまり、git switch が成功しない限り (例: ブランチが別のワークツリーで使用されている場合、現在のブランチは同じままであるだけでなく、ブランチは開始点にリセットされません)、ブランチはリセット/作成されません。

-C <new-branch>
--force-create <new-branch>

--create と似ていますが、<new-branch> が既に存在する場合、<start-point> にリセットされます。これは、次の便利なショートカットです。

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

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

--guess
--no-guess

<branch> が見つからないが、正確に1つのリモート (これを <remote> と呼ぶ) に同じ名前の追跡ブランチが存在する場合、次と同等に扱います。

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

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

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

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

-f
--force

--discard-changes のエイリアス。

--discard-changes

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

-m
--merge

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

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

--conflict=<style>

上記の --merge オプションと同じですが、競合するハンクの表示方法を変更し、merge.conflictStyle 設定変数を上書きします。可能な値は merge (デフォルト)、diff3、および zdiff3 です。

-q
--quiet

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

--progress
--no-progress

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

-t
--track[ (direct|inherit)]

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

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

--no-track

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

--orphan <new-branch>

<new-branch> という名前の新しい孤立ブランチを作成します。すべての追跡されているファイルは削除されます。

--ignore-other-worktrees

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

--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方向マージを試行します。

$ git switch -m mytopic
Auto-merging frotz

この3方向マージの後、ローカルの変更はインデックスファイルに登録されません。したがって、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 <something> または git switch <something> を実行し、リモートが1つしかない場合、暗黙的に例えば origin/<something> のチェックアウトと追跡にフォールバックすることがあります。これは、<something> 参照を持つリモートが複数あるとすぐに機能しなくなります。この設定により、曖昧さの解消に関して常に優先されるべき、推奨されるリモートの名前を設定できます。典型的なユースケースは、これを origin に設定することです。

現在、これは git checkout <something> または git switch <something> が別のリモートの <something> ブランチをチェックアウトする場合に 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