git-switch

Название

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>

Начальная точка новой ветки. Указание <start-point> позволяет создать ветку на основе другой точки истории, а не той, на которую сейчас указывает HEAD. (Или, в случае --detach, позволяет просмотреть другую точку и отсоединиться от неё.)

Для ссылки на ветку или коммит, на который переключались <N> последним, можно использовать синтаксис @{-<N>} при выполнении операции git switch или git checkout. Также можно указать -, что является синонимом @{-1}. Это часто используется для быстрого переключения между двумя ветками или для отмены ошибочного переключения ветки.

В особом случае можно использовать <rev-a>...<rev-b> как сокращённую запись для базового коммита слияния <rev-a> и <rev-b>, если такая база ровно одна. Можно опустить не более одного из значений <rev-a> и <rev-b>; в этом случае по умолчанию используется HEAD.

-c <new-branch>

--create <new-branch>

Создать новую ветку с именем <new-branch>, начинающуюся с <start-point>, и переключиться на неё. Это транзакционный эквивалент команды

$ 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

Переключиться на коммит для просмотра и экспериментов, которые можно отбросить. Подробности см. в разделе «DETACHED HEAD» документации git-checkout[1].

--guess

--no-guess

Если <branch> не найдена, но на единственном удалённом репозитории (назовём его <remote>) есть одноимённая отслеживаемая ветка, считать команду эквивалентной

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

Если ветка существует в нескольких удалённых репозиториях и один из них указан переменной конфигурации checkout.defaultRemote, для устранения неоднозначности будет использован именно он, даже если <branch> не уникальна среди всех удалённых репозиториев. Например, задайте значение checkout.defaultRemote=origin, чтобы всегда переключаться на удалённые ветки из этого репозитория, если <branch> неоднозначна, но существует в удалённом репозитории origin. См. также checkout.defaultRemote в документации git-config[1].

--guess — поведение по умолчанию. Используйте --no-guess, чтобы отключить его.

Поведение по умолчанию можно задать с помощью переменной конфигурации checkout.guess.

-f

--force

Синоним --discard-changes.

--discard-changes

Продолжить, даже если индекс или рабочее дерево отличаются от HEAD. Индекс и рабочее дерево будут восстановлены в соответствии с целевой веткой. Если указан параметр --recurse-submodules, содержимое подмодулей также будет восстановлено в соответствии с целевой веткой. Используется для отбрасывания локальных изменений.

-m

--merge

Если у вас есть локальные изменения в одном или нескольких файлах, отличающихся между текущей веткой и веткой, на которую вы переключаетесь, команда обычно отказывается переключать ветки, чтобы сохранить изменения в их контексте. Однако с этим параметром конфликтующие локальные изменения автоматически помещаются в stash перед переключением и применяются повторно после него. Если локальные изменения не пересекаются с различиями между ветками, переключение выполняется без помещения изменений в stash. Если повторное применение stash приводит к конфликтам, запись сохраняется в списке stash. Устраните конфликты и после завершения выполните git stash drop либо очистите рабочее дерево (например, с помощью git reset --hard), а затем выполните git stash pop, чтобы повторно применить изменения.

--conflict=<style>

То же, что и описанный выше параметр --merge, но изменяет способ представления конфликтующих фрагментов, переопределяя переменную конфигурации merge.conflictStyle. Возможные значения: merge (по умолчанию), diff3 и zdiff3.

-q

--quiet

Тихий режим: не выводить сообщения обратной связи.

--progress

--no-progress

По умолчанию сведения о ходе выполнения выводятся в стандартный поток ошибок, если он подключён к терминалу, если не указан параметр --quiet. Этот флаг включает вывод сведений о ходе выполнения, даже если поток не подключён к терминалу, независимо от --quiet.

-t

--track[ (direct|inherit)]

При создании новой ветки настроить конфигурацию «upstream». Предполагается -c. Подробности см. в --track документации git-branch[1].

Если параметр -c не указан, имя новой ветки определяется по ветке удалённого отслеживания: рассматривается локальная часть refspec, настроенного для соответствующего удалённого репозитория, а затем удаляется начальная часть до символа «*». Так команда определит, что локальную ветку следует назвать hack при создании на основе origin/hack (или remotes/origin/hack, или даже refs/remotes/origin/hack). Если указанное имя не содержит косой черты или результат такого определения оказывается пустым, попытка определить имя отменяется. В этом случае можно явно указать имя с помощью -c.

--no-track

Не настраивать конфигурацию «upstream», даже если переменная конфигурации 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, который перенесёт локальные изменения в новую ветку:

$ git switch -m mytopic
Applied autostash.
Switched to branch 'mytopic'
The following paths have local changes:
M        frotz

После переключения локальные изменения применяются повторно и not регистрируются в файле индекса, поэтому команда 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>, если у вас только один удалённый репозиторий, команда может неявно переключиться на ветку и начать отслеживать, например, origin/<something>. Это перестаёт работать, если у вас появляется более одного удалённого репозитория с ссылкой <something>. Эта настройка позволяет задать предпочтительный удалённый репозиторий, который всегда будет выбираться при устранении неоднозначности. Обычно в качестве него указывают origin.

Сейчас этот параметр используется командами git-switch[1] и git-checkout[1], когда git checkout <something> или git switch <something> извлекают ветку <something> из другого удалённого репозитория, а также командой git-worktree[1], когда git worktree add ссылается на удалённую ветку. В будущем эта настройка может использоваться и другими командами или функциями, работающими подобно checkout.

checkout.guess

Задаёт значение по умолчанию для параметра --guess или --no-guess в командах git checkout и git switch. См. git-switch[1] и git-checkout[1].

checkout.workers

Количество параллельных рабочих процессов для обновления рабочего дерева. По умолчанию используется один процесс, то есть выполнение происходит последовательно. Если задано значение меньше единицы, Git использует столько рабочих процессов, сколько доступно логических ядер. Эта настройка и checkout.thresholdForParallelism влияют на все команды, выполняющие checkout, например checkout, clone, reset, sparse-checkout и другие.

Примечание

Параллельный checkout обычно обеспечивает более высокую производительность для репозиториев на SSD или доступных по NFS. Для репозиториев на вращающихся дисках и/или компьютеров с небольшим числом ядер последовательный checkout, используемый по умолчанию, часто работает быстрее. На производительность параллельной версии также могут влиять размер репозитория и степень сжатия.

checkout.thresholdForParallelism

При выполнении параллельного checkout для небольшого числа файлов затраты на запуск подпроцессов и межпроцессное взаимодействие могут превысить выигрыш от параллельного выполнения. Эта настройка позволяет определить минимальное число файлов, при котором следует запускать параллельный checkout. По умолчанию используется значение 100.

См. также

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

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-switch