українська мова ▾ Topics ▾ Latest version ▾ git-checkout last updated in 2.51.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 [-f] <tree-ish> [--] <pathspec>…​
git checkout [-f] <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 також оновить HEAD, щоб встановити вказану гілку як поточну.

git checkout [<branch>]

Щоб підготуватися до роботи з <гілкою>, перейдіть до неї, оновивши індекс та файли в робочому дереві, а також вказавши HEAD на гілку. Локальні зміни до файлів у робочому дереві зберігаються, щоб їх можна було зафіксувати в <гілці>.

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

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

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

git checkout (-b|-B) <new-branch> [<start-point>]

Вказівка -b призводить до створення нової гілки, ніби було викликано git-branch[1], а потім отримано. У цьому випадку ви можете використовувати опції --track або --no-track, які будуть передані до git branch. Для зручності, --track без -b означає створення гілки; див. опис --track нижче.

Якщо задано -B, то <нова-гілка> створюється, якщо вона не існує; інакше вона скидається. Це транзакційний еквівалент

$ git branch -f <branch> [<start-point>]
$ git checkout <branch>

тобто, гілка не скидається/не створюється, доки "git checkout" не буде успішним (наприклад, коли гілка використовується в іншому робочому дереві, не лише поточна гілка залишається незмінною, але й гілка не скидається до початкової точки).

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

Підготуйтеся до роботи над <commit>, від’єднавши від нього HEAD (див. розділ "DETACHED HEAD") та оновивши індекс і файли в робочому дереві. Локальні зміни файлів у робочому дереві зберігаються, тому результуюче робоче дерево буде станом, записаним у комміті, плюс локальні зміни.

Коли аргумент <commit> є назвою гілки, опцію --detach можна використовувати для від’єднання HEAD на кінці гілки (git checkout <branch> перевірить цю гілку без від’єднання HEAD).

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

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

Перезаписати вміст файлів, що відповідають специфікації шляху. Якщо <дерево-подібне> (найчастіше коміт) не вказано, перезаписати робоче дерево вмістом індексу. Якщо вказано <дерево-подібне>, перезаписати як індекс, так і робоче дерево вмістом <дерево-подібне>.

Індекс може містити необ’єднані записи через попереднє невдале злиття. За замовчуванням, якщо ви спробуєте вивести такий запис з індексу, операція виведення завершиться невдачею, і нічого не буде виведено. Використання -f проігнорує ці необ’єднані записи. Вміст з певної сторони злиття можна вивести з індексу за допомогою --ours або --theirs. За допомогою -m зміни, внесені до робочого файлу дерева, можна відкинути, щоб відтворити початковий конфліктний результат злиття.

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

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

ОПЦІЇ

-q
--quiet

Тихі, придушені повідомлення зворотного зв’язку.

--progress
--no-progress

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

-f
--force

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

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

--ours
--theirs

Під час перевірки шляхів з індексу перевірте етап №2 (наші) або №3 (їхні) для необ’єднаних шляхів.

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

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

-b <new-branch>

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

-B <new-branch>

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

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

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

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

--no-track

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

--guess
--no-guess

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

$ 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

Створіть рефлог нової гілки; див. 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, поетапні зміни можуть бути втрачені.

--conflict=<стиль>

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

-p
--patch

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

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

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

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

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

--inter-hunk-context=<n>

Показує контекст між різницями (diff hanks), до вказаної <кількості> рядків, таким чином об’єднуючи ханки, що знаходяться близько один до одного. За замовчуванням використовується значення 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=<файл>

Специфікація шляху передається у <файл> замість аргументів командного рядка. Якщо <файл> дорівнює саме -, то використовується стандартний ввід. Елементи Pathspec розділяються символами LF або CR/LF. Елементи Pathspec можна брати в лапки, як пояснено для змінної конфігурації 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].

ВІДДІЛЕНА ГОЛОВА

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  # or
$ 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 # or
$ git log -g -2 HEAD

УСУНЕННЯ НЕОДНОЗНАЧНОСТЕЙ АРГУМЕНТУ

Коли задано лише один аргумент, і це не -- (наприклад, git checkout abc), і коли аргумент є одночасно коректним <tree-ish> (наприклад, гілка abc існує) та коректним <pathspec> (наприклад, файл або каталог з іменем "abc" існує), Git зазвичай просить вас усунути неоднозначність. Однак, оскільки отримання гілки є дуже поширеною операцією, git checkout abc приймає "abc" як <tree-ish> у такій ситуації. Використовуйте git checkout -- <pathspec>, якщо ви хочете отримати ці шляхи з індексу.

ПРИКЛАДИ

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]. Вміст такий самий, як і там:

Warning

Missing uk/config/checkout.adoc

See original version for this content.

ДИВ. ТАКОЖ

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

GIT

Частина набору git[1]