українська мова ▾ Topics ▾ Latest version ▾ git-checkout last updated in 2.53.0

НАЗВА

git-checkout — Перемикання гілок або відновлення робочих файлів дерева

СИНОПСИС

git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] --detach [<branch>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
git checkout <tree-ish> [--] <pathspec>…​
git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…​]

ОПИС

git checkout має два основні режими:

  1. Перемикання гілок, з git checkout <branch>

  2. Відновлення версії файлу, наприклад, за допомогою git checkout <commit> <імʼя файлу> або git checkout <імʼя файлу>

Дивіться РОЗУМІННЯ НЕОДНОЗНАЧНОСТЕЙ АРГУМЕНТІВ нижче, щоб дізнатися, як Git вирішує, який з них використовувати.

git checkout [<branch>]

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

Якщо <branch> не знайдено, але існує гілка відстеження рівно в одному віддаленому об’єкті (назвемо його <remote>) з відповідним імʼям, і --no-guess не вказано, розглядати як еквівалент

$ git checkout -b <branch> --track <remote>/<branch>

Виконання команди git checkout без зазначення гілки не має жодного ефекту, окрім виведення інформації про відстеження поточної гілки.

git checkout -b <new-branch> [<start-point>]

Створює нову гілку з назвою <new-branch>, починає її з <start-point> (стандартно поточний коміт) та перемикається на нову гілку. Ви можете використовувати опції --track або --no-track, щоб встановити інформацію для відстеження основної гілки.

Це не вдасться, якщо виникне помилка під час перемикання на <new-branch>, наприклад, якщо перемикання на коміт <start-point> перезапише ваші незафіксовані зміни.

git checkout -B <branch> [<start-point>]

Те саме, що й -b, за винятком того, що якщо гілка вже існує, то <branch> скидається до початкової точки, а не призводить до невдачі.

git checkout --detach [<branch>]
git checkout [--detach] <commit>

Те саме, що й git checkout <branch>, за винятком того, що замість вказівки HEAD на гілку, він вказує HEAD на ID коміта. Дивіться розділ "DETACHED HEAD" нижче для отримання додаткової інформації.

Пропуск <branch> відʼєднує HEAD на вершині поточної гілки.

git checkout <tree-ish> [--] <pathspec>...
git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]

Замінити вказані файли та/або теки версією з вказаного коміту або дерева та додати їх до індексу (також відомого як "staging area").

Наприклад, git checkout main file.txt замінить file.txt версією з main.

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]

Замінює вказані файли та/або теки версією з індексу.

Наприклад, якщо ви виконуєте перевірку коміту, редагуєте файл file.txt, а потім вирішуєте, що ці зміни були помилкою, команда git checkout file.txt відкине всі зміни у файлі file.txt, які не були додані до stage.

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

git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]

Це схоже на два попередні режими, але дозволяє використовувати інтерактивний інтерфейс для показу виводу "diff" та вибору фрагментів для використання в результаті. Дивіться нижче опис опції --patch.

ОПЦІЇ

-q
--quiet

Тихий режим, повідомлення відгуку придушуються.

--progress
--no-progress

Повідомлення про стан виконання зазвичай зʼявляються у стандартному потоці помилок, коли він підключений до термінала, якщо не вказано --quiet. Цей прапорець дозволяє повідомляти про хід виконання, навіть якщо він не підключений до термінала, незалежно від --quiet.

-f
--force

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

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

--ours
--theirs

Під час перемикання шляхів з індексу перемикатись на stage #2 (ours) або stage #3 (theirs) для необʼєднаних шляхів.

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

Це пояснюється тим, що rebase використовується в робочому процесі, який розглядає історію на віддаленій гілці як спільну канонічну, а роботу, виконану на гілці, яку ви перебазуєте, розглядає як роботу третьої сторони, що інтегрується, і ви тимчасово берете на себе роль зберігача канонічної історії під час перебазування. Як зберігачу канонічної історії, вам потрібно переглядати історію з віддаленої гілки як ours (тобто "нашу спільну канонічну історію"), тоді як те, що ви зробили на своїй бічній гілці, як theirs (тобто "роботу одного учасника поверх неї").

-b <new-branch>

Створення нової гілки з назвою <нова-гілка>, яка починається з <початкової-точки> та перехід на отриману гілку; див. git-branch[1] для отримання детальної інформації.

-B <new-branch>

Те саме, що й -b, за винятком того, що якщо гілка вже існує, то <branch> скидається до початкової точки, а не призводить до невдачі.

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

Під час створення нової гілки встановлює конфігурацію "upstream". Див. --track у git-branch[1] для отримання детальної інформації. Для зручності, --track без -b означає створення гілки.

Якщо не вказано параметр -b, імʼя нової гілки буде отримано з гілки віддаленого відстеження, шляхом перегляду локальної частини refspec, налаштованої для відповідного віддаленого елемента, а потім видалення початкової частини до "*". Це підкаже нам використовувати hack як локальну гілку під час відгалуження від origin/hack (або remotes/origin/hack, або навіть refs/remotes/origin/hack). Якщо задана назва не має косої риски, або вищевказане вгадування призводить до порожньої назви, вгадування переривається. У такому випадку ви можете явно вказати назву за допомогою -b.

--no-track

Не встановлювати конфігурацію "upstream", навіть якщо змінна конфігурації branch.autoSetupMerge має значення true.

--guess
--no-guess

Якщо <branch> не знайдено, але існує гілка відстеження саме в одному віддаленому репозиторії (назвемо його <remote>) з відповідною назвою, розглядайте це як еквівалент

$ git checkout -b <branch> --track <remote>/<branch>

Якщо гілка існує на декількох віддалених репозиторіях і один із них вказано у конфігураційній змінній checkout.defaultRemote, ми будемо використовувати саме його для усунення неоднозначності, навіть якщо <branch> не є унікальним для всіх віддалених репозиторіїв. Встановіть, наприклад, checkout.defaultRemote=origin, щоб завжди перевіряти віддалені гілки звідти, якщо <branch> є неоднозначним, але існує на віддаленому сервері origin . Див. також checkout.defaultRemote у git-config[1].

--guess — є стандартною поведінкою. Використовуйте --no-guess, щоб її вимкнути.

Стандартну поведінку можна встановити за допомогою змінної конфігурації checkout.guess.

-l

Створіть reflog нової гілки; див. git-branch[1] для отримання детальної інформації.

-d
--detach

Замість того, щоб перемикатись на гілку для роботи з нею, перейти до коміту для перевірки та експериментів, які можна видалити. Це стандартна поведінка для git checkout <commit>, коли <commit> не є назвою гілки. Дивіться розділ "DETACHED HEAD" нижче для отримання детальної інформації.

--orphan <new-branch>

Створити нову ненароджену гілку з назвою <нова-гілка>, розпочату з <початкова-точка>, та перейти до неї. Перший коміт, зроблений у цій новій гілці, не матиме батьківських елементів і буде коренем нової історії, повністю відокремленої від усіх інших гілок та комітів.

Індекс та робоче дерево налаштовуються так, ніби ви попередньо виконали команду 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, зміни в stage можуть бути втрачені.

--conflict=<стиль>

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

-p
--patch

Інтерактивно обирайте фрагменти у різниці між <tree-ish> (або індексом, якщо не вказано) та робочим деревом. Потім обрані фрагменти застосовуються у зворотному порядку до робочого дерева (а якщо вказано <tree-ish>, то й до індексу).

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

Зверніть увагу, що цей параметр стандартно використовує режим без накладання (див. також --overlay) і наразі не підтримує режим накладання.

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

Створює файли відмінностей (diff) з <n> рядками контексту. Стандартно використовується diff.context або 3, якщо параметр конфігурації не встановлено.

--inter-hunk-context=<n>

Показує контекст між фрагментами відмінностей (diff hunks), до вказаної <кількості> рядків, таким чином обʼєднуючи фрагменти, що знаходяться близько один до одного. Стандартно використовується значення 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, файли, які зʼявляються в індексі та робочому дереві, але не в <tree-ish>, видаляються, щоб вони точно відповідали <tree-ish>.

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

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

--pathspec-file-nul

Має сенс лише з --pathspec-from-file. Елементи Pathspec розділяються символом NUL, а всі інші символи (включно з символами нового рядка та лапками) сприймаються буквально.

<branch>

Гілка для перемикання; якщо вона посилається на гілку (тобто ім’я, яке, доповнене "refs/heads/", є коректним посиланням), то ця гілка вилучена. В іншому випадку, якщо вона посилається на коректний коміт, ваш HEAD стає "відокремленим", і ви більше не перебуваєте на жодній гілці (див. деталі нижче).

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

У особливому випадку можна використовувати <rev-a>...<rev-b> як скорочений запис для бази злиття <rev-a> та <rev-b>, якщо така база існує лише одна. Можна опустити не більше одного з елементів <rev-a> та <rev-b>; у цьому випадку буде використано значення HEAD.

<нова-гілка>

Назва для нової гілки.

<start-point>

Імʼя коміту, з якого починається нова гілка; див. git-branch[1] для отримання детальної інформації. Стандартно — HEAD.

У особливому випадку можна використовувати <rev-a>...<rev-b> як скорочений запис для бази злиття <rev-a> та <rev-b>, якщо така база існує лише одна. Можна опустити не більше одного з елементів <rev-a> та <rev-b>; у цьому випадку буде використано значення HEAD.

<tree-ish>

Дерево для отримання (якщо шляхи вказані). Якщо не вказано, буде використано індекс.

У особливому випадку можна використовувати <rev-a>...<rev-b> як скорочений запис для бази злиття <rev-a> та <rev-b>, якщо така база існує лише одна. Можна опустити не більше одного з елементів <rev-a> та <rev-b>; у цьому випадку буде використано значення HEAD.

--

Не інтерпретує жодних додаткових аргументів як опції.

<pathspec>...

Обмежує шляхи, на які впливає операція.

Для отримання додаткової інформації див. елемент «pathspec» у gitglossary[7].

DETACHED HEAD

HEAD зазвичай посилається на іменовану гілку (наприклад, master). Тим часом кожна гілка посилається на певний коміт. Розгляньмо репозиторій з трьома комітами, один з яких позначений тегом, та з гілкою master, яка є поточною:

           HEAD (посилається на гілку «master»')
            |
            v
a---b---c  гілка 'master' (посилається на коміт 'c'))
    ^
    |
  tag 'v2.0' (посилається на коміт 'b')

Коли коміт створюється в цьому стані, гілка оновлюється, щоб посилатися на новий коміт. Зокрема, git commit створює новий коміт d, батьківським комітом якого є commit c, а потім оновлює гілку master, щоб посилатися на новий коміт d. HEAD все ще посилається на гілку master і тому опосередковано тепер посилається на коміт d:

$ edit; git add; git commit

               HEAD (посилається на гілку «master»')
                |
                v
a---b---c---d  гілка 'master' (стосується комміту 'd')
    ^
    |
  tag 'v2.0' (посилається на коміт 'b')

Іноді корисно мати можливість отримати коміт, який не знаходиться на верхівці жодної іменованої гілки, або навіть створити новий коміт, на який не посилається іменована гілка. Розгляньмо, що відбувається, коли ми перемикаємось на коміт b (тут ми показуємо два способи, як це можна зробити):

$ git checkout v2.0  # або
$ git checkout master^^

   HEAD (посилається на коміт 'b')
    |
    v
a---b---c---d  гілка 'master' (стосується комміту 'd')
    ^
    |
  tag 'v2.0' (посилається на коміт 'b')

Зверніть увагу, що незалежно від того, яку команду перемикання ми використовуємо, HEAD тепер безпосередньо посилається на коміт b. Це відомо як перебування HEAD у відокремленому стані. Це просто означає, що HEAD посилається на конкретний коміт, на відміну від посилання на іменовану гілку. Подивимося, що відбувається, коли ми створюємо коміт:

$ edit; git add; git commit

     HEAD (посилається на commit 'e')
      |
      v
      e
     /
a---b---c---d  гілка 'master' (посилається на коміт 'd')
    ^
    |
  tag 'v2.0' (посилається на коміт 'b')

Тепер є новий коміт e, але на нього посилається лише HEAD. Звичайно, ми можемо додати ще один коміт у цьому стані:

$ edit; git add; git commit

	 HEAD (посилається на коміт 'f')
	  |
	  v
      e---f
     /
a---b---c---d  гілка 'master' (посилається на коміт 'd')
    ^
    |
  tag 'v2.0' (посилається на коміт 'b')

Фактично, ми можемо виконувати всі звичайні операції Git. Але подивимось, що відбувається, коли ми потім отримуємо master:

$ git checkout master

               HEAD (стосується гілки «головна»)
      e---f     |
     /          v
a---b---c---d  гілка 'master' (стосується комміту 'd')
    ^
    |
  tag 'v2.0' (посилається на коміт 'b')

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

$ git checkout -b foo  # or "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
Автоматичне обʼєднання 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]