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

НАЗВА

git-switch  — Перемикання гілок

СИНОПСИС

git switch [<options>] [--no-guess] <branch>
git switch [<options>] --detach [<start-point>]
git switch [<options>] (-c|-C) <new-branch> [<start-point>]
git switch [<options>] --orphan <new-branch>

ОПИС

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

За бажанням, нову гілку можна створити за допомогою -c, -C, автоматично з віддаленої гілки з такою ж назвою (див. --guess), або відʼєднати робоче дерево від будь-якої гілки за допомогою --detach, разом з перемиканням на неї.

Перемикання гілок не вимагає чистого індексу та робочого дерева (тобто немає відмінностей порівняно з HEAD). Однак операція переривається, якщо призводить до втрати локальних змін, якщо не вказано інше за допомогою --discard-changes або --merge.

ОПЦІЇ

<branch>

Гілка, на яку потрібно перейти.

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

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

<start-point>

Початкова точка для нової гілки. Вказівка <початкової-точки> дозволяє створити гілку на основі деякої іншої точки в історії, ніж та, на яку зараз вказує HEAD. (Або, у випадку --detach, дозволяє перевірити та почати від деякої іншої точки.)

Ви можете використовувати синтаксис @{-<N>}, щоб звернутися до <N>-ї останньої гілки/коміту, до якої було здійснено перехід за допомогою команди git switch або git checkout. Ви також можете вказати -, що є синонімом @{-1}. Це часто використовується для швидкого переходу між двома гілками або для скасування помилкового переходу на іншу гілку.

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

-c <new-branch>
--create <new-branch>

Створіть нову гілку з назвою <new-branch>, починаючи з <start-point>, перш ніж перемикатися на гілку. Це транзакційний еквівалент

$ git branch <new-branch>
$ git switch <new-branch>

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

-C <new-branch>
--force-create <new-branch>

Аналогічно до --create, за винятком того, що якщо гілка <new-branch> вже існує, її буде скинуто до точки <start-point>. Це зручний спосіб замість:

$ git branch -f _<new-branch>_
$ git switch _<new-branch>_
-d
--detach

Переключитись на коміт для перевірки та експериментів, які можна відкинути. Дивіться розділ "DETACHED HEAD" в git-checkout[1] для отримання детальної інформації.

--guess
--no-guess

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

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

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

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

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

-f
--force

Псевдонім для --discard-changes.

--discard-changes

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

-m
--merge

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

У разі виникнення конфлікту злиття записи індексу для шляхів, що конфліктують, залишаються незлиті, і вам потрібно розвʼязати ці конфлікти та позначити розвʼязані шляхи командою git add (або git rm, якщо в результаті злиття шлях має бути видалено).

--conflict=<стиль>

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

-q
--quiet

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

--progress
--no-progress

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

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

Під час створення нової гілки налаштувати «upstream». Мається на увазі використання -c. Детальніше див. опис параметра --track у документації git-branch[1].

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

--no-track

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

--orphan <new-branch>

Створити нову незалежну гілку з назвою <new-branch>. Усі відстежувані файли видаляються.

--ignore-other-worktrees

git switch відмовляє, коли потрібне посилання вже отримано іншим робочим деревом. Ця опція дозволяє йому все одно отримати посилання. Іншими словами, посилання може зберігатися більш ніж одним робочим деревом.

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

Використання --recurse-submodules оновить вміст усіх активних субмодулів відповідно до коміту, записаного в суперпроєкті. Якщо нічого не використовується (або --no-recurse-submodules), робочі дерева субмодулів не оновлюватимуться. Так само, як і git-submodule[1], це відʼєднає HEAD субмодулів.

ПРИКЛАДИ

Наступна команда перемикає на гілку "master":

$ git switch master

Після роботи в неправильній гілці, перемикання на правильну гілку буде здійснюватися за допомогою:

$ git switch mytopic

Однак, ваша "неправильна" гілка та правильна гілка "mytopic" можуть відрізнятися у файлах, які ви змінили локально, і в такому разі вищезгаданий перемикач не спрацює ось так:

$ git switch mytopic
error: You have local changes to 'frotz'; not switching branches.

Ви можете надати команді прапорець -m, що спробує виконати тристороннє злиття:

$ git switch -m mytopic
Auto-merging frotz

Після цього тристороннього злиття локальні зміни не реєструються у вашому індексному файлі, тому git diff покаже вам, які зміни ви внесли з моменту створення нової гілки.

Щоб повернутися до попередньої гілки перед тим, як ми переключилися на mytopic (тобто гілку "master"):

$ git switch -

Ви можете створити нову гілку з будь-якого коміту. Наприклад, перейдіть на "HEAD~3" та створіть гілку "fixup":

$ git switch -c fixup HEAD~3
Switched to a new branch 'fixup'

Якщо ви хочете розпочати нову гілку з віддаленої гілки з такою ж назвою:

$ git switch new-topic
Branch `new-topic` set up to track remote branch `new-topic` from `origin`
Switched to a new branch `new-topic`

Щоб переглянути коміт HEAD~3 для тимчасового ознайомлення або експерименту без створення нової гілки:

$ git switch --detach HEAD~3
HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'

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

$ git switch -c good-surprises

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

Все, що знаходиться нижче цього рядка в цьому розділі, вибірково включено з документації git-config[1]. Вміст такий самий, як і там:

checkout.defaultRemote

Коли ви виконуєте команду git checkout <щось> або 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-checkout[1], git-branch[1]

GIT

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