Git

git-push last updated in 2.52.0

НАЗВА

git-push - Оновлення віддалених посилань разом із пов’язаними об’єктами

СИНОПСИС

git push [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
	 [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
	 [-u | --set-upstream] [-o <string> | --push-option=<string>]
	 [--[no-]signed | --signed=(true|false|if-asked)]
	 [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
	 [--no-verify] [<repository> [<refspec>…]]

ОПИС

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

Найпростіший спосіб надсилання змін – це git push <віддалена> <гілка>. git push origin main надішле локальну гілку main до гілки main на віддаленій гілці з назвою origin.

Аргумент <repository> за замовчуванням використовує значення основного репозиторію (upstream) для поточної гілки або origin, якщо основного репозиторію немає.

Щоб вирішити, які гілки, теги чи інші посилання надсилати, Git використовує (у порядку пріоритету):

Аргумент(и) <refspec> (наприклад, main у git push origin main) або опції --all, --mirror або --tags
Конфігурація remote.<назва>.push для репозиторію, до якого надсилається
Конфігурація push.default. Значення за замовчуванням — push.default=simple, що надсилатиме зміни до гілки з такою ж назвою, як і поточна гілка. Дивіться розділ CONFIGURATION нижче для отримання додаткової інформації про push.default.

Команда git push може завершитися невдало, якщо ви не встановили основний напрямок (upstream) для поточної гілки, залежно від значення push.default. Дивіться розділ UPSTREAM BRANCHES нижче, щоб дізнатися більше про те, як налаштувати та використовувати основні напрямки (upstream).

Ви можете створювати цікаві речі в репозиторії щоразу, коли ви до нього надсилаєте зміни, встановивши там «перехоплювачі». Дивіться документацію для git-receive-pack[1].

ОПЦІЇ

<репозиторій>

«Віддалене» сховище, яке є місцем призначення для операції надсилання. Цей параметр може бути або URL-адресою (див. розділ GIT URLS нижче), або іменем віддаленого сховища (див. розділ REMOTES нижче).

<refspec>...

Вкажіть, яке посилання на призначення оновлювати за допомогою якого вихідного об’єкта.

Формат для специфікації посилань — [+]<source>[:<dst>], наприклад main, main:other або HEAD^:refs/heads/main.

<src> часто є назвою локальної гілки для надсилання, але це може бути будь-який довільний "SHA-1 вираз" (див. gitrevisions[7]).

<dst> визначає, яке посилання оновлювати на віддаленій стороні. Це має бути назва гілки, тегу або іншого посилання, а не довільний вираз.

Символ + необов’язковий і виконує ту саму функцію, що й --force.

Ви можете написати специфікацію посилань, використовуючи повністю розгорнуту форму (наприклад, refs/heads/main:refs/heads/main), яка вказує точне джерело та призначення, або у коротшій формі (наприклад, main або main:other). Ось правила розгортання специфікацій посилань, а також різні інші спеціальні форми специфікацій посилань:

<src> без :<dst> означає оновлення того самого посилання, що й <src>, якщо конфігурація remote.<repository>.push не вказує на інше <dst>. Наприклад, якщо main є гілкою, то специфікація посилань main розширюється до main:refs/heads/main.
Якщо <dst> однозначно посилається на посилання на віддаленому репозиторії <repository>, то розгорніть його до цього посилання. Наприклад, якщо v1.0 є тегом на віддаленому репозиторії, то HEAD:v1.0 розгортається до HEAD:refs/tags/v1.0.
Якщо <src> розв’язується як посилання, що починається з refs/heads/ або refs/tags/, то додайте це до <dst>. Наприклад, якщо main є гілкою, то main:other розширюється до main:refs/heads/other
Спеціальна специфікація refspec : (або +: для дозволу оновлень без швидкого перемотування вперед) вказує Git надсилати "відповідні" гілки: для кожної гілки, що існує на локальній стороні, віддалена сторона оновлюється, якщо гілка з такою ж назвою вже існує на віддаленій стороні.
<src> може містити * для позначення простого збігу зі шаблоном. Це працює як глобальний елемент, який відповідає будь-якому посиланню, що відповідає шаблону. У <src> та <dst> має бути лише одна *. Це зіставлятиме посилання з місцем призначення, замінюючи * вмістом, що відповідає джерелу. Наприклад, refs/heads/*:refs/heads/* відправить усі гілки.
Специфікація посилань, що починається з ^, є негативною специфікацією посилань. Це визначає посилання, які потрібно виключити. Посилання вважатиметься таким, що відповідає, якщо воно відповідає принаймні одній позитивній специфікації посилань і не відповідає жодній негативній специфікації посилань. Негативні специфікації посилань можуть бути специфікаціями посилань шаблонів. Вони повинні містити лише <src>. Повністю написані шістнадцяткові назви об’єктів також не підтримуються. Наприклад, git push origin refs/heads/*' ^refs/heads/dev-*' надішле всі гілки, крім тих, що починаються з dev-
Якщо <src> порожній, це видаляє посилання <dst> з віддаленого репозиторію. Наприклад, git push origin :dev видалить гілку dev.
tag <tag> розширюється до refs/tags/<tag>:refs/tags/<tag>. Технічно це спеціальний синтаксис для git push, а не специфікація посилань (refspec), оскільки в git push origin tag v1.0 аргументи tag та v1.0 є окремими.
Якщо специфікацію посилань не можна однозначно розширити, виведіть помилку із зазначенням того, що було зроблено, і залежно від конфігурації advice.pushUnqualifiedRefname (див. git-config[1]) запропонуйте, до яких посилань/простір імен ви, можливо, хотіли б надіслати дані.

Не всі оновлення дозволені: див. деталі в розділі ПРАВИЛА НАДСИЛАННЯ нижче.

--all

--branches

Додати всі гілки (тобто посилання під refs/heads/); не можна використовувати з іншими <refspec>.

--prune

Видаліть віддалені гілки, які не мають локального аналога. Наприклад, віддалена гілка tmp буде видалена, якщо локальна гілка з такою ж назвою більше не існує. Це також враховує специфікації посилань, наприклад, git push --prune remote refs/heads/*:refs/tmp/* гарантує, що віддалена гілка refs/tmp/foo буде видалена, якщо refs/heads/foo не існує.

--mirror

Замість того, щоб називати кожне посилання для надсилання, вказує, що всі посилання в refs/ (що включає, але не обмежується refs/heads/, refs/remotes/ та refs/tags/) будуть відображені у віддаленому репозиторії. Новостворені локальні посилання будуть надсилатися на віддалений кінець, локально оновлені посилання будуть примусово оновлюватися на віддаленому кінці, а видалені посилання будуть видалятися з віддаленого кінця. Це значення за замовчуванням, якщо встановлено параметр конфігурації remote.<remote>.mirror.

-n

--dry-run

Зробіть усе, крім надсилання оновлень.

--porcelain

Створити машинозчитуваний вивід. Рядок стану виводу для кожного посилання буде розділений табуляцією та відправлений на stdout замість stderr. Будуть надані повні символічні імена посилань.

-d

--delete

Усі перелічені посилання видаляються з віддаленого репозиторію. Це те саме, що й додавати перед усіма посиланнями двокрапку.

--tags

Усі посилання з тегів refs/tags надсилаються, окрім специфікацій посилань, явно перелічених у командному рядку.

--follow-tags

Надсилати всі посилання, які були б надсилані без цієї опції, а також надсилати анотовані теги в refs/tags, які відсутні на віддаленому сервері, але вказують на елементи типу commit, до яких можна дістатися з посилань, що надсилаються. Це також можна вказати за допомогою змінної конфігурації push.followTags. Для отримання додаткової інформації див. push.followTags у git-config[1].

--signed

--no-signed

--signed=(true|false|if-asked)

Підписати push-запит GPG для оновлення посилань на стороні приймача, щоб дозволити перевірку хуками та/або запис у журнал. Можливі значення:

false
--no-signed: жодної спроби підписання не буде зроблено.
true
--signed: Надсилання не вдасться, якщо сервер не підтримує підписані повідомлення.
if-asked: підписувати тоді і тільки тоді, коли сервер підтримує підписані push-повідомлення. Push-повідомлення також завершиться невдачею, якщо фактичний виклик gpg --sign завершиться невдачею. Див. git-receive-pack[1] для отримання детальної інформації про приймаючу сторону.

--atomic

--no-atomic

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

-o <option>

--push-option=<option>

Передати заданий рядок на сервер, який передає його як до, так і до перехоплювачів після отримання. Заданий рядок не повинен містити символів NUL або LF. Якщо задано кілька параметрів --push-option=<опція>, усі вони надсилаються іншій стороні в порядку, зазначеному в командному рядку. Якщо --push-option=<опція> не задано в командному рядку, замість них використовуються значення змінної конфігурації push.pushOption.

--receive-pack=<git-receive-pack>

--exec=<git-receive-pack>

Шлях до програми git-receive-pack на віддаленому кінці. Іноді корисно під час надсилання даних до віддаленого репозиторію через ssh, якщо у вас немає програми в каталозі за замовчуванням $PATH.

--force-with-lease

--no-force-with-lease

--force-with-lease=<refname>

--force-with-lease=<refname>:<expect>

Зазвичай, git push відмовляється оновлювати віддалене посилання, яке не є предком локального посилання, що використовується для його перезапису.

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

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

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

Використання лише параметра --force-with-lease, без уточнення деталей, захистить усі віддалені посилання, які будуть оновлені, вимагаючи, щоб їхнє поточне значення було таким самим, як і значення гілки remote-tracking, яку ми для них маємо.

--force-with-lease=<refname>, без вказівки очікуваного значення, захистить <refname> (окремо), якщо його буде оновлено, вимагаючи, щоб його поточне значення було таким самим, як і гілка віддаленого відстеження, яку ми для нього маємо.

--force-with-lease=<refname>:<expect> захистить <refname> (окремо), якщо його буде оновлено, вимагаючи, щоб його поточне значення було таким самим, як зазначене значення <expect> (яке може відрізнятися від гілки віддаленого відстеження, яку ми маємо для refname, або нам навіть не потрібно мати таку гілку віддаленого відстеження, коли використовується ця форма). Якщо <expect> є порожнім рядком, то іменований рефлекс ще не повинен існувати.

Зверніть увагу, що всі форми, крім --force-with-lease=<refname>:<expect>, які явно вказують очікуване поточне значення посилання, все ще є експериментальними, і їхня семантика може змінюватися в міру набуття досвіду роботи з цією функцією.

--no-force-with-lease скасує всі попередні --force-with-lease у командному рядку.

Загальне зауваження щодо безпеки: використання цього параметра без очікуваного значення, тобто як --force-with-lease або --force-with-lease=<refname>, дуже погано взаємодіє з будь-чим, що неявно запускає git fetch на віддаленому комп’ютері, на який потрібно перенести дані у фоновому режимі, наприклад, git fetch origin на вашому репозиторії в cronjob.

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

Якщо ваш редактор або якась інша система виконує git fetch у фоновому режимі, спосіб зменшити це — просто налаштувати інший віддалений доступ:

git remote add origin-push $(git config remote.origin.url)
git fetch origin-push

Тепер, коли фоновий процес виконується git fetch origin, посилання на origin-push не оновлюватимуться, і тому команди типу:

git push --force-with-lease origin-push

Не вийде, якщо ви вручну не запустите git fetch origin-push. Цей метод, звичайно, повністю переможений тим, що виконує git fetch --all, у такому разі вам потрібно буде або вимкнути його, або зробити щось більш нудне, наприклад:

git fetch              # update 'master' from remote
git tag base master    # mark our base point
git rebase -i master   # rewrite some commits
git push --force-with-lease=master:base master:master

Тобто, створіть тег base для версій коду основної розробки, які ви бачили та бажаєте перезаписати, потім перепишіть історію та, нарешті, примусово надішліть зміни до master, якщо віддалена версія все ще знаходиться на рівні base, незалежно від того, до якого значення було оновлено ваш локальний remotes/origin/master у фоновому режимі.

Або ж, якщо вказати --force-if-includes як допоміжний параметр разом з --force-with-lease[=<назва_посилання>] (тобто, не вказуючи, на який саме коміт має вказувати посилання на віддаленій стороні, або які посилання на віддаленій стороні захищаються) під час "push", це перевірить, чи оновлення з посилань віддаленого відстеження, які могли бути неявно оновлені у фоновому режимі, інтегровані локально, перш ніж дозволити примусове оновлення.

-f

--force

Зазвичай, git push відмовляється оновлювати гілку, яка не є предком коміту, що надсилається.

Цей прапорець вимикає цю перевірку, інші перевірки безпеки в PUSH RULES нижче та перевірки в --force-with-lease. Це може призвести до втрати комітів віддаленим репозиторієм; використовуйте його обережно.

Зверніть увагу, що --force застосовується до всіх посилань, що надсилаються, тому його використання з push.default, встановленим на matching, або з кількома місцями призначення надсилання, налаштованими за допомогою remote.<name>.push, може перезаписати посилання, відмінні від поточної гілки (включаючи локальні посилання, які знаходяться строго за їхнім віддаленим аналогом). Щоб примусово надсилати дані лише до однієї гілки, використовуйте + перед специфікацією посилань для надсилання (наприклад, git push origin +master, щоб примусово надсилати дані до гілки master). Дивіться розділ <refspec>... вище для отримання детальної інформації.

--force-if-includes

--no-force-if-includes

Примусово оновлювати, лише якщо кінчик посилання віддаленого відстеження було інтегровано локально.

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

Якщо опцію передано без вказівки --force-with-lease або вказано разом з --force-with-lease=<refname>:<expect>, це "no-op".

Вказівка --no-force-if-includes вимикає цю поведінку.

--repo=<repository>

Цей параметр еквівалентний аргументу <репозиторій>. Якщо вказано обидва, аргумент командного рядка має пріоритет.

-u

--set-upstream

Для кожної гілки, яка є актуальною або успішно завантаженою, додайте посилання на початковий етап (відстеження), яке використовується командою git-pull[1] без аргументів та іншими командами. Для отримання додаткової інформації див. branch.<name>.merge у git-config[1].

--thin

--no-thin

Ці опції передаються до git-send-pack[1]. Тонка передача значно зменшує обсяг даних, що надсилаються, коли відправник і одержувач використовують багато спільних об’єктів. Значення за замовчуванням — --thin.

-q

--quiet

Пригнічувати весь вивід, включаючи список оновлених посилань, якщо не виникає помилка. Прогрес не повідомляється до стандартного потоку помилок.

-v

--verbose

Виконуйте багатослівно.

--progress

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

--no-recurse-submodules

--recurse-submodules=(check|on-demand|only|no)

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

check: Git перевірить, чи всі коміти підмодулів, які змінилися в ревізіях, що надсилаються, доступні принаймні на одному віддаленому комп’ютері підмодуля. Якщо будь-які коміти відсутні, надсилання буде перервано та завершиться з ненульовим статусом.
on-demand: Усі підмодулі, що змінилися в ревізіях, що будуть надіслані, будуть надіслані. Якщо on-demand не зміг надіслати всі необхідні ревізії, він також буде перервано та завершиться з ненульовим статусом.
only: усі підмодулі будуть завантажені, поки суперпроект залишиться незавантаженим.
no: перевизначає змінну конфігурації push.recurseSubmodules, коли рекурсія підмодуля не потрібна. Подібно до використання --no-recurse-submodules.

Під час використання on-demand або only, якщо підмодуль має конфігурацію push.recurseSubmodules=(on-demand|only) або submodule.recurse, відбуватиметься подальша рекурсія. У цьому випадку only розглядається як on-demand.

--verify

--no-verify

Увімкнути/вимкнути хук перед надсиланням (див. githooks[5]). Значення за замовчуванням — --verify, що дає хуку можливість запобігти надсиланню. З --no-verify хук повністю обходиться.

-4

--ipv4

Використовуйте лише адреси IPv4, ігноруючи адреси IPv6.

-6

--ipv6

Використовуйте лише адреси IPv6, ігноруючи адреси IPv4.

GIT URLS

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

Git підтримує протоколи ssh, git, http та https (крім того, для отримання даних можна використовувати ftp та ftps, але це неефективно та застаріло; не використовуйте їх).

Власний транспорт (тобто URL-адреса git://) не виконує автентифікацію та має використовуватися з обережністю в незахищених мережах.

З ними можна використовувати такі синтаксичні схеми:

ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>
git://<host>[:<port>]/<path-to-git-repo>
http[s]://<host>[:<port>]/<path-to-git-repo>
ftp[s]://<host>[:<port>]/<path-to-git-repo>

Альтернативний синтаксис, подібний до scp, також може використовуватися з протоколом ssh:

[<user>@]<host>:/<path-to-git-repo>

Цей синтаксис розпізнається лише за відсутності склесних риск перед першою двокрапкою. Це допомагає розрізнити локальний шлях, який містить двокрапку. Наприклад, локальний шлях foo:bar можна вказати як абсолютний шлях або ./foo:bar, щоб уникнути неправильної інтерпретації як URL-адреси ssh.

Протоколи ssh та git додатково підтримують розширення ~<ім'я користувача>:

ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>
git://<host>[:<port>]/~<user>/<path-to-git-repo>
[<user>@]<host>:~<user>/<path-to-git-repo>

Для локальних репозиторіїв, які також підтримуються Git нативно, можна використовувати такі синтаксиси:

/path/to/repo.git/
file:///path/to/repo.git/

Ці два синтаксиси здебільшого еквівалентні, за винятком клонування, коли перший передбачає опцію --local. Див. git-clone[1] для отримання детальної інформації.

Команди git clone, git fetch та git pull, але не git push, також прийматимуть відповідний файл пакета. Див. git-bundle[1].

Коли Git не знає, як обробляти певний транспортний протокол, він намагається використати віддалений помічник remote-<transport>, якщо такий існує. Щоб явно запитати віддалений помічник, можна використовувати наступний синтаксис:

<transport>::<address>

де <адреса> може бути шляхом, сервером та шляхом або довільним рядком, подібним до URL-адреси, який розпізнає конкретний викликаний віддалений помічник. Див. gitremote-helpers[7] для отримання детальної інформації.

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

	[url "<actual-url-base>"]
		insteadOf = <other-url-base>

Наприклад, з цим:

	[url "git://git.host.xz/"]
		insteadOf = host.xz:/path/to/
		insteadOf = work:

URL-адреса типу "work:repo.git" або "host.xz:/path/to/repo.git" буде перезаписана в будь-якому контексті, який приймає URL-адресу як "git://git.host.xz/repo.git".

Якщо ви хочете переписати URL-адреси лише для push-розсилок, ви можете створити розділ конфігурації:

	[url "<actual-url-base>"]
		pushInsteadOf = <other-url-base>

Наприклад, з цим:

	[url "ssh://example.org/"]
		pushInsteadOf = git://example.org/

URL-адреса типу "git://example.org/path/to/repo.git" буде переписана на "ssh://example.org/path/to/repo.git" для надсилання змін, але для отримання змін все одно використовуватиметься оригінальна URL-адреса.

ПУЛЬТИ КЕРУВАННЯ

Замість URL-адреси як аргумент <репозиторій> можна використовувати назву одного з наступних:

віддалений сервер у файлі конфігурації Git: $GIT_DIR/config,
файл у каталозі $GIT_DIR/remotes, або
файл у каталозі $GIT_DIR/branches.

Усі вони також дозволяють вам пропустити refspec з командного рядка, оскільки кожен з них містить refspec, який git використовуватиме за замовчуванням.

Назва віддаленого пристрою у файлі конфігурації

Ви можете вказати назву віддаленого сервера, який ви раніше налаштували за допомогою git-remote[1], git-config[1] або навіть вручну редагуючи файл $GIT_DIR/config. URL-адреса цього віддаленого сервера буде використана для доступу до репозиторію. Специфікація посилань цього віддаленого сервера буде використовуватися за замовчуванням, якщо ви не вкажете специфікацію посилань у командному рядку. Запис у файлі конфігурації виглядатиме так:

	[remote "<name>"]
		url = <URL>
		pushurl = <pushurl>
		push = <refspec>
		fetch = <refspec>

<pushurl> використовується лише для надсилання змін. Він необов’язковий і за замовчуванням має значення <URL>. Надсилання змін на віддалений сервер впливає на всі визначені адреси pushurl або всі визначені URL-адреси, якщо жодної адреси pushurl не визначено. Однак Fetch буде отримувати дані лише з першої визначеної URL-адреси, якщо визначено кілька URL-адрес.

Іменований файл у `$GIT_DIR/remotes`

Ви можете вказати назву файлу в $GIT_DIR/remotes. URL-адреса з цього файлу буде використана для доступу до репозиторію. Специфікація посилань у цьому файлі буде використовуватися за замовчуванням, якщо ви не вкажете специфікацію посилань у командному рядку. Цей файл повинен мати такий формат:

	URL: один із наведених вище форматів URL-адрес
	Push: <refspec>
	Pull: <refspec>

Рядки Push: використовуються командами git push, а рядки Pull: використовуються командами git pull та git fetch. Для додаткових зіставлень гілок можна вказати кілька рядків Push: та Pull:.

Іменований файл у `$GIT_DIR/branches`

Ви можете вказати назву файлу в $GIT_DIR/branches. URL-адреса з цього файлу буде використана для доступу до репозиторію. Цей файл повинен мати такий формат:

	<URL>#<head>

<URL> обов’язковий; #<head> необов’язковий.

Залежно від операції, git використовуватиме одну з наступних специфікацій refspecs, якщо ви не вкажете її в командному рядку. <branch> це назва цього файлу в $GIT_DIR/branches, а <head> за замовчуванням має значення master.

git fetch uses:

	refs/heads/<head>:refs/heads/<branch>

git push uses:

	HEAD:refs/heads/<head>

ВИГЛЯДНІ ФІЛІЇ

Гілки в Git можуть за бажанням мати віддалену гілку, що знаходиться вище за тегом. Git за замовчуванням використовує гілку, що знаходиться вище за тегом, для віддалених операцій, наприклад:

Це значення за замовчуванням для git pull або git fetch без аргументів.
Це значення за замовчуванням для git push без аргументів, за деякими винятками. Наприклад, ви можете використовувати опцію branch.<name>.pushRemote для надсилання даних на інший віддалений сервер, ніж той, з якого ви отримуєте дані, і за замовчуванням з push.default=simple гілка, яку ви налаштовуєте, повинна мати таку саму назву.
Різні команди, зокрема git checkout та git status, покажуть вам, скільки комітів було додано до вашої поточної гілки та основної гілки з моменту відгалуження від неї, наприклад, «Ваша гілка та origin/main розійшлися та мають 2 та 3 різні коміти відповідно».

Дані основного потоку зберігаються у файлі .git/config, у полях "remote" та "merge". Наприклад, якщо основним потоком для main є origin/main:

[branch "main"]
   remote = origin
   merge = refs/heads/main

Ви можете явно встановити гілку upstream за допомогою git push --set-upstream <віддалена> <гілка>, але Git часто автоматично встановить її за вас, наприклад:

Коли ви клонуєте репозиторій, Git автоматично встановить основний напрямок (upstream) для гілки за замовчуванням.
Якщо у вас встановлено опцію конфігурації push.autoSetupRemote, git push автоматично встановить розгортання під час першого надсилання гілки.
Перевірка гілки віддаленого відстеження за допомогою git checkout <branch> автоматично створить локальну гілку з цією назвою та встановить основний хід (upstream) на віддалену гілку.

Note	Гілки вище за течією іноді називають «інформацією відстеження», наприклад, «встановити інформацію відстеження гілки».

ВИХІД

Вивід команди "git push" залежить від використаного методу передачі; у цьому розділі описано вивід під час надсилання даних через протокол Git (локально або через ssh).

Статус push-повідомлення виводиться у табличній формі, де кожен рядок представляє статус окремого посилання. Кожен рядок має такий вигляд:

 <flag> <summary> <from> -> <to> (<reason>)

Якщо використовується --porcelain, то кожен рядок виводу має вигляд:

 <flag> \t <from>:<to> \t <summary> (<reason>)

Статус актуальних посилань відображається лише за використання опції --porcelain або --verbose.

<flag>

Один символ, що вказує на статус посилання:

(простір): для успішно перемотування вперед;
+: для успішного примусового оновлення;
-: для успішно видаленого посилання;
*: для успішно надісланого нового посилання;
!: для судді, який був відхилений або не зміг просунути заявку; та
=: для судді, який був актуальним і не потребував наполегливої праці.

<summary>

Для успішно надісланого посилання, зведення показує старі та нові значення посилання у формі, придатній для використання як аргумент git log (у більшості випадків це <old>..<new>, а <old>...<new> для примусових оновлень без перемотування вперед).

Для невдалого оновлення наведено більше деталей:

відхилено: Git взагалі не намагався надіслати посилання, зазвичай тому, що це не перемотування вперед, і ви не примусово виконали оновлення.
віддалений відхилено: Віддалений кінець відмовив в оновленні. Зазвичай це спричинено перехопленням на віддаленому боці або тим, що віддалений репозиторій має один із наступних параметрів безпеки: receive.denyCurrentBranch (для надсилання до гілки, що перевірена), receive.denyNonFastForwards (для примусових оновлень без перемотування вперед), receive.denyDeletes або receive.denyDeleteCurrent. Див. git-config[1].
віддалений збій: Віддалений кінець не повідомив про успішне оновлення посилання, можливо, через тимчасову помилку на віддаленому боці, розрив мережевого з’єднання або іншу тимчасову помилку.

з

Назва локального посилання, що надсилається, мінус префікс refs/<тип>/. У разі видалення назва локального посилання пропускається.

до

Ім’я віддаленого посилання, що оновлюється, мінус його префікс refs/<тип>/.

причина

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

ПРАВИЛА НАТИСНЕННЯ

Як засіб безпеки, команда git push дозволяє лише певні види оновлень, щоб запобігти випадковій втраті даних на віддаленому комп’ютері.

Оскільки гілки та теги призначені для різних робіт, правила безпеки для надсилання змін до гілки відрізняються від правил для надсилання змін до тегу. У наступних правилах «оновлення» означає будь-які зміни, крім видалення та створення змін. Видалення та створення змін завжди дозволені, окрім випадків, коли це заборонено конфігурацією або перехоплювачами.

Якщо місцем призначення для публікації є гілка (refs/heads/*): дозволені лише оновлення вперед, що означає, що місцем призначення має бути предок вихідного коміту. Джерело має бути комміт.
Якщо місцем призначення для надсилання є тег (refs/tags/*): усі оновлення будуть відхилені. Джерелом може бути будь-який об’єкт.
Якщо місце призначення push-посилання не є гілкою або тегом:
- Якщо джерелом є дерево або блоб-об’єкт, будь-які оновлення будуть відхилені
- Якщо джерелом є тег або об’єкт коміту, дозволено будь-яке оновлення вперед, навіть у випадках, коли перемотується не коміт, а об’єкт тегу, який вказує на новий коміт, що є перемотуванням вперед останнього тегу (або коміту), який він замінює. Заміна тегу на зовсім інший тег також дозволена, якщо він вказує на той самий коміт, а також вставлення очищеного тегу, тобто вставлення коміту, на який вказує існуючий об’єкт тегу, або нового об’єкта тегу, на який вказує існуючий коміт.

Ви можете змінити ці правила, передавши --force або додавши необов’язковий початковий символ + до специфікації посилання. Єдиними винятками є те, що жодна кількість примусового введення не змусить гілку прийняти об’єкт без коміту, а примусове введення не змусить віддалений репозиторій прийняти push-повідомлення, яке він налаштований відхиляти.

Хуки та конфігурація також можуть перевизначати або змінювати ці правила, див., наприклад, receive.denyNonFastForwards та receive.denyDeletes у git-config[1] та pre-receive та update у githooks[5].

ПРИМІТКА ЩОДО ШВИДКОГО ПЕРЕМОТУВАННЯ ВПЕРЕД

Коли оновлення змінює гілку (або, загалом, посилання), яка раніше вказувала на коміт A, щоб вказувати на інший коміт B, це називається оновленням уперед тоді і тільки тоді, коли B є нащадком A.

При швидкому оновленні від A до B, набір комітів, на яких побудовано оригінальний коміт A, є підмножиною комітів, на яких побудовано новий коміт B. Отже, історія не втрачається.

Натомість, оновлення без перемотування вперед призведе до втрати історії. Наприклад, припустимо, що ви та хтось інший почали з одного й того ж коміту X, і ви створили історію, що веде до коміту B, тоді як інша людина створила історію, що веде до коміту A. Історія виглядає так:

      B
     /
 ---X---A

Далі припустимо, що інша людина вже відправила зміни, що призвели до A, назад до оригінального репозиторію, з якого ви отримали оригінальний коміт X.

Надіслані іншою особою зміни оновили гілку, яка раніше вказувала на коміт X, тепер вона вказувала на коміт A. Це перемотування вперед.

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

Команда за замовчуванням не дозволяє оновлення, яке не є перемотуванням вперед, щоб запобігти такій втраті історії.

Якщо ви не хочете втратити свою роботу (історію від X до B) або роботу іншої особи (історію від X до A), вам спочатку потрібно отримати історію з репозиторію, створити історію, яка містить зміни, внесені обома сторонами, та відправити результат назад.

Ви можете виконати "git pull", вирішити потенційні конфлікти та "git push" результат. "git pull" створить коміт злиття C між комітами A та B.

      B---C
     /   /
 ---X---A

Оновлення A з результуючим комітом злиття перенесеться вперед, і ваш push буде прийнято.

Або ж ви можете перебазувати зміни між X та B поверх A за допомогою git pull --rebase та відправити результат назад. Перебазування створить новий коміт D, який будує зміни між X та B поверх A.

      B   D
     /   /
 ---X---A

Знову ж таки, оновлення A цим комітом призведе до перемотування вперед, і ваш push буде прийнято.

Існує ще одна поширена ситуація, коли ви можете зіткнутися з відхиленням без перемотування вперед під час спроби надсилання, і це можливо навіть тоді, коли ви надсилаєте коміт A в репозиторій, куди ніхто інший не надсилає. Після того, як ви самі надішлете коміт A (на першому зображенні в цьому розділі), замініть його на git commit --amend, щоб створити коміт B, і ви спробуєте надсилати його, бо забули, що ви вже надсилали A. У такому випадку, і лише якщо ви впевнені, що ніхто тим часом не отримав ваш попередній коміт A (і не почав збирати поверх нього), ви можете виконати git push --force, щоб перезаписати його. Іншими словами, git push --force — це метод, зарезервований для випадку, коли ви дійсно хочете втратити історію.

ПРИКЛАДИ

git push

Працює аналогічно git push <remote>, де <remote> — це віддалений сервер поточної гілки (або origin, якщо для поточної гілки не налаштовано віддалений сервер).

git push origin

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

Поведінку цієї команди за замовчуванням, коли не вказано <refspec>, можна налаштувати, встановивши опцію push віддаленого пристрою або змінну конфігурації push.default.

Наприклад, щоб за замовчуванням надсилати лише поточну гілку до origin, використовуйте git config remote.origin.push HEAD. Будь-який дійсний <refspec> (як ті, що в прикладах нижче) може бути налаштований як стандартний для git push origin.

git push origin :

Надсилати "відповідні" гілки до origin. Див. <refspec> у розділі OPTIONS вище для опису "відповідних" гілок.

git push origin master

Знайдіть посилання, що відповідає master у вихідному репозиторії (найімовірніше, буде знайдено refs/heads/master), та оновіть те саме посилання (наприклад, refs/heads/master) у репозиторії origin, використовуючи його. Якщо master не існує віддалено, його буде створено.

git push origin HEAD

Зручний спосіб перенести поточну гілку на ту саму назву на віддаленому сервері.

git push mothership master:satellite/master dev:satellite/dev

Використайте посилання на джерело, що відповідає master (наприклад, refs/heads/master), щоб оновити посилання, що відповідає satellite/master (найімовірніше, refs/remotes/satellite/master) у репозиторії mothership; зробіть те саме для dev та satellite/dev.

Дивіться розділ, що описує <refspec>... вище, для обговорення семантики відповідності.

Це емуляція команди git fetch, що виконується на mothership, за допомогою git push, яка виконується у зворотному напрямку, щоб інтегрувати роботу, виконану на satellite, і часто це необхідно, коли ви можете встановити з’єднання лише одним способом (тобто suttelite може підключитися до mothership через ssh, але mothership не може ініціювати з’єднання із suttelite, оскільки останній знаходиться за брандмауером або не використовує sshd).

Після запуску цього git push на машині satellite, вам слід через ssh увійти до mothership та виконати там git merge, щоб завершити емуляцію git pull, яка була запущена на mothership для отримання змін, внесених на satellite.

git push origin HEAD:master

Надсилає поточну гілку до віддаленого посилання, що відповідає master у репозиторії origin. Ця форма зручна для надсилання поточної гілки, не замислюючись про її локальну назву.

git push origin master:refs/heads/experimental

Створіть гілку experimental у репозиторії origin, скопіювавши поточну гілку master. Ця форма потрібна лише для створення нової гілки або тегу у віддаленому репозиторії, коли локальне ім’я та віддалене ім’я відрізняються; в іншому випадку працюватиме лише ім’я посилання.

git push origin :experimental

Знайдіть посилання, що відповідає experimental, у репозиторії origin (наприклад, refs/heads/experimental), та видаліть його.

git push origin +dev:master

Оновіть гілку master оригінального репозиторію гілкою dev, що дозволить оновлення без перемотування вперед. Це може призвести до того, що не посилання на коміти залишаться в оригінальному репозиторії. Розглянемо таку ситуацію, коли перемотування вперед неможливе:

	    o---o---o---A---B  origin/master
		     \
		      X---Y---Z  dev

Вищевказана команда змінить початковий репозиторій на

		      A---B  (безіменна гілка)
		     /
	    o---o---o---X---Y---Z  master

Коміти A та B більше не належатимуть до гілки із символічною назвою, а отже, будуть недоступні. Таким чином, ці коміти будуть видалені командою git gc у вихідному репозиторії.

БЕЗПЕКА

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

Відомі вектори атаки такі:

Жертва надсилає рядки "have", що рекламують ідентифікатори об’єктів, які вона має, але які не призначені для спільного використання, але можуть бути використані для оптимізації передачі, якщо вони також є у вузла. Зловмисник вибирає ідентифікатор об’єкта X для крадіжки та надсилає посилання на X, але не зобов’язаний надсилати вміст X, оскільки жертва вже має його. Тепер жертва вважає, що зловмисник має X, і пізніше надсилає вміст X назад зловмиснику. (Цю атаку найпростіше виконати на сервері, створюючи посилання на X у просторі імен, до якого клієнт має доступ, а потім отримуючи його. Найімовірніший спосіб для сервера виконати це на клієнті - це "злити" X у публічну гілку та сподіватися, що користувач виконає додаткову роботу над цією гілкою та надішле її назад на сервер, не помічаючи злиття.)
Як і в пункті №1, зловмисник вибирає ідентифікатор об’єкта X для крадіжки. Жертва надсилає об’єкт Y, який у зловмисника вже є, а зловмисник хибно стверджує, що має X, а не Y, тому жертва надсилає Y як дельту відносно X. Дельта показує зловмиснику області X, схожі на Y.

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

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

Warning

Missing uk/config/push.adoc

See original version for this content.

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