Git

git-branch last updated in 2.51.0

НАЗВА

git-branch — Перегляд, створення або видалення гілок

СИНОПСИС

git branch [--color[=<when>] | --no-color] [--show-current]
	   [-v [--abbrev=<n> | --no-abbrev]]
	   [--column[=<options>] | --no-column] [--sort=<key>]
	   [--merged [<commit>]] [--no-merged [<commit>]]
	   [--contains [<commit>]] [--no-contains [<commit>]]
	   [--points-at <object>] [--format=<format>]
	   [(-r|--remotes) | (-a|--all)]
	   [--list] [<pattern>…]
git branch [--track[=(direct|inherit)] | --no-track] [-f]
	   [--recurse-submodules] <branch-name> [<start-point>]
git branch (--set-upstream-to=<upstream>|-u <upstream>) [<branch-name>]
git branch --unset-upstream [<branch-name>]
git branch (-m|-M) [<old-branch>] <new-branch>
git branch (-c|-C) [<old-branch>] <new-branch>
git branch (-d|-D) [-r] <branch-name>…
git branch --edit-description [<branch-name>]

ОПИС

Якщо вказано параметр --list або якщо аргументів, що не є параметрами, немає, виводиться список наявних гілок; поточна гілка виділяється зеленим кольором і позначається зірочкою. Будь-які гілки, вибрані у пов’язаних робочих деревах, виділяються блакитним кольором і позначаються знаком «плюс». Параметр -r викликає виведення списку гілок, що відстежуються віддалено, а параметр -a показує як локальні, так і віддалені гілки.

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

Зверніть увагу, що під час надання <шаблону> треба використовувати --list; інакше команда може бути інтерпретована як створення гілки.

З параметром --contains буде показано лише гілки, що містять вказаний коміт (іншими словами, гілки, вершини яких є нащадками вказаного коміту), а параметр --no-contains діє навпаки. З опцією --merged будуть перелічені лише гілки, злиті з вказаним комітом (тобто гілки, вершини яких можна досягти з вказаного коміту). З опцією --no-merged будуть перелічені лише гілки, не злиті з вказаного коміту. Якщо аргумент <commit> відсутній, буде використано типове значення HEAD (тобто вершина поточної гілки).

Друга форма команди створює нову вершину гілки з іменем <назва-гілки>, яка вказує на поточний HEAD або на <початкову-точку>, якщо вона вказана. Як особливий випадок, для <початкової-точки> ви можете використовувати <rev-A>...<rev-B> як скорочення для бази злиття <rev-A> та <rev-B>, якщо існує лише одна база злиття. Ви можете пропустити щонайбільше один із <rev-A> та <rev-B>, у цьому випадку типовим значенням буде HEAD.

Зверніть увагу, що це створить нову гілку, але не переключить на неї робоче дерево; використовуйте git switch <нова-гілка> для перемикання на нову гілку.

Коли локальна гілка створюється на основі гілки, що відстежує віддалену гілку, Git налаштовує цю гілку (а саме записи конфігурації branch.<name>.remote та branch.<name>.merge) таким чином, щоб команда git pull виконувала відповідне злиття з гілки, що відстежує віддалену гілку. Цю поведінку можна змінити за допомогою глобального прапорця конфігурації branch.autoSetupMerge. Це налаштування можна замінити за допомогою опцій --track та --no-track, а згодом змінити за допомогою команди git branch --set-upstream-to.

При використанні опції -m або -M <стара-гілка> буде перейменована на <нова-гілка>. Якщо для <стара-гілка> існував відповідний reflog, його буде перейменовано відповідно до назви <нова-гілка>, а також буде створено запис у reflog для фіксації перейменування гілки. Якщо <нова-гілка> існує, для примусового перейменування необхідно використовувати -M.

Опції -c та -C мають точно таку ж семантику, як -m та -M, за винятком того, що замість перейменування гілки вона буде скопійована з новою назвою разом з її конфігурацією та reflog.

З опцією -d або -D, гулку <назва-гілки> буде видалено. Ви можете вказати більше однієї гілки для видалення. Якщо гілка наразі має журнал змін (reflog), то його також буде видалено.

Використовуйте -r разом із -d для видалення гілок, що відстежують віддалені репозиторії. Зверніть увагу, що видаляти такі гілки доцільно лише в тому випадку, якщо вони більше не існують у віддаленому репозиторії або якщо для команди git fetch налаштовано не завантажувати їх знову. Дивіться також підкоманду prune у git-remote[1], щоб дізнатися, як очистити всі застарілі гілки, що відстежують віддалені репозиторії.

ОПЦІЇ

-d
--delete: Видалити гілку. Гілку необхідно повністю обʼєднати з її гілкою upstream або з HEAD, якщо upstream не було встановлено за допомогою --track або --set-upstream-to.
-D: Скорочення для --delete --force.
--create-reflog: Створити журнал змін (reflog) гілки. Активує запис усіх змін, внесених до посилання гілки, що дозволяє використовувати sha1-вирази на основі дати, такі як <назва-гілки>@{yesterday}. Зверніть увагу, що в нечистих (non-bare) репозиторіях журнали змін зазвичай є стандартно увімкненим параметром конфігурації core.logAllRefUpdates. Заперечувана форма --no-create-reflog лише перевизначає попередній параметр --create-reflog, але наразі не скасовує налаштування core.logAllRefUpdates.
-f
--force: Скинути <назва-гілки> до <початкова-точка>, навіть якщо <назва-гілки> вже існує. Без -f, git branch відмовляється змінювати наявну гілку. У поєднанні з -d (або --delete) дозволяє видалення гілки незалежно від її статусу обʼєднання, або від того, чи вказує вона на дійсний коміт. У поєднанні з -m (або --move) дозволяє перейменування гілки, навіть якщо нова назва гілки вже існує, те саме стосується -c (або --copy).

Зверніть увагу, що git branch -f <назва-гілки> [<початкова-точка>], навіть з -f, відмовляється змінювати наявну гілку <назва-гілки>, яка отримана з іншого робочого дерева, повʼязаного з тим самим репозиторієм.
-m
--move: Перемістити/перейменувати гілку разом з її конфігурацією та журналом змін (reflog).
-M: Скорочення для --move --force.
-c
--copy: Скопіювати гілку разом з її конфігурацією та журналом змін (reflog).
-C: Скорочення для --copy --force.
--color[=<when>]: Виділити поточні, локальні та віддалено відстежувані гілки кольором. Значення має бути always (стандартно), never або auto.
--no-color: Вимкнути кольори гілок, навіть якщо у файлі конфігурації вказано використовувати кольоровий вивід. Те саме, що й --color=never.
-i
--ignore-case: При сортуванні та фільтруванні гілок не враховувати регістр.
--omit-empty: Не друкувати символ нового рядка після відформатованих посилань, якщо результат форматування — порожній рядок.
--column[=<опція>]
--no-column: Відображати список гілок у стовпцях. Синтаксис параметрів див. у змінній конфігурації column.branch. Параметри --column та --no-column без додаткових опцій відповідають значенням always та never відповідно.

Ця опція діє лише в режимі без розширеного виведення.
--sort=<ключ>: Сортування за <ключ>. Додайте префікс -, щоб сортувати за спаданням значень. Опцію --sort=<ключ> можна вказати кілька разів; у цьому випадку останній ключ стане первинним. Підтримувані ключі відповідають тим, що вказані в git-for-each-ref[1]. Якщо змінна branch.sort існує, то типовим порядком сортування є значення, задане для неї; інакше сортування відбувається за повним іменем посилання refname (включно з префіксом refs/...). У цьому випадку спочатку перелічуються відокремлені HEAD (якщо такі є), потім локальні гілки, а наостанок — гілки, що відстежують віддалені репозиторії. Див. git-config[1].
-r
--remotes: Вивести список або видалити (якщо використовується з опцією -d) гілки з віддаленим відстеженням. У поєднанні з опцією --list дозволяє знайти гілки, що відповідають заданим шаблонам.
-a
--all: Виведе перелік як гілок віддаленого відстеження, так і локальних гілок. Поєднуйте з --list для отримання збігу з опціональними шаблонами.
-l
--list: Список гілок. З опціональним <шаблон>..., наприклад, git branch --list maint-*', виводить лише ті гілки, що відповідають шаблону(ам).
--show-current: Вивести назву поточної гілки. У відокремленому стані HEAD нічого не виводиться.
-v
-vv
--verbose: У режимі переліку для кожного HEAD відображати SHA-1 та заголовок коміту, а також зв’язок із гілкою upstream (якщо такий є). Якщо вказано двічі, виводити шлях до пов’язаного робочого дерева (якщо таке є) та назву гілки upstream (див. також git remote show <remote>). Зверніть увагу, що шлях до поточного HEAD робочого дерева не виводитиметься (це завжди буде ваш поточна тека).
-q
--quiet: Бути менш гучним під час створення або видалення гілки, приховуючи повідомлення, що не є повідомленнями про помилки.
--abbrev=<n>: У деталізованому списку, що відображає імена об’єктів комітів, показувати найкоротший префікс довжиною не менше <n> шістнадцяткових цифр, який однозначно ідентифікує об’єкт. Стандартне значення — 7; його можна змінити за допомогою параметра конфігурації core.abbrev.
--no-abbrev: Показувати повні sha1 у вихідному переліку, не скорочувати їх.
-t
--track[=(direct|inherit)]: Під час створення нової гілки встановити параметри конфігурації branch.<name>.remote та branch.<name>.merge, щоб встановити конфігурацію відстеження "upstream" для нової гілки. Ця конфігурація вкаже git показувати звʼязок між двома гілками в git status та git branch -v. Крім того, при створенні нової гілки команда git pull без аргументів автоматично завантажує зміни з основного репозиторію.

Конкретна гілка upstream вибирається залежно від додаткового аргументу: -t, --track або --track=direct означають, що як upstream використовується сама гілка-відправна точка; --track=inherit означає, що копіюється конфігурація upstream гілки-відправної точки.

Змінна конфігурації branch.autoSetupMerge визначає, як повинні поводитися git switch, git checkout та git branch, коли не вказано ні --track, ні --no-track:

Стандартний параметр, true, діє так, ніби вказано --track=direct, коли початкова точка є гілкою з віддаленим відстеженням. false діє так, ніби вказано --no-track. always діє так, ніби вказано --track=direct. inherit працює так, ніби вказано --track=inherit. simple працює так, ніби вказано --track=direct, лише коли <start-point> є гілкою віддаленого відстеження, а нова гілка має таку саму назву, як і віддалена гілка.

Докладніше про те, як використовуються параметри branch.<name>.remote та branch.<name>.merge, див. git-pull[1] та git-config[1].
--no-track: Не встановлювати «upstream», навіть якщо встановлено параметр конфігурації branch.autoSetupMerge.
--recurse-submodules: ЦЯ ОПЦІЯ Є ЕКСПЕРИМЕНТАЛЬНОЮ! Змушує поточну команду виконувати рекурсію в субмодулях, якщо ввімкнено параметр submodule.propagateBranches. Див. submodule.propagateBranches у git-config[1]. Наразі підтримується лише створення гілок.

При використанні під час створення гілки в суперпроєкті буде створено нову гілку <branch-name>, а всі субмодулі в суперпроєкті — у точці <start-point>. У субмодулях гілка вказуватиме на коміт субмодуля в точці <start-point> суперпроєкту, але інформація про відстеження гілки буде налаштована на основі гілок та віддалених репозиторіїв субмодуля, наприклад: git branch --recurse-submodules topic origin/main створить гілку субмодуля «topic», яка вказує на коміт субмодуля в «origin/main» суперпроекту, але відстежує «origin/main» субмодуля.
--set-upstream: Оскільки цей параметр мав заплутаний синтаксис, він більше не підтримується. Будь ласка, використовуйте замість нього --track або --set-upstream-to.
-u <upstream>
--set-upstream-to=<upstream>: Встановіть інформацію про відстеження для <назва-гілки> так, щоб <upstream> вважалася батьківською гілкою для <назва-гілки>. Якщо <назва-гілки> не вказано, типовим значенням буде поточна гілка.
--unset-upstream: Видалити інформацію про upstream для <назва-гілки>. Якщо гілка не вказана, стандартно використовується поточна гілка.
--edit-description: Відкрийте редактор і відредагуйте текст, щоб пояснити, для чого призначена гілка, щоб її використовували інші команди (наприклад, format-patch, request-pull та merge (якщо увімкнено)). Можна використовувати багаторядкові пояснення.
--contains [<коміт>]: Перераховувати лише гілки, що містять <коміт> (HEAD, якщо не вказано). Мається на увазі --list.
--no-contains [<коміт>]: Перелічувати лише гілки, що не містять <коміт> (HEAD, якщо не вказано). Мається на увазі --list.
--merged [<коміт>]: Перелічувати лише гілки, вершини яких доступні з <коміт> (HEAD, якщо не вказано). Мається на увазі --list.
--no-merged [<коміт>]: Перелічувати лише гілки, вершини яких недоступні з <коміт> (HEAD, якщо не вказано). Має на увазі --list.
--points-at <обʼєкт>: Перелічувати лише гілки <обʼєкта>.
--format <формат>: Рядок, що інтерполює %(імʼя_поля) на основі посилання на гілку, яке відображається, та обʼєкта, на який воно вказує. <формат> відповідає формату, описаному в git-for-each-ref[1].
<назва-гілки>: Назва гілки для створення або видалення. Нова назва гілки має пройти всі перевірки, визначені в git-check-ref-format[1]. Деякі з цих перевірок можуть обмежувати кількість символів, дозволених у назві гілки.
<start-point>: Новий заголовок гілки вказуватиме на цей коміт. Його можна вказати як назву гілки, ідентифікатор коміту або тег. Якщо цей параметр пропущено, замість нього буде використано поточний HEAD.
<стара-гілка>: Назва наявної гілки. Якщо цей параметр пропущено, замість нього буде використано назву поточної гілки.
<нова-гілка>: Нова назва наявної гілки. Застосовуються ті ж обмеження, що й для <назва-гілки>.

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

pager.branch враховується лише під час перерахування гілок, тобто коли використовується або мається на увазі --list. Типово використовується pager. Див. git-config[1].

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

branch.autoSetupMerge

Вказує командам git branch, git switch та git checkout створювати нові гілки таким чином, щоб команда git-pull[1] могла правильно об’єднати зміни, починаючи з гілки-відправної точки. Зверніть увагу, що навіть якщо цей параметр не вказано, таку поведінку можна вибрати для кожної гілки окремо за допомогою параметрів --track та --no-track. Стандартним значенням цього параметра є true. Допустимі значення:

false: автоматичне налаштування не виконується
true: автоматичне налаштування виконується, якщо початковою точкою є гілка з віддаленим відстеженням
always: автоматичне налаштування виконується, якщо початковою точкою є локальна гілка або гілка, що відстежує віддалену гілку
inherit: якщо початкова точка має налаштування відстеження, вони копіюються до нової гілки
simple: автоматичне налаштування виконується лише в тому випадку, якщо початковою точкою є віддалена гілка, а нова гілка має таку саму назву, як і віддалена гілка.

branch.autoSetupRebase

Коли за допомогою команд git branch, git switch або git checkout створюється нова гілка, яка відстежує іншу гілку, ця змінна вказує Git налаштувати операцію pull на rebase замість merge (див. branch.<name>.rebase). Допустимі значення:

never: rebase ніколи автоматично не встановлюється в значення true.
local: rebase встановлюється в значення true для відстежуваних гілок інших локальних гілок.
remote: rebase встановлюється в значення true для відстежуваних гілок гілок дистанційного відстеження.
always: rebase буде встановлено у true для всіх відстежуваних гілок.

Детальніше про те, як налаштувати гілку для відстеження іншої гілки, див. branch.autoSetupMerge. Типовим значенням цього параметра є never.

branch.sort

Ця змінна визначає порядок сортування гілок під час їх перегляду за допомогою команди git-branch[1]. Якщо не вказано опцію --sort=<value>, як стандартне значення буде використано значення цієї змінної. Див. git-for-each-ref[1] «Назви полів» для ознайомлення з допустимими значеннями.

branch.<name>.remote

Коли ви перебуваєте в гілці <name>, це вказує командам git fetch та git push, з якого віддаленого сервера слід завантажувати дані або на який їх надсилати. Віддалений сервер для надсилання даних можна перевизначити за допомогою параметра remote.pushDefault (для всіх гілок). Віддалений сервер для надсилання даних для поточної гілки можна додатково перевизначити за допомогою параметра branch. <name>.pushRemote. Якщо віддалений сервер не налаштований, або якщо ви не перебуваєте в жодній гілці, а в репозиторії визначено більше одного віддаленого сервера, зазвичай для завантаження використовується origin, а для надсилання — remote.pushDefault. Крім того, . (крапка) — це поточний локальний репозиторій (репозиторій з крапкою), див. останню примітку щодо branch.<name>.merge нижче.

branch.<name>.pushRemote

Перебуваючи у гілці <name>, ця опція замінює значення branch.<name>.remote під час надсилання. Вона також замінює remote.pushDefault для надсилання з гілки <name>. Коли ви завантажуєте з одного місця (наприклад, вашого upstream) і надсилаєте в інше місце (наприклад, у власний репозиторій для публікації), вам слід встановити remote.pushDefault, щоб вказати віддалений сервер для надсилання для всіх гілок, і використовувати цю опцію, щоб замінити це значення для конкретної гілки.

branch.<name>.merge

Разом із branch.<name>.remote визначає гілку-джерело для вказаної гілки. Вказує командам git fetch/git pull/git rebase, яку гілку слід об’єднати, а також може впливати на команду git push (див. push.default). Перебуваючи в гілці <name>, вказує команді git fetch стандартне значення refspec, яке слід позначити для об’єднання в FETCH_HEAD. Значення обробляється як віддалена частина refspec і має відповідати ref, який завантажується з віддаленого репозиторію, вказаного branch.<name>.remote. Інформація про злиття використовується git pull (який спочатку викликає git fetch) для пошуку стандартної гілки для злиття. Без цієї опції git pull стандартно зливає перший завантажений refspec. Вкажіть кілька значень, щоб отримати злиття «octopus». Якщо ви хочете налаштувати git pull так, щоб він зливав у <name> з іншої гілки в локальному репозиторії, ви можете вказати branch.<name>.merge на бажану гілку та використовувати відносний шлях . (крапка) для branch.<name>.remote.

branch.<name>.mergeOptions

Встановлює стандартні параметри для злиття у гілку <name>. Синтаксис та підтримувані параметри відповідають тим, що використовуються у команді git-merge[1], однак значення параметрів, що містять пробіли, наразі не підтримуються.

branch.<name>.rebase

Якщо встановлено, під час виконання команди git pull гілку <name> буде перебазовано на вершину завантаженої гілки замість стандартно злиття з гілкою зі стандартного віддаленого репозиторію. Щоб виконати цю дію незалежно від конкретної гілки, див. параметр pull.rebase.

У разі використання команди merges (або просто m) передайте опцію --rebase-merges команді git rebase, щоб локальні коміти злиття були включені в перебазування (детальніше див. git-rebase[1]).

Якщо значення дорівнює interactive (або просто i), перебазування виконується в інтерактивному режимі.

УВАГА: ця операція може бути небезпечною; не використовуйте її, якщо не розумієте всіх наслідків (детальніше див. git-rebase[1]).

branch.<name>.description

Опис гілки можна редагувати за допомогою команди git branch --edit-description. Опис гілки автоматично додається до супровідного листа команди format-patch або до резюме команди request-pull.

ПРИКЛАДИ

Почати розробку з відомого тегу

$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
$ cd my2.6
$ git branch my2.6.14 v2.6.14   (1)
$ git switch my2.6.14

Цей крок та наступний можна обʼєднати в один за допомогою "checkout -b my2.6.14 v2.6.14".

Видалити непотрібну гілку

$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
$ git branch -d -r origin/todo origin/html origin/man   (1)
$ git branch -D test                                    (2)

Видалить гілки віддаленого відстеження "todo", "html" та "man". Наступні команди git fetch або git pull знову їх створить, якщо ви не налаштуєте їх інакше. Див. git-fetch[1].
Видалить гілку "test", навіть якщо гілка "master" (або будь-яка гілка, що наразі активна) не містить усіх комітів з гілки test.

Перелік гілок з конкретного віддаленого сервера

$ git branch -r -l '<remote>/<pattern>'                 (1)
$ git for-each-ref 'refs/remotes/<remote>/<pattern>'    (2)

Використання параметра -a призведе до об’єднання <remote> з будь-якими локальними гілками, префікс яких збігається з шаблоном <remote>.
for-each-ref може приймати широкий спектр опцій. Див. git-for-each-ref[1]

Зазвичай шаблони треба брати в лапки.

ПРИМІТКИ

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

Опції --contains, --no-contains, --merged та --no-merged виконують чотири повʼязані, але різні функції:

--contains <коміт> використовується для пошуку всіх гілок, яким потрібно буде приділити особливу увагу, якщо <коміт> буде перебазовано або змінено, оскільки ці гілки містять вказаний <коміт>.
--no-contains <коміт> є інверсією цього, тобто гілки, які не містять зазначеного <коміт>.
--merged використовується для пошуку всіх гілок, які можна безпечно видалити, оскільки ці гілки повністю містяться в HEAD.
--no-merged використовується для пошуку гілок, які є кандидатами для обʼєднання з HEAD, оскільки ці гілки не повністю містяться в HEAD.

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

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

ДИВ. ТАКОЖ

git-check-ref-format[1], git-fetch[1], git-remote[1], "Розуміння історії: Що таке гілка?" у Посібнику користувача Git.

Частина набору 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