GIT-PUSH(1), руководство пользователя

NAME

       git-push - обновляет удаленные ссылки (remote refs) вместе со связанными объектами

SYNOPSIS

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

ОПИСАНИЕ

       Обновит remote refs (ссылки на сетевом репозитории), используя local refs (ссылки на локальном репозитории), с отправкой объектов, необходимых для завершения указанных refs. Короче говоря, синхронизирует локальный репозиторий с удалённым (remote).

       Вы можете выполнять некоторые интересные вещи, которые будут происходить при каждом вашем push в удалённый (remote) репозиторий, с помощью настройки hooks. См. документацию для git-receive-pack(1).

       Когда в командной строке не указано с помощью аргумента < repository>, куда следует выполнить push, будет проверена конфигурация branch.*.remote для текущей ветки (branch), чтобы определить место для push. Если эта конфигурация отсутствует, то по умолчанию используется origin.

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

       Когда не указано ни в командной строке, ни в конфигурации, что делать для push, то используется поведение по умолчанию, которое соответствует простому значению для push.default: текущая branch проталкивается (pushed) в соответствующую upstream branch, но по соображениям безопасности push прерывается, если имя upstream branch не совпадает с локальным именем.

ОПЦИИ

       < repository>

           Это remote-репозиторий, указывающий место назначения операции push. Этот параметр может быть либо URL (см. секцию GIT URLS ниже), либо имя remote (см. далее секцию REMOTES).

       < refspec>...

           Указывает ссылку назначения (ref) для обновления объектом источника. Формат параметра < refspec> включает опциональный знак +, за которым идет объект источника < src>, после чего идет двоеточие :, за которым идет ссылка (ref) места назначения < dst>.

           < src> часто имя branch, для которой вы хотите выполнить push, однако это может быть произвольное "SHA-1 expression", такое как master~4 или HEAD (см. gitrevisions(7)).

           < dst> говорит, какая ref на стороне remote обновляется этим push. Здесь нельзя использовать произвольные выражения, должно быть указано актуальное имя ref. Если git push [< repository>] установлен без какого-либо аргумента < refspec> для обновления какого-нибудь ref на месте назначения вместе с < src> и переменной конфигурации remote.< repository>.push, то часть :< dst> может быть опущена — такой push обновит ref, которая нормально обновляется < src> без какого-нибудь < refspec> в командной строке. Иначе пропущенное :< dst> означает обновление той же ref, что и < src>.

           Если < dst> не начинается с refs/ (например refs/heads/master), то мы попытаемся определить, к чему относится refs/* в целевом < repository>, на основании типа < src>, который проталкивает push, и является ли < dst> неоднозначным.

           • Если < dst> однозначано ссылается на ref на < repository> remote, то push выполняется на эту ref.
           • Если < src> разрешается в ref, начинающуюся на refs/heads/ или refs/tags/, то это добавляется к < dst>.
           • Другие разрешения неоднозначности могут быть добавлены в будущем, но на данный момент любые другие случаи будут вызывать ошибку с указанием, какая попытка была сделана, и в зависимости от конфигурации advice.pushUnqualifiedRefname (см. git-config(1)) будет выведен совет, для какого refs/ namespace вы могли бы захотеть сделать push.

           Объект, на который ссылается < src>, используется для обновления ссылки < dst> на стороне remote. Допустимость этого зависит от того, где в refs/* существует ссылка < dst>, как подробно описано ниже, в этих секциях "обновление" (update) означает любые модификации, кроме удалений (удаления, как отмечено после следующих нескольких секций, обрабатываются по-другому).

           Пространство имен refs/heads/* принимает только объекты фиксации и обновляется только в том случае, если они могут быть быстро перенаправлены (fast-forward).

           Пространство имен refs/tags/* принимает любой вид объектов (как могут быть помечены фиксации, деревья и blob-ы), и любые обновления в них будут отклонены.

           Можно сделать push объекта любого типа в любое пространство имен вне refs/{tags,heads}/*. В случае тегов (tags) и фиксаций (commits), они будут рассматриваться как если бы они были фиксациями внутри refs/heads/* для предназначения разрешения обновления. Например, fast-forward фиксаций и тегов вне refs/{tags,heads}/* разрешается, даже в случаях, где fast-forward содержимое это не фиксация, а объект тега, который указывает на новую фиксацию, которая является fast-forward фиксации последнего заменяемого тега (или фиксации). Замена тега совершенно другим тегом также допускается, если он указывает на ту же самую фиксацию, а также push очищенного тега, т. е. push фиксации, на которую указывает существующий объект тега, или нового объекта тега, на который указывает существующая фиксация.

           Объекты дерева и blob-объекты вне refs/{tags,heads}/* будут обрабатываться таким же образом, как если бы они были внутри refs/tags/*, любое их обновление будет отклонено.

           Все описанные выше правила о том, что не разрешено как обновление, можно переопределить, добавив опциональный начальный + для refspec (или используя опцию командной строки --force). Единственное исключение из этого: никакая форсировка не заставит пространство имен refs/heads/* принять объект, не являющийся фиксацией. Хуки (hooks) и конфигурация также могут переопределять или изменять эти правила, см. например receive.denyNonFastForwards в git-config(1), а также pre-receive и update в githooks(5).

           Выполнение push пустого < src> позволяет вам удалить < dst> из remote-репозитория. Удаления всегда принимаются без начального '+' в refspec (или --force), за исключением, когда это запрещено конфигурацией или hook-ами. См. receive.denyDeletes в git-config(1), а также pre-receive и update в githooks(5).

           Специальная refspec : (или +: чтобы разрешить non-fast-forward обновления) направляет Git выполнить "совпавшие" ветки: для каждой branch, которая существует локально, будет обновлена сторона remote, если на ней уже существует branch с таким же именем.

           Тег < tag> означает то же самое, что и refs/tags/< tag>:refs/tags/< tag>.

       --all, --branches

           Выполнит push всех ветвей (т. е. refs под refs/heads/); не может использоваться с другим < refspec>.

       --prune

           Удалит remote-ветви, у которых нет локальной соответствующей ветки. Например, remote ветка tmp будет удалена, если больше не существует локальная branch с таким же именем. Это также относится к refspecs, например git push --prune remote refs/heads/*:refs/tmp/* обеспечит удаление remote refs/tmp/foo, если не существует refs/heads/foo.

       --mirror

           Вместо именования каждой ссылки на push, указывает, что все ссылки под refs/ (которые включают, но не ограничиваются refs/heads/, refs/remotes/ и refs/tags/) будут зеркалированы в remote-репозиторий. Новые созданные локальные ссылки будут протолкнуты на remote, локально обновленные ссылки будут принудительно обновлены на remote, и remore-ссылки будут удалены из remote-репозитория. Это умолчание, если установлена опция конфигурации remote.< remote>.mirror.

       -n, --dry-run

           Выполнение всех действий, кроме фактической отправик обновления.

       --porcelain

           Генерация вывода, удобного для машинной обработки. Выводимая строка статуса для каждой ссылки будет разделена табулияцией и отправлена в stdout вместо stderr. Будут предоставлены полные символические имена ссылок.

       -d, --delete

           Все перечисленные ссылки удаляются из remote-репозитория. Это то же самое, как добавление префикса двоеточия ко всем ссылкам.

       --tags

           Проталкиваются все ссылки под refs/tags в дополнение к refspecs, явно перечисленным в командной строке.

       --follow-tags

           Проталкиваются все ссылки, которые были бы протолкнуты без этой опции, и также проталкиваются помеченные теги в refs/tags, которые отсутствуют на remote, но указывают на фиксации, которые достижимы из поталкиваемых ссылок. Это может такеж быть укзано в переменной конфигурации push.followTags. Для дополнительной информации см. push.followTags в git-config(1).

       --[no-]signed, --signed=(true|false|if-asked)

           GPG-подпись (GPG означает GNU Privacy Guard) push-запроса для обновления ссылок на принимающей стороне, для их проверки hook-ами и/или для лога. Если false или --no-signed, то не будет выполнена попытка подписи. Если true или --signed, то push потерпит неудачу, если сервер не поддерживает подписанные push. Если установлено в if-asked, подпись осуществляется только если сервер поддерживает подписанные push. Push также потерпит неудачу, если фактический вызов gpg --sign потерпит неудачу. См. git-receive-pack(1) для подробностей на получающем конце.

       --[no-]atomic

           Использовать атомарную транзакцию на стороне remote, если это доступно. Либо обновятся все ссылки, либо в случае ошибки никакие ссылки не обновятся. Если сервер не поддерживает atomic push, то push потерпит неудачу.

       -o < option>, --push-option=< option>

           Передает указанную строку на сервер, который передает её на pre-receive а также на post-receive hook. Предоставленная строка не должна содержать символ NUL или LF. Когда предоставлено несколько --push-option=< option>, все они посылаются на другую сторону в порядке, в котором перечислеы в командной строке. Когда в командной строке не указано --push-option=< option>, вместо этого используется значение конфигурационной переменной push.pushOption.

       --receive-pack=< git-receive-pack>, --exec=< git-receive-pack>

           Путь до программы git-receive-pack на remote конце. Иногда полезно, когда проталкивание производится на remote-репозиторий через ssh, и у вас нет программы в директории по умолчательному $PATH.

       --[no-]force-with-lease, --force-with-lease=< refname>, --force-with-lease=< refname>:< expect>

           Обычно "git push" отклоняет обновление remote ссылки, которая не является предком локальной ссылки, используемой для её перезаписи. Эта опция отменяет это ограничение, если текущее значение remote ссылки является ожидаемым. Иначе "git push" потерпит неудачу.

           Представьте себе, что вы долны выполнить rebase того, что уже опубликовали. Вам придется обойти правило "must fast-forward", чтобы заменить историю, которую вы изначально опубликовали с rebased-историей. Если кто-то еще надстроил что-то поверх вашей оригинальной истории, когда вы делаете rebase, кончик ветки на remote может продвинуться с их фиксацией, и слепое проталкивание с --force приведет к потере их работы.

           Эта опция позволяет вам сказать, что вы ожидаете, что обновляемая история это то, что вы перебазировали и хотите заменить. Если ссылка все еще указывает на указанную вами фиксацию, вы можете быть уверены, что никакие другие ребята ничего не сделали с этой ссылкой. Это похоже на взятие "аренды" на ссылке без явной её блокировки, и remote-ссылка обновится только если "аренда" все еще корректна.

           --force-with-lease по отдельности, без указания подробностей, защитит все remote ссылки, которые будут обновляться, требуя, чтобы их текущее значение было таким же, как ветка remote-tracking, которая у нас есть для отслеживания.

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

           --force-with-lease=< refname>:< expect> защитит именованную ссылку (отделно), если выполняется её обновление, требуя, чтобы её текущее значение было таким же как указанное значение < expect> (которому разрешено отличаться от remote-tracking ветки, которая у нас есть для refname, или у нас даже не должно быть такой remote-tracking ветки, когда используется такая форма). Если < expect> это пустая строка, то именованная ссылка не должна существовать.

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

           "--no-force-with-lease" отменит все предыдущие --force-with-lease, указанные в командой строке.

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

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

           Если ваш редактор или другая система запустила 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) для версий upstream-кода, который вы видите и хотите перезаписать, затем перезапишите историю, и в конце сделайте принудительное проталкивание (force push) изменений в master если все еще remote-версия находится в base, независимо от того, что ваш локальный remotes/origin/master был обновлен в фоновом режиме.

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

       -f, --force

           Обычно команда отклонит обновление remote ссылки, которая не является предком локальной ссылки, используемой для её перезаписи. Также, когда используется опция --force-with-lease, команда отклонит обновление remote ссылки, текущее значение которой не соответствует ожидаемому.

           Эта опция запретит эти проверки, и может привести к тому, что remote репозиторий потеряет фиксации; используйте это с осторожностью.

           Обратите внимание, что --force применяется для всех проталкиваемых ссылок, поэтому использование с набором push.default, совпавшим с несколькими местами назначения push, сконфигурированными через remote.*.push, может перезаписать ссылки, отличные от текущей ветки (включая локальные ссылки, которые находятся строго за их remote соответствием). Чтобы принудительно сделать push только одной ветки, используйте + перед refspec для push (например git push origin +master для принудительного push ветки master). См. секцию < refspec>... выше для дополнительной информации.

       --[no-]force-if-includes

           Принудительное обновление только если хвост remote-tracking ссылки был интегрирован локально.

           Эта опция включает проверку, доступен ли хвост remote-tracking ссылки из одной из "reflog" записей локальной ветки, основаннрой на ней, для возможности перезаписи. Эта проверка гарантирует, что любые обновления из remote были интегрированы локально путем отклонения принудительного обновления, если это не так.

           Если эта опция передана без указания --force-with-lease, или указанием с --force-with-lease=< refname>:< expect>, то это аналог "no-op".

           Указание --no-force-if-includes запрещает это поведение.

       --repo=< repository>

           Эта опция эквивалентна аргументу < repository>. Если указано и то, и другое, то приоритет получает аргумент командной строки.

       -u, --set-upstream

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

       --[no-]thin

           Эти опции передаются в git-send-pack(1). Транзакция thin значительно уменьшает количество отправляемых данных, когда передатчик и приемник совместно используют много одинаковых объектов. В качестве умолчания используется --thin.

       -q, --quiet

           Подавляет весь вывод, включая листинг обновленных ссылок, за исключением ситуаций возникновения ошибок. Прогресс не показывается в стандартном потоке ошибок (standard error stream).

       -v, --verbose

           Запуск с подробной информацией.

       --progress

           Статус прогресса выводится по умолчанию в standard error stream, когда он присоединен к терминалу, кроме ситуаций, когда указана опция -q. Этот флаг принудительно показывает статус прогресса даже если standard error stream не направлен в терминал.

       --no-recurse-submodules, --recurse-submodules=check|on-demand|only|no

           Может использоваться для гарантии, что все фиксации субмодуля, используемые в проталкиваемых ревизиях, доступны на remote-tracking ветви. Если используется проверка, то Git будет проверять, что все фикации субмодуля, измененные в проталкиваемых ревизиях, доступны по крайней мере на одном remote субмодуле. Если любые фиксации отсутствуют, то push будет оборван, и произойдет выход с ненулевым статусом. Если используется on-demand, то на все субмодули, измененные в ревизиях для push, будeт применена операция  push. Если on-demand не может выполнить push всех необходимых ревизий, то операция также будет оборвана и произойдет выход с ненулевым статусом. Если используется only, то будут протолкнуты все субмодули, в то время как superproject останется без проталкивания. Значение no или опция --no-recurse-submodules могут использоваться для отмены переменной конфигурации push.recurseSubmodules, когда не требуется рекурсия субмодуля.

          Когда используется on-demand или only, если субмодуль имеет конфигурацию "push.recurseSubmodules={on-demand,only}" или "submodule.recurse", то произойдут дальнейшие рекурсии. В этом случае "only" обрабатывается как "on-demand".

       --[no-]verify

           Переключит pre-push hook (см. githooks(5)). Используется умолчание --verify, давая для hook шанс предотвратить push. С --no-verify действие hook полностью пропускается.

       -4, --ipv4

           Использовать только адреса IPv4, с игнорированием адресов IPv6.

       -6, --ipv6

           Использовать только адреса IPv6, с игнорированием адресов IPv4.

GIT URLS

       Обычно URL-ы содержат информацию о транспортном протоколе, адрес remote сервера и путь до репозитория. в зависимости от транспортного протокола некоторая часть этой информации может отсутствовать.

       Git поддерживает протоколы ssh, git, http и https (дополнительно могут использоваться ftp и ftps для fetch, но это не эффективно и сделано устаревшим; не используйте эти протоколы).

       Традиционный (native) транспорт (например, git:// URL) не выполняет аутентификацию, и должен использоваться с осторожностью на незащищенных сетях.

       Следующие синтаксисы могут использоваться вместе с URL:

       •   ssh://[user@]host.xz[:port]/path/to/repo.git/
       •   git://host.xz[:port]/path/to/repo.git/
       •   http[s]://host.xz[:port]/path/to/repo.git/
       •   ftp[s]://host.xz[:port]/path/to/repo.git/

       С протоколом ssh может использоваться альтернативный синтаксис в стиле scp:

       •   [user@]host.xz:path/to/repo.git/

       Этот синтаксис распознается только если нет слешей перед первым двоеточием. Это помогает отличить локальный путь, который содержит двоеточие. Например, локальный путь foo:bar может быть указан как абсолютный путь или ./foo:bar, чтобы избежать неправильной интерпретации как ssh URL.

       Протоколы ssh и git дополнительно прддерживают расширение ~username:

       •   ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
       •   git://host.xz[:port]/~[user]/path/to/repo.git/
       •   [user@]host.xz:/~[user]/path/to/repo.git/

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

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

       Эти два синтаксиса почти эквивалентны, за исключением ситуации клонирования, когда первый вариант подразумевает опцию --local option. Подробную информацию см. в git-clone(1).

       git clone, git fetch и git pull, но не git push, будут также принимать подходящий bundle-файл. См. git-bundle(1).

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

       •   < transport>::< address>

       .. где < address> может быть путем, сервером и путем, или произвольной URL-строкой, распознаваемой определенным вовлекаемым remote helper. См. gitremote-helpers(7) для получения подробностей.

       Если существует большое количество remote-репозиториев с похожими именами, и вы хотите использовать для них другой формат (чтобы используемые вами 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" для операций push, но операции pull все еще будут использовать оригинальный URL.

REMOTES

       Вместо URL в качестве аргумента < repository> может использоваться одно из следующих имен:

       •   remote в конфигурационном файле Git: $GIT_DIR/config,
       •   файл в директории $GIT_DIR/remotes, или
       •   файл в директории $GIT_DIR/branches.

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

   Именованный remote в конфигурационном файле

       Вы можете выбрать предоставление имени remote, которое вы ранее сконфигурировали с использованием git-remote(1), git-config(1) или даже вручную путем редактирования файла $GIT_DIR/config. URL этого remote будет использоваться для доступа к репозиторию. Refspec этого удалённого (remote) репозитория будет использоваться по умолчанию, когда вы не предоставили refspec в командной строке. Запись в конфигурационном файле может выглядеть следующим образом:

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

       Здесь < pushurl> используется только для операций проталкивания (push). Это опционально, и по умолчанию используется для < URL>. На проталкивание в remote влияют все определенные pushurl или все определенные url, если не были определены pushurl. Однакоо fetch будет производиться только из первого определенного 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>

OUTPUT

       Вывод "git push" зависит от используемого метода транспорта; эта секция описывает вывод, который проталкивается через протокол Git (или локально, или через ssh).

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

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

       Если используется --porcelain, то каждая строка выводится в форме:

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

       Статус синхронизированных (up-to-date) ссылок показывается только если используется опция --porcelain или опция --verbose.

       flag

           Одиночный символ, показывающий статус ссылки:

           (пробел)

               для успешно pushed fast-forward;

           +
               для успешного forced update;

           -
               для успешно удаленной ссылки;

           *
               для успешно pushed новой ссылки;

           !
               для ссылки, которая была отклонена или потерпела неудачу для push;

           =
               для ссылки, которая была синхронизированной и не нуждалась в push.

       summary

           Для успешно pushed ссылок summary показывает старые и новые значения ссылок в форме, подходящей для использования в качестве аргумента для git log (это в большинстве случаев < old>..< new>, и < old>...< new> для обновлений forced non-fast-forward).

           Для неудачных обновления предоставляется больше деталей:

           rejected

               Git вообще не пытался отправить ссылку, обычно по причине того, что это не fast-forward и вы не делали принудительное обновление (force update).

           remote rejected

               Remote отклонил обновление. Обычно это вызвано hook на стороне remote, или потому что remote-репозиторий имеет одну из следующих действующих safety-опций: receive.denyCurrentBranch (для push в checked out ветку), receive.denyNonFastForwards (для обновлений forced non-fast-forward), receive.denyDeletes или receive.denyDeleteCurrent. См. git-config(1).

           remote failure

               Remote не сообщил об успешном обновлении ссылки, потому что была временная ошибка на стороне remote, разрыв сетевого соединения или другая временная ошибка.

       from

           Имя локальной проталкиваемой ссылки, минус её префикс refs/< type>/. В случае удаления имя локальной ссылки опускается.

       to

           Имя обновляемой remote ссылки, минус её префикс refs/< type>/.

       reason

           Объяснение, понятное для человека. В случае успешно pushed ссылок объяснения не требуется. Для неудавшихся ссылок описывается причина неудачи.

ЗАМЕЧАНИЕ ПО ПОВОДУ ОПЕРАЦИЙ FAST-FORWARD

       Когда обновление меняет ветку (или в более общем случае ссылку), которая используется для указания на фиксацию A для точки в другой фиксации B, то это называется обновлением fast-forward, если и только если B является потомком A.

       В обновлении fast-forward от A к B, набор фиксаций, на основе которых строится первоначальная фиксация A, является подмножеством фиксаций, на основе которых строится новая фиксация B. Следовательно, она не теряет историю.

       В отличие от этого обновление non-fast-forward теряет историю. Для примера предположим, что вы и кто-то еще начали работу с одной и той же фиксации X, и вы построили историю, ведущую к фиксации B, в то время как другой человек построил историю, ведущую к фиксации A.

       История выглядит следующим образом:

                 B
                /
            ---X---A

       Далее предположим, что другой человек уже сделал push изменений, приводящих к A, обратно в орининальный репозиторий, из которого вы оба получили оригинальную фиксацию X.

       Операция push, сделанная другим человеком, обновила ветку, которая раньше указывала на фиксацию X, чтобы указать на фиксацию A. Это fast-forward.

       Однако если вы попытаетесь сделать push, то эта попытка обновить ветку (которая сейчас указывает на A) фиксацией B. Это сделает not fast-forward. Если вы это сделаете, то изменения, которые введены фиксацией A, будут потеряны, потому что любой будет теперь начинать сборку поверх B.

       По умолчанию команда не позволяет обновление, которое не является операцией fast-forward, чтобы не допустить потери истории.

       Если вы не хотите потерять вашу работу (историю от X до B) или работу другого человека (истории от X до A), то вам нужно сначала загрузить (fetch) историю из репозитория, создать историю, которая содержит изменения партнера, и затем сделать push результата.

       Вы можете выполнить "git pull", разрешить потенциальные конфликты, и затем сделать "git push" результата. Команда "git pull" создаст фиксацию слияния (merge commit) C между фиксациями A и B.

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

       Обновление A результатом merge commit будет операцией fast-forward и ваш push будет принят.

       Альтернативно вы можете выполнить rebase вашего изменения между X и B поверх A командой "git pull --rease", и выполнить push результата. Операция rebase создаст новую фиксацию D, которая построит изменение между X и B поверх A.

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

       И снова, обновление A этой фиксацией будет операцией fast-forward, и ваш push будет принят.

       Существует другая похожая ситуация, когда вы можете встретиться с отказом операции non-fast-forward, если вы пытаетесь сделать push, и это возможно даже когда вы делате push в репозиторий, в который больше никто не делал push. После того, как вы сами сделали push фиксации A (как в первой картинке этой секции), замените это на "git commit --amend" для формирования фиксации B, и попробуйте сделать её push, потому что забыли, что уже сделали push A. В этом случае, и только если вы уверены, что никто в то же время не получил вашу предыдущую фиксацию A (и начал построение своей истории от неё), то вы можете запустить "git push --force" для её перезаписи. Другими словами, "git push --force" является методом, зарезервированным для случая, когда вы хотите потерять историю.

ПРИМЕРЫ

       git push

           Работает наподобие git push < remote>, где < remote> это текущая ветка remote (или origin, если на текущей ветке не сконфигурирован никакой remote).

       git push origin

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

           Поведение по умолчанию этой команды, когда не предоставлена < refspec>, может быть сконфигурировано установкой опции push на remote, или переменной конфигурации push.default.

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

       git push origin :

           Push "совпавших" веток на origin. См. < refspec> выше в секции ОПЦИИ для описания "matching" веток.

       git push origin master

           Найдет ссылку, которая соответствует master в репозитории источника (скорее всего, будет найдено refs/heads/master), и обновит такую же ссылку (т. е. refs/heads/master) в репозитории origin. Если master не существует на remote, то она будет создана.

       git push origin HEAD

           Удобный способ сделать push текущей ветки в то же самое имя на remote.

       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 может сделать соединение ssh к mothership, но mothership не может инициировать соединение к satellite, потому что последний находится за файерволом, или на нем не запущен sshd).

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

       git push origin HEAD:master

           Выполнит push текущей ветки на remote ссылку соответствующей master в репозитории origin. Это удобная форма команды для push текущей ветки без необходимости задумываться о её локальном имени.

       git push origin master:refs/heads/experimental

           Создаст ветку experimental в репозитории origin путем компирования текущей ветки master. Эта форма только нужна для создания новой ветки или тега в репозитории remote, когда локальное имя и remote имя отличаются; otherwise, имя ссылки само по себе будет работать.

       git push origin :experimental

           Найдет ссылку, которая соответствует experimental в репозитории origin (т. е. refs/heads/experimental), и удалит её.

       git push origin +dev:master

           Обновит ветку master репозитория origin веткой dev, позволяя обновления non-fast-forward. Это может оставить зависшие не используемые фиксации в репозитории origin. Рассмотрим следующую ситуацию, где операция fast-forward невозможна:

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

           Показанная выше команда изменит репозиторий origin на

                                     A---B  (безымянная ветка)
                                    /
                           o---o---o---X---Y---Z  master

           Фиксации A и B больше не будут принадлежать ветке с символическим именем, и поэтому будут недоступны. Так что эти ветки будут удалены командой git gc в репозитории origin.

БЕЗОПАСНОСТЬ

       Протоколы fetch и push не были разработаны для предотвращения сторонней кражи данных из другого репозитория, которые не были предназначены для общего использования. Если у вас есть приватные данные, которые нужно защитить от злонамеренного пира, то лучше всего сохранить их в другом репозитории. Это относится и к клиентам, и к серверам. В частности, пространства имен на сервере не эффективны для управления доступом для чтения; вы должны давать доступ на чтение к пространству имен только клиентам, которым вы доверяете доступ на чтение ко всему репозиторию.

       Известны следующие векторы атак:

        1. Жертва отправляет строки "have", рекламирующие ID объектов, которые у неё есть, не предназначенные явно для совместного использования, но они могут использоваться для оптимизации передачи, если у пира они также есть. Атакующий выбирает для кражи объект ID X и посылает ссылку на X, но не требуется посылать содержимое X, потму что у жертвы оно уже есть. Теперь жертва доверяет атакудющему, что у него есть X, и впоследствии посылает содержимое X обратно атакующему. Эта атака самая простая для клиента, чтобы выполнить её на сервере, путем создания ссылки X в пространстве имен клиента, к которому клиент имеет доступ, и он может затем выполнить fetch. Наиболее вероятный способ для сервера выполнить это на клиенте - сделать "merge" X в публичную ветку и надеяться, что пользователь выполнит дополнительную работу над этой веткой и сделает её push обратно на сервер, не заметив merge.

        2. Как в варианте #1, атакующий выбирает для кражи объект с ID X. Жертва посылает объект Y, который уже есть у атакующего, и атакующий ложно утверждает, что у него есть X, и не Y, так что жертва посылает Y как delta вместо X. Delta раскрывает области X, которые похожи на Y для атакующего.

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

       Все, что показано далее, селективно взято из документации git-config(1).

       push.autoSetupRemote

           Если установлено в "true", то подразумевается, что --set-upstream на push по умолчанию, когда нет upstream tracking для текущей ветки; эта опция дает эффект с push.default опциями simple, upstream и current. Это полезно, если по умолчанию вы хотите, чтобы новые ветки проталкивались в умолчательный remote (наподобие поведения push.default=current), и вы также хотите установить upstream tracking. Рабочие процессы, которые скорее всего выиграют от этого параметра, это простые рабочие процессы, в которых все ветки должны иметь одинаковое имя на remote.

       push.default

           Определяет действие, которое должен выполнить git push, если не была предоставлена refspec (из командной строки, конфига или откуда-то еще). Другие значения хорошо подойдут для особенных рабочих процессов; например, в чисто центальном рабочем процессе (например источник fetch эквивалентен месту назначения push), вариант вероятно то, что вам нужно. Возможны значения:

           • nothing - не делать push ни для чего (выведется ошибка), если не задана refspec. Это главным образом предназначено для людей, которые хотят избежать ошибок путем обязательного явного указания необходимой информации.

           • current - делать push текущей ветки для обновления ветки с таким же именем на принимающем конце. Работает и в централизованных, и не централизованных рабочих процессах.

           • upstream - делать push текущей ветки на ветку, изменения которой обычно интегрированы в текущую ветку (которая называется  @{upstream}). Этот режим имеет смысл только если вы делаете push в тот же самый репозиторий, откуда нормально сделали pull (т. е. централизованный рабочий процесс).

           • tracking - устаревший синоним для upstream.

           • simple - делать push текущей ветки с таким же именем, что и на remote.

               Если вы работаете на централизованном рабочем процессе (операции push в тот же репозиторий, откуда делается pull, который обычно origin), то вам нужно сконфигурировать ветку upstream с таким же именем.

               Этот режим является умолчанием начиная с Git 2.0, и это самая безопасная опция для начинающих.

           • matching - push всех веток с одинаковыми именами на обоих концах. Это заставляет репозиторий, для которого вы делаете push, запоминать набор ветвей, которые были вытолкнуты наружу (например если вы всегда делаете push maint и master, а не другие ветки, то репозиторий, куда вы делаете push, будет иметь эти две ветки, и ваши локальные maint и master будут выталкиваться туда).

               Для эффективного использования этого режима вы должны убедиться, что все векти, которые вы выталкиваете push, готовы к этой операции перед запуском git push, так как смысл этого режима заключается в том, чтобы вытолкнуть все ветки за один раз. Если вы обычно завершаете работу только на одной ветке и делаете push результата, в то время как другие ветки не закончены, то этот режим не для вас. Также этот режим не подойдет для проталкивания в общий центральный репозиторий, посколку другие люди могут добавлять туда новые ветки, или обновлять хвосты существующих веток, что находится вне вашего контроля.

               Это использовалось по умолчанию до появления Git 2.0 (в нем по умолчанию simple).

       push.followTags

           Если установлено в true, по умолчанию разрешена опция --follow-tags. Вы можете отменить эту конфигурацию в мтмент push указанием опции --no-follow-tags.

       push.gpgSign

           Может быть установлена в значение boolean, или строку if-asked. Значение true приводит к тому, что все push подписываются GPG, как если бы была передана опция --signed в git-push(1). Строка if-asked приводит к тому, что push подписывается, если сервер это поддерживает, как если бы была передана опция --signed=if-asked в git push. Значение false отменяет значение из более низкого по приоритету файла конфигурации. Явно указанный флаг командной строки всегда отменяет эту опцию конфигурации.

       push.pushOption

           Когда в командной строке не указан аргумент --push-option=< option>, git push ведет себя как если бы каждое значение < value> этой переменной передается как --push-option=< value>.

           Эта переменная с несколькими значениями, и пустое значение может использоваться в файле конфигурации с более высоким приоритетом (например .git/config в репозитории), чтобы очистить значения, унаследованные файлами конфигурации с более низким приоритетом (например $HOME/.gitconfig).

               Пример:

               /etc/gitconfig
                 push.pushoption = a
                 push.pushoption = b

               ~/.gitconfig
                 push.pushoption = c

               repo/.git/config
                 push.pushoption =
                 push.pushoption = b

               Это прведет к тому, что активно будет только значение b (a и c очищаются).

       push.recurseSubmodules

           Может быть "check", "on-demand", "only", или "no", с таким же поведлением, как у "push --recurse-submodules". Если не установлено, то по умолчанию используется no, если не установлено submodule.recurse (в этом случае значение true означает on-demand).

       push.useForceIfIncludes

           Если установлено в "true", то это эквивалент указанию --force-if-includes как опции git-push(1) в командной строке. Добавление --no-force-if-includes в момент push отменит эту установку конфигурации.

       push.negotiate

           Если установлено в "true", попытается уменьшить размер packfile, отправляемого раундами согласования, в которых клиент и сервер пытаются найти общие фиксации. Если "false", то Git будет полностью полагаться на рекламные объявления сервера для нахождения общих фиксаций.

       push.useBitmaps

           Если установлено в "false", то запрещает использование bitmap для "git push", даже если pack.useBitmaps установлено в "true", без предотвращения других операций git для использования bitmap. По умолчанию true.

Git 2.43.0, 01/13/2025, GIT-PUSH(1)