Git

git-push last updated in 2.53.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, що означає надсилання до гілки з назвою, яка збігається з назвою поточної гілки. Докладнішу інформацію про push.default див. у розділі КОНФІГУРАЦІЯ нижче.

Команда git push може завершитися невдачею, якщо ви не встановили upstream для поточної гілки, залежно від значення push.default. Дивіться розділ ГІЛКИ UPSTREAM нижче, щоб дізнатися більше про те, як налаштувати та використовувати upstream.

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

ОПЦІЇ

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

Репозиторій «remote», який є призначенням операції push. Цим параметром може бути або URL-адреса (див. розділ GIT URLS нижче), або імʼя віддаленого сервера (див. розділ ВІДДАЛЕНІ ЕКЗЕМПЛЯРИ нижче).

<refspec>...

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

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

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

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

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

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

<src> без :<dst> означає оновлення того самого посилання, що й <src>, якщо конфігурація remote.<repository>.push не вказує на інше місце призначення <dst>. Наприклад, якщо main є гілкою, то refspec 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 : (або +: для дозволу оновлень, що не є fast-forward) вказує Git надсилати «відповідні» гілки: для кожної гілки, що існує на локальному боці, віддалена сторона оновлюється, якщо на ній уже існує гілка з такою самою назвою.
<src> може містити символ *, що вказує на просте зіставлення за шаблоном. Це працює як універсальний символ, який зіставляється з будь-яким репозиторієм, що відповідає шаблону. У обох елементах <src> та <dst> має бути лише один символ *. Це дозволить зіставити репозиторії з пунктом призначення шляхом заміни символу * на вміст, знайдений у джерелі. Наприклад, refs/heads/*:refs/heads/* додасть усі гілки.
Refspec, що починається з ^, є негативним refspec. Він визначає посилання, які слід виключити. Посилання вважатиметься таким, що відповідає критеріям, якщо воно відповідає хоча б одному позитивному refspec і не відповідає жодному негативному refspec. Негативні refspec можуть бути шаблонними. Вони повинні містити лише <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 є окремими.
Якщо refspec неможливо однозначно розгорнути, повертається помилка з вказівкою на те, що було спробувано, і, залежно від налаштувань advice.pushUnqualifiedRefname (див. git-config[1]), надається пропозиція щодо того, до якого простіру імен refs/ ви, ймовірно, хотіли здійснити надсилання.

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

--all

--branches

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

--prune

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

--mirror

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

-n

--dry-run

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

--porcelain

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

-d

--delete

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

--tags

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

--follow-tags

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

--signed

--no-signed

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

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

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

--atomic

--no-atomic

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

-o <option>

--push-option=<option>

Передає вказаний рядок на сервер, який передає його як у гачок pre-receive, так і в гачок post-receive. Вказаний рядок не повинен містити символи NUL або LF. Якщо вказано декілька опцій --push-option=<option>, вони всі надсилаються на інший бік у порядку, вказаному в командному рядку. Якщо в командному рядку не вказано жодної опції --push-option=<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 завершується невдачею.

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

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

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

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

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

Зверніть увагу, що всі форми, крім --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 у фоновому режимі, то щоб уникнути цього, достатньо просто налаштувати ще один remote:

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              # оновлення 'master' з remote
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[=<refname>] (тобто, не вказуючи, на який саме коміт має вказувати посилання на віддаленій стороні, або які посилання на віддаленій стороні захищаються) під час "push", це перевірить, чи оновлення з посилань віддаленого відстеження, які могли бути неявно оновлені у фоновому режимі, інтегровані локально, перш ніж дозволити примусове оновлення.

-f

--force

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

Цей прапорець вимикає цю перевірку, інші перевірки безпеки, зазначені нижче в розділі ПРАВИЛА НАДСИЛАННЯ, а також перевірки, передбачені опцією --force-with-lease. Це може призвести до втрати комітів у віддаленому репозиторії; використовуйте його з обережністю.

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

--force-if-includes

--no-force-if-includes

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

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

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

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

--repo=<repository>

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

-u

--set-upstream

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

--thin

--no-thin

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

-q

--quiet

Придушити весь вивід, включаючи перелік оновлених посилань, якщо не сталося помилки. Інформація про хід виконання не виводиться у стандартний потік помилок.

-v

--verbose

Надавати повний (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

Вмикає або вимикає гачок pre-push (див. 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 використовуватиме стандартно.

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

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

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

<pushurl> використовується виключно для надсилання. Цей параметр є необов’язковим, а стандартним значенням є <URL>. Надсилання на віддалений сервер впливає на всі визначені pushurl або на всі визначені url, якщо pushurl не визначено. Натомість, якщо визначено кілька url, завантаження відбуватиметься лише з першого визначеного url.

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

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

	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 використовує:

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

git push використовує:

	HEAD:refs/heads/<head>

ВИСХІДНІ ГІЛКИ

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

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

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

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

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

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

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

ВИВІД

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

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

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

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

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

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

<flag>

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

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

<summary>

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

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

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

з (from)

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

до (to)

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

причина (reason)

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

ПРАВИЛА НАДСИЛАННЯ

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

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

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

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

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

ПРИМІТКИ ЩОДО ПЕРЕМОТУВАННЯ ВПЕРЕД (FAST-FORWARD)

Коли оновлення змінює гілку (або, загалом, посилання), яка раніше вказувала на коміт A, щоб вказувати на інший коміт B, це називається перемотуванням вперед (fast-forward) тоді і тільки тоді, коли 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 буде прийнятий.

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

ПРИКЛАДИ

git push

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

git push origin

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

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

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

git push origin :

Надсилати «відповідні» гілки до origin. Опис «відповідних» гілок див. у розділі <refspec> вище в розділі ОПЦІЇ.

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, і часто це необхідно, коли ви можете встановити зʼєднання лише одним способом (тобто satellite може підʼєднатись до mothership через ssh, але mothership не може ініціювати зʼєднання із satellite, оскільки останній знаходиться за брандмауером або не використовує 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 репозиторію origin за допомогою гілки dev, дозволивши оновлення, що не є fast-forward. Це може призвести до появи в репозиторії origin комітів без посилань. Розглянемо таку ситуацію, коли fast-forward неможливий:

	    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