українська мова ▾ 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>

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

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

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

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

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

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

--no-track

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

--orphan <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]