Git

git-checkout last updated in 2.52.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 має два основні режими:

Перемикання гілок, з git checkout <branch>
Відновіть іншу версію файлу, наприклад, за допомогою git checkout <commit> <ім'я файлу> або git checkout <ім'я файлу>

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

git checkout [<branch>]

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

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

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

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

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

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

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

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

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

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]

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

Наприклад, 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.

Це не вдасться, якщо файл має конфлікт злиття, і ви ще не виконали git add file.txt (або щось еквівалентне), щоб позначити його як вирішене. Ви можете використовувати -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>

-t

--track[=(direct|inherit)]

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

Якщо не вказано параметр -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)

створює нову гілку foo, яка посилається на коміт f, а потім оновлює HEAD, щоб він посилався на гілку foo. Іншими словами, після цієї команди ми більше не будемо в окремому стані HEAD.
аналогічно створює нову гілку foo, яка посилається на коміт f, але залишає HEAD відокремленою.
створює новий тег foo, який посилається на коміт f, залишаючи HEAD відокремленим.

Якщо ми відійшли від коміту f, то спочатку потрібно відновити назву його об’єкта (зазвичай за допомогою git reflog), а потім створити посилання на нього. Наприклад, щоб побачити два останні коміти, на які посилався HEAD, можна скористатися будь-якою з цих команд:

$ git reflog -2 HEAD # or
$ 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)

перемикач гілки
взяти файл з іншого коміту
відновити 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[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands