Git

git-push last updated in 2.48.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-receive-pack[1].

Коли в командному рядку не вказано, куди надсилати дані, за допомогою аргументу <repository>, для визначення місця надсилання використовується конфігурація branch.*.remote для поточної гілки. Якщо конфігурація відсутня, за замовчуванням використовується значення origin.

Коли в командному рядку не вказано, що надсилати за допомогою аргументів <refspec>... або опцій --all, --mirror, --tags, команда знаходить значення <refspec> за замовчуванням, звертаючись до конфігурації remote.*.push, і якщо воно не знайдено, враховує конфігурацію push.default, щоб вирішити, що надсилати (див. git-config[1] для значення push.default).

Коли ні в командному рядку, ні в конфігурації не вказано, що потрібно надсилати, використовується поведінка за замовчуванням, яка відповідає значенню simple для push.default: поточна гілка надсилається до відповідної гілки вище за течією, але як захід безпеки надсилання переривається, якщо гілка вище за течією має таку ж назву, як і локальна.

ВАРІАНТИ

<repository>

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

<refspec>…

Вкажіть, яке посилання призначення оновлювати за допомогою якого вихідного об’єкта. Формат параметра <refspec> – це необов’язковий знак плюса +, за яким іде вихідний об’єкт <src>, далі двокрапка :, а потім посилання призначення <dst>.

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

<dst> вказує, яке посилання на віддаленій стороні оновлюється цим надсиланням. Тут не можна використовувати довільні вирази, має бути назване фактичне посилання. Якщо git push [<repository>] без аргументу <refspec> встановлено на оновлення деякого посилання в пункті призначення за допомогою <src> з конфігураційною змінною remote.<repository>.push, частину :<dst> можна пропустити – таке надсилання оновить посилання, яке <src> зазвичай оновлює без будь-яких <refspec> у командному рядку. В іншому випадку, відсутність :<dst> означає оновлення того самого посилання, що й <src>.

Якщо <dst> не починається з refs/ (наприклад, refs/heads/master), ми спробуємо визначити, де в refs/* на цільовому <repository> він знаходиться, виходячи з типу <src>, що надсилається, та того, чи є <dst> неоднозначним.

Якщо <dst> однозначно посилається на посилання на віддаленому репозиторії <repository>, тоді слід надіслати змінну на це посилання.
Якщо <src> розв’язується як посилання, що починається з refs/heads/ або refs/tags/, тоді додайте це посилання до <dst>.
Інші способи вирішення неоднозначностей можуть бути додані в майбутньому, але наразі будь-які інші випадки призведуть до помилки, яка вкаже, що ми спробували, і, залежно від конфігурації advice.pushUnqualifiedRefname (див. git-config[1]), підкаже, до яких посилань/простіру імен ви, можливо, хотіли надіслати зміни.

Об’єкт, на який посилається <src>, використовується для оновлення посилання <dst> на віддаленому боці. Дозволено це залежить від того, де в refs/* знаходиться посилання <dst>, як детально описано нижче. У цих розділах "оновлення" означає будь-які зміни, крім видалення, які, як зазначено в наступних кількох розділах, обробляються по-різному.

Простір імен refs/heads/* прийматиме лише об’єкти комітів та оновлення, лише якщо їх можна перемотати вперед.

Простір імен refs/tags/* прийматиме будь-які типи об’єктів (як коміти, дерева та блоби можна позначати тегами), а будь-які їх оновлення будуть відхилені.

Можна переміщувати об’єкт будь-якого типу до будь-якого простору імен поза refs/{tags,heads}/*. У випадку тегів та комітів, вони будуть розглядатися як коміти всередині refs/heads/* для визначення того, чи дозволено оновлення.

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

Об’єкти Tree та blob поза межами refs/{tags,heads}/* будуть оброблятися так само, як якщо б вони знаходилися всередині refs/tags/*, будь-яке їх оновлення буде відхилено.

Усі описані вище правила щодо того, що не дозволено як оновлення, можна змінити, додавши необов’язковий початковий символ + до специфікації посилань (або використовуючи опцію командного рядка --force). Єдиним винятком є те, що жодна кількість форсування не змусить простір імен refs/heads/* приймати об’єкт без коміту. Хуки та конфігурація також можуть змінювати або перевизначати ці правила, див., наприклад, receive.denyNonFastForwards у git-config[1] та pre-receive та update у githooks[5].

Додавання порожнього <src> дозволяє видалити посилання <dst> з віддаленого репозиторію. Видалення завжди приймаються без початкового символу + у специфікації посилань (або --force), окрім випадків, коли це заборонено конфігурацією або хуками. Див. receive.denyDeletes у git-config[1] та pre-receive та update у githooks[5].

Спеціальна специфікація refspec : (або +: для дозволу оновлень без швидкого перемотування вперед) вказує Git надсилати "відповідні" гілки: для кожної гілки, що існує на локальній стороні, віддалена сторона оновлюється, якщо гілка з такою ж назвою вже існує на віддаленій стороні.

tag <tag> означає те саме, що refs/tags/<tag>:refs/tags/<tag>.

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

--[no-]signed

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

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

--[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.

--[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>, без вказівки очікуваного значення, захистить іменований рефлекс (окремо), якщо його буде оновлено, вимагаючи, щоб його поточне значення було таким самим, як і значення віддаленого рефлексу.

--force-with-lease=<refname>:<expect> захистить іменований рефлекс (окремо), якщо його буде оновлено, вимагаючи, щоб його поточне значення було таким самим, як зазначене значення <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              # оновити "головний" віддалено
git tag base master    # позначте нашу базову точку
git rebase -i master   # переписати деякі коміти
git push --force-with-lease=master:base master:master

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

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

-f

--force

Зазвичай команда відмовляється оновлювати віддалене посилання, яке не є предком локального посилання, що використовується для його перезапису. Також, коли використовується опція --force-with-lease, команда відмовляється оновлювати віддалене посилання, поточне значення якого не відповідає очікуваному.

Цей прапорець вимикає ці перевірки та може призвести до втрати комітів віддаленим репозиторієм; використовуйте його обережно.

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

--[no-]force-if-includes

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

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

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

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

--repo=<repository>

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

-u

--set-upstream

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

--[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 або використання --no-recurse-submodules можна використовувати для перевизначення змінної конфігурації push.recurseSubmodules, коли рекурсія підмодуля не потрібна.

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

--[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-адреси як аргумент <repository> можна використовувати назву одного з наступних:

віддалений сервер у файлі конфігурації 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> is required; #<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 push" залежить від використаного методу передачі; у цьому розділі описано вивід під час надсилання даних через протокол Git (локально або через ssh).

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

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

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

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

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

прапор

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

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

короткий зміст

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

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

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

з

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

до

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

причина

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

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

Коли оновлення змінює гілку (або, загалом, посилання), яка раніше вказувала на коміт 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