Русский ▾ Topics ▾ Latest version ▾ git-checkout last updated in 2.54.0

НАЗВАНИЕ

git-checkout - Переключение веток или восстановление файлов в рабочем каталоге

ОБЗОР

git checkout [-q] [-f] [-m] [<ветка>]
git checkout [-q] [-f] [-m] --detach [<ветка>]
git checkout [-q] [-f] [-m] [--detach] <коммит>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <новая-ветка>] [<начальная-точка>]
git checkout <указатель-дерева> [--] <спецификатор-пути>…​
git checkout <указатель-дерева> --pathspec-from-file=<файл> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<стиль>] [--] <спецификатор-пути>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<стиль>] --pathspec-from-file=<файл> [--pathspec-file-nul]
git checkout (-p|--patch) [<указатель-дерева>] [--] [<спецификатор-пути>…​]

ОПИСАНИЕ

git checkout имеет два основных режима:

  1. Переключение веток с помощью git checkout <ветка>

  2. Восстановление другой версии файла, например, с помощью git checkout <коммит> <имя-файла> или git checkout <имя-файла>

См. УСТРАНЕНИЕ НЕОДНОЗНАЧНОСТИ АРГУМЕНТОВ ниже о том, как Git решает, что именно делать.

git checkout [<ветка>]

Переключиться на <ветку>. Это устанавливает текущую ветку в <ветку> и обновляет файлы в вашем рабочем каталоге. Переключение завершится ошибкой, если есть незафиксированные изменения в любых файлах, где <ветка> и ваш текущий коммит имеют разное содержимое. В противном случае незафиксированные изменения будут сохранены.

Если <ветка> не найдена, но существует отслеживаемая ветка ровно в одном внешнем репозитории (назовём его <внешний-репозиторий>) с совпадающим именем и --no-guess не указан, обрабатывать как эквивалент

$ git checkout -b <ветка> --track <внешний-репозиторий>/<ветка>

Выполнение git checkout без указания ветки не имеет никакого эффекта, кроме вывода информации об отслеживании для текущей ветки.

git checkout -b <новая-ветка> [<начальная-точка>]

Создать новую ветку с именем <новая-ветка>, начать её в <начальной-точке> (по умолчанию текущий коммит) и переключить новую ветку. Вы можете использовать параметры --track или --no-track, чтобы установить информацию об отслеживании вышестоящей ветки.

Это завершится ошибкой, если возникнет ошибка при переключении <новой-ветки>, например, если переключение коммита <начальная-точка> перезапишет ваши незафиксированные изменения.

git checkout -B <ветка> [<начальная-точка>]

То же, что и -b, за исключением того, что если ветка уже существует, она сбрасывает <ветку> на начальную точку вместо того, чтобы завершаться ошибкой.

git checkout --detach [<ветка>]
git checkout [--detach] <коммит>

То же, что и git checkout <ветка>, за исключением того, что вместо указания HEAD на ветку, он указывает HEAD на идентификатор коммита. Подробнее см. раздел "ОТСОЕДИНЁННЫЙ HEAD" ниже.

Опускание <ветки> отсоединяет HEAD на верхушке текущей ветки.

git checkout <указатель-дерева> [--] <спецификатор-пути>...
git checkout <указатель-дерева> --pathspec-from-file=<файл> [--pathspec-file-nul]

Заменить указанные файлы и/или каталоги версией из данного коммита или дерева и добавить их в индекс (также известный как «область подготовки»).

Например, git checkout main file.txt заменит file.txt версией из main.

git checkout [-f|--ours|--theirs|-m|--conflict=<стиль>] [--] <спецификатор-пути>...
git checkout [-f|--ours|--theirs|-m|--conflict=<стиль>] --pathspec-from-file=<файл> [--pathspec-file-nul]

Заменить указанные файлы и/или каталоги версией из индекса.

Например, если вы переключили коммит, отредактировали file.txt, а затем решили, что эти изменения были ошибкой, git checkout file.txt отбросит любые неиндексированные изменения в file.txt.

Это завершится ошибкой, если файл имеет конфликт слияния и вы ещё не выполнили git add file.txt (или что-то эквивалентное), чтобы пометить его как разрешённый. Вы можете использовать -f, чтобы игнорировать не слитые файлы вместо того, чтобы завершаться ошибкой, использовать --ours или --theirs, чтобы заменить их версией с определённой стороны слияния, или использовать -m, чтобы заменить их исходным конфликтующим результатом слияния.

git checkout (-p|--patch) [<указатель-дерева>] [--] [<спецификатор-пути>...]

Это похоже на два предыдущих режима, но позволяет использовать интерактивный интерфейс для отображения вывода "diff" и выбора, какие части использовать в результате. См. ниже описание параметра --patch.

ПАРАМЕТРЫ

-q
--quiet

Тихий режим, подавлять информационные сообщения.

--progress
--no-progress

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

-f
--force

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

При переключении путей из индекса не завершаться ошибкой при не слитых записях; вместо этого не слитые записи игнорируются.

--ours
--theirs

При переключении путей из индекса переключать стадию №2 (ours) или №3 (theirs) для не слитых путей.

Обратите внимание, что во время git rebase и git pull --rebase ours и theirs могут поменяться местами; --ours даёт версию из ветки, на которую перемещаются изменения, в то время как --theirs даёт версию из ветки, содержащей вашу работу, которая перемещается.

Это связано с тем, что rebase используется в рабочем процессе, который рассматривает историю во внешнем репозитории как общую каноническую, а работу, проделанную в ветке, которую вы перемещаете, как стороннюю работу для интеграции, и вы временно принимаете на себя роль хранителя канонической истории во время перемещения. Как хранитель канонической истории, вы должны рассматривать историю из внешнего репозитория как ours (т.е. "нашу общую каноническую историю"), а то, что вы сделали в своей побочной ветке, как theirs (т.е. "работу одного участника поверх неё").

-b <новая-ветка>

Создать новую ветку с именем <новая-ветка>, начать её в <начальной-точке> и переключить результирующую ветку; подробности см. в git-branch[1].

-B <новая-ветка>

То же, что и -b, за исключением того, что если ветка уже существует, она сбрасывает <ветку> на начальную точку вместо того, чтобы завершаться ошибкой.

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

При создании новой ветки настраивает конфигурацию "вышестоящей". Подробности см. в описании --track в git-branch[1]. Для удобства, --track без -b подразумевает создание ветки.

Если параметр -b не указан, имя новой ветки будет получено из отслеживаемой внешней ветки путём просмотра локальной части спецификатора ссылки, настроенного для соответствующего внешнего репозитория, а затем удаления начальной части до "*". Это указывает нам использовать hack в качестве локальной ветки при создании ветки от origin/hack (или remotes/origin/hack, или даже refs/remotes/origin/hack). Если указанное имя не содержит слэша или приведённое выше угадывание даёт пустое имя, угадывание прерывается. В таком случае вы можете явно указать имя с помощью -b.

--no-track

Не настраивать конфигурацию "вышестоящей", даже если переменная конфигурации branch.autoSetupMerge имеет значение true.

--guess
--no-guess

Если <ветка> не найдена, но существует отслеживаемая внешняя ветка ровно в одном внешнем репозитории (назовём его <внешний-репозиторий>) с совпадающим именем, обрабатывать как эквивалент

$ git checkout -b <ветка> --track <внешний-репозиторий>/<ветка>

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

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

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

-l

Создать журнал ссылок новой ветки; подробности см. в git-branch[1].

-d
--detach

Вместо переключения ветки для работы над ней, переключить коммит для осмотра и одноразовых экспериментов. Это поведение по умолчанию для git checkout <коммит>, когда <коммит> не является именем ветки. Подробности см. в разделе "ОТСОЕДИНЁННЫЙ HEAD" ниже.

--orphan <новая-ветка>

Создать новую нерождённую ветку с именем <новая-ветка>, начатую с <начальной-точки>, и переключиться на неё. Первый коммит, сделанный в этой новой ветке, не будет иметь родителей и станет корнем новой истории, полностью отделённой от всех других веток и коммитов.

Индекс и рабочий каталог настраиваются так, как если бы вы ранее выполнили git checkout <начальная-точка>. Это позволяет вам начать новую историю, которая записывает набор путей, похожий на <начальную-точку>, легко выполнив git commit -a, чтобы сделать корневой коммит.

Это может быть полезно, когда вы хотите опубликовать дерево из коммита, не раскрывая его полную историю. Возможно, вы захотите сделать это, чтобы опубликовать ветку с открытым исходным кодом проекта, чьё текущее дерево "чисто", но чья полная история содержит проприетарные или иным образом обременённые фрагменты кода.

Если вы хотите начать отдельную историю, которая записывает набор путей, полностью отличающийся от набора <начальной-точки>, то вы должны очистить индекс и рабочий каталог сразу после создания ветки-сироты, выполнив git rm -rf . из верхнего уровня рабочего каталога. После этого вы будете готовы подготовить свои новые файлы, повторно заполнив рабочий каталог, скопировав их из другого места, извлекая tar-архив и т.д.

--ignore-skip-worktree-bits

В режиме частичного переключения git checkout -- <путь>... обновляет только записи, соответствующие <путям> и разрежённым шаблонам в $GIT_DIR/info/sparse-checkout. Этот параметр игнорирует разрежённые шаблоны и добавляет обратно любые файлы в <путь>....

-m
--merge

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

Когда возникает конфликт слияния, записи индекса для конфликтующих путей остаются не слитыми, и вам нужно разрешить конфликты и пометить разрешённые пути с помощью git add (или git rm, если слияние должно привести к удалению пути).

При переключении путей из индекса этот параметр позволяет воссоздать конфликтующее слияние по указанным путям. Этот параметр нельзя использовать при переключении путей из указателя дерева.

При переключении веток с --merge проиндексированные изменения могут быть потеряны.

--conflict=<стиль>

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

-p
--patch

Интерактивно выбирать части в различии между <указателем-дерева> (или индексом, если не указан) и рабочим каталогом. Выбранные части затем применяются в обратном порядке к рабочему каталогу (и если был указан <указатель-дерева>, то и к индексу).

Это означает, что вы можете использовать git checkout -p для выборочного отбрасывания правок из вашего текущего рабочего каталога. См. раздел "Интерактивный режим" в git-add[1], чтобы узнать, как работать в режиме --patch.

Обратите внимание, что этот параметр по умолчанию использует режим без наложения (см. также --overlay) и в настоящее время не поддерживает режим наложения.

-U<n>
--unified=<n>

Создавать сравнения с <число> строками контекста. Количество строк контекста по умолчанию равно diff.context или 3, если переменная конфигурации не установлена. (-U без <числа> молча принимается как синоним -p из-за исторической случайности).

--inter-hunk-context=<n>

Выводить в качестве контекста между блоками изменений до <n> строк, тем самым объединяя близкие блоки изменений. По умолчанию равно значению переменной конфигурации diff.interHunkContext или 0, если она не установлена.

--ignore-other-worktrees

git checkout отказывается, когда нужная ветка уже переключена или иным образом используется другим рабочим каталогом. Этот параметр заставляет всё равно переключить ветку. Другими словами, ветка может использоваться более чем одним рабочим каталогом.

--overwrite-ignore
--no-overwrite-ignore

Молча перезаписывать игнорируемые файлы при переключении веток. Это поведение по умолчанию. Используйте --no-overwrite-ignore, чтобы прервать операцию, когда новая ветка содержит игнорируемые файлы.

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

Использование --recurse-submodules обновит содержимое всех активных подмодулей в соответствии с коммитом, записанным в суперпроекте. Если локальные изменения в подмодуле будут перезаписаны, переключение завершится ошибкой, если не использовать -f. Если ничего (или --no-recurse-submodules) не используется, рабочие каталоги подмодулей не будут обновлены. Как и git-submodule[1], это отсоединит HEAD подмодуля.

--overlay
--no-overlay

В режиме наложения по умолчанию git checkout никогда не удаляет файлы из индекса или рабочего каталога. При указании --no-overlay файлы, которые присутствуют в индексе и рабочем каталоге, но отсутствуют в <указателе-дерева>, удаляются, чтобы они точно соответствовали <указателю-дерева>.

--pathspec-from-file=<файл>

Спецификатор пути передаётся в <файле>, а не в аргументах командной строки. Если <файл> точно равен -, то используется стандартный ввод. Элементы спецификатора пути разделяются символами LF или CR/LF. Элементы спецификатора пути могут заключаться в кавычки, как объяснено для переменной конфигурации core.quotePath (см. git-config[1]). См. также --pathspec-file-nul и глобальный --literal-pathspecs.

--pathspec-file-nul

Имеет значение только при указании --pathspec-from-file. Элементы спецификатора пути отделяются друг от друга с помощью NUL-символа, а все остальные символы интерпретируются буквально (включая кавычки и переводы строк).

<ветка>

Ветка для переключения; если она ссылается на ветку (т.е. имя, которое при добавлении "refs/heads/" является допустимой ссылкой), то эта ветка переключается. В противном случае, если она ссылается на допустимый коммит, ваш HEAD становится "отсоединённым", и вы больше не находитесь ни на какой ветке (подробности см. ниже).

Вы можете использовать синтаксис @{-N}, чтобы ссылаться на N-ю последнюю ветку/коммит, переключенные с помощью операции "git checkout". Вы также можете указать -, что является синонимом @{-1}.

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

<новая-ветка>

Имя для новой ветки.

<начальная-точка>

Имя коммита, с которого начинается новая ветка; подробности см. в git-branch[1]. По умолчанию HEAD.

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

<указатель-дерева>

Дерево, из которого выполняется переключение (когда указаны пути). Если не указано, будет использоваться индекс.

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

--

Не рассматривать остальные аргументы командной строки в качестве параметров.

<спецификатор-пути>…

Ограничивает пути, на которые влияет операция.

Более подробно описание см. в параграфе спецификатор пути (pathspec) в gitglossary[7].

ОТСОЕДИНЁННЫЙ HEAD

HEAD обычно ссылается на именованную ветку (например, master). Между тем, каждая ветка ссылается на конкретный коммит. Давайте посмотрим на репозиторий с тремя коммитами, один из которых помечен, и с переключённой веткой master:

           HEAD (ссылается на ветку 'master')
            |
            v
a---b---c  ветка 'master' (ссылается на коммит 'c')
    ^
    |
  метка 'v2.0' (ссылается на коммит 'b')

Когда в этом состоянии создаётся коммит, ветка обновляется, чтобы ссылаться на новый коммит. В частности, git commit создаёт новый коммит d, чьим родителем является коммит c, а затем обновляет ветку master, чтобы она ссылалась на новый коммит d. HEAD по-прежнему ссылается на ветку master и, таким образом, теперь косвенно ссылается на коммит d:

$ edit; git add; git commit

               HEAD (ссылается на ветку 'master')
                |
                v
a---b---c---d  ветка 'master' (ссылается на коммит 'd')
    ^
    |
  метка 'v2.0' (ссылается на коммит 'b')

Иногда бывает полезно иметь возможность переключить коммит, который не находится на верхушке какой-либо именованной ветки, или даже создать новый коммит, на который не ссылается именованная ветка. Давайте посмотрим, что произойдёт, когда мы переключим коммит b (здесь мы показываем два способа, которыми это можно сделать):

$ git checkout v2.0  # или
$ git checkout master^^

   HEAD (ссылается на коммит 'b')
    |
    v
a---b---c---d  ветка 'master' (ссылается на коммит 'd')
    ^
    |
  метка 'v2.0' (ссылается на коммит 'b')

Обратите внимание, что независимо от того, какую команду checkout мы используем, HEAD теперь ссылается непосредственно на коммит b. Это известно как состояние отсоединённого HEAD. Это просто означает, что HEAD ссылается на конкретный коммит, в отличие от ссылки на именованную ветку. Давайте посмотрим, что произойдёт, когда мы создадим коммит:

$ edit; git add; git commit

     HEAD (ссылается на коммит 'e')
      |
      v
      e
     /
a---b---c---d  ветка 'master' (ссылается на коммит 'd')
    ^
    |
  метка 'v2.0' (ссылается на коммит 'b')

Теперь есть новый коммит e, но на него ссылается только HEAD. Конечно, мы можем добавить ещё один коммит в этом состоянии:

$ edit; git add; git commit

	 HEAD (ссылается на коммит 'f')
	  |
	  v
      e---f
     /
a---b---c---d  ветка 'master' (ссылается на коммит 'd')
    ^
    |
  метка 'v2.0' (ссылается на коммит 'b')

Фактически, мы можем выполнять все обычные операции Git. Но давайте посмотрим, что произойдёт, когда затем мы переключим master:

$ git checkout master

               HEAD (ссылается на ветку 'master')
      e---f     |
     /          v
a---b---c---d  ветка 'master' (ссылается на коммит 'd')
    ^
    |
  метка 'v2.0' (ссылается на коммит 'b')

Важно понимать, что в этот момент ничто не ссылается на коммит f. В конце концов коммит f (и, как следствие, коммит e) будет удалён обычным процессом сборки мусора Git, если только мы не создадим ссылку до того, как это произойдёт. Если мы ещё не ушли от коммита f, любое из следующих действий создаст ссылку на него:

$ git checkout -b foo  # или "git switch -c foo"  (1)
$ git branch foo                                 (2)
$ git tag foo                                    (3)

  1. создаёт новую ветку foo, которая ссылается на коммит f, а затем обновляет HEAD, чтобы он ссылался на ветку foo. Другими словами, после этой команды мы больше не будем находиться в состоянии отсоединённого HEAD.

  2. аналогично создаёт новую ветку foo, которая ссылается на коммит f, но оставляет HEAD отсоединённым.

  3. создаёт новую метку foo, которая ссылается на коммит f, оставляя HEAD отсоединённым.

Если мы ушли от коммита f, то мы должны сначала восстановить его имя объекта (обычно с помощью git reflog), а затем можем создать ссылку на него. Например, чтобы увидеть последние два коммита, на которые ссылался HEAD, мы можем использовать любую из этих команд:

$ git reflog -2 HEAD # или
$ git log -g -2 HEAD

УСТРАНЕНИЕ НЕОДНОЗНАЧНОСТИ АРГУМЕНТОВ

Когда вы запускаете git checkout <что-то>, Git пытается угадать, предназначено ли <что-то> для ветки, коммита или набора файлов, а затем либо переключается на эту ветку или коммит, либо восстанавливает указанные файлы.

Если есть какая-либо неоднозначность, Git будет обрабатывать <что-то> как ветку или коммит, но вы можете использовать двойное тире --, чтобы заставить Git обрабатывать параметр как список файлов и/или каталогов, например:

git checkout -- file.txt

ПРИМЕРЫ

1. Пути

Следующая последовательность переключает ветку master, возвращает Makefile на две редакции назад, случайно удаляет hello.c и восстанавливает его из индекса.

$ git checkout master             (1)
$ git checkout master~2 Makefile  (2)
$ rm -f hello.c
$ git checkout hello.c            (3)

  1. переключить ветку

  2. извлечь файл из другого коммита

  3. восстановление hello.c из индекса

Если вы хотите переключить все C-исходные файлы из индекса, вы можете выполнить

$ git checkout -- '*.c'

Обратите внимание на кавычки вокруг *.c. Файл hello.c также будет переключён, даже если он больше не находится в рабочем каталоге, потому что подстановка имён файлов используется для сопоставления записей в индексе (а не в рабочем каталоге оболочкой).

Если у вас есть неудачная ветка с именем hello.c, этот шаг будет воспринят как инструкция переключиться на эту ветку. Вместо этого вы должны написать:

$ git checkout -- hello.c

2. Слияние

После работы в неправильной ветке переключение на правильную ветку выполняется с помощью:

$ git checkout mytopic

Однако ваша «неправильная» ветка и правильная ветка mytopic могут различаться в файлах, которые вы изменили локально, и в этом случае приведённое выше переключение завершится ошибкой, например:

$ git checkout mytopic
ошибка: У вас есть локальные изменения в 'frotz'; переключение веток не выполняется.

Вы можете передать команде флаг -m, который попытается выполнить трёхходовое слияние:

$ git checkout -m mytopic
Автослияние frotz

После этого трёхходового слияния локальные изменения не регистрируются в вашем файле индекса, поэтому git diff покажет вам, какие изменения вы сделали с момента верхушки новой ветки.

3. Конфликт слияния

Когда возникает конфликт слияния при переключении веток с параметром -m, вы увидите что-то вроде этого:

$ git checkout -m mytopic
Auto-merging frotz
ОШИБКА: Конфликт слияния в frotz
критическая ошибка: программа слияния не выполнена

На этом этапе git diff показывает чисто слитые изменения, как в предыдущем примере, а также изменения в конфликтующих файлах. Отредактируйте и разрешите конфликт и пометьте его как разрешённый с помощью git add как обычно:

$ edit frotz
$ git add frotz

КОНФИГУРАЦИЯ

Дальнейшее содержание этого раздела, повторяет то, что может быть найдено в git-config[1]:

checkout.defaultRemote

Когда вы запускаете git checkout <что-то> или git switch <что-то> и у вас есть только один внешний репозиторий, он может неявно переключиться на отслеживание, например, origin/<что-то>. Это перестаёт работать, как только у вас появляется более одного внешнего репозитория со ссылкой <что-то>. Этот параметр позволяет задать имя предпочтительного внешнего репозитория, который всегда должен побеждать при разрешении неоднозначности. Типичный вариант использования — установить это значение в origin.

В настоящее время это используется git-switch[1] и git-checkout[1], когда git checkout <что-то> или git switch <что-то> будет переключаться на ветку <что-то> в другом внешнем репозитории, и 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 и т.д.

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

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

СМ. ТАКЖЕ

git-switch[1], git-restore[1]

GIT

Является частью пакета git[1]