git-pull

Выполняет слияние и фиксирует результат. Этот параметр можно использовать для переопределения --no-commit. Полезен только при слиянии.

С параметром --no-commit выполняет слияние и останавливается непосредственно перед созданием коммита слияния, чтобы пользователь мог проверить и при необходимости изменить результат слияния перед фиксацией.

Обратите внимание: обновления с перемоткой вперёд не создают коммит слияния, поэтому остановить такое слияние с помощью --no-commit невозможно. Поэтому, если нужно гарантировать, что команда слияния не изменит и не обновит ветку, используйте --no-ff вместе с --no-commit.

Перед фиксацией успешно выполненного автоматического слияния запускает редактор, чтобы можно было изменить автоматически сформированное сообщение о слиянии и объяснить его причины и обоснование. Параметр --no-edit можно использовать, чтобы принять автоматически сформированное сообщение (обычно это не рекомендуется).

Старые сценарии могут зависеть от прежнего поведения, при котором пользователю не разрешалось редактировать сообщение в журнале слияния. При запуске git merge в них будет открываться редактор. Чтобы упростить адаптацию таких сценариев к обновлённому поведению, в начале сценария можно задать переменную окружения GIT_MERGE_AUTOEDIT со значением no.

Этот параметр определяет, как будет очищено сообщение о слиянии перед фиксацией. Подробнее см. git-commit[1]. Кроме того, если для <mode> задано значение scissors, перед передачей системе фиксации при конфликте слияния в MERGE_MSG будут добавлены ножницы.

Обновляет ветку до новой истории только в том случае, если локальная история не разошлась с удалённой. Это способ по умолчанию, если метод согласования разошедшихся историй не задан (с помощью флагов --rebase).

При слиянии, а не перебазировании, определяет, как выполнять слияние, если включаемая история уже является потомком текущей истории. Если запрошено слияние, по умолчанию используется --ff, за исключением случая слияния аннотированного (и, возможно, подписанного) тега, который хранится не в своём обычном месте в иерархии refs/tags/; в этом случае предполагается --no-ff.

С параметром --ff, если возможно, выполняет слияние с перемоткой вперёд (только перемещает указатель ветки, чтобы он указывал на объединённую ветку; коммит слияния не создаётся). Если это невозможно (включаемая история не является потомком текущей), создаёт коммит слияния.

С параметром --no-ff всегда создаёт коммит слияния, даже если слияние можно было выполнить с перемоткой вперёд.

Подписывает полученный коммит слияния с помощью GPG. Аргумент <key-id> необязателен; по умолчанию используется идентификатор автора коммита. Если аргумент указан, он должен следовать сразу за параметром без пробела. Параметр --no-gpg-sign полезен для отмены действия как переменной конфигурации commit.gpgSign, так и более раннего параметра --gpg-sign.

Помимо имён веток, добавляет в сообщение журнала однострочные описания не более чем <n> фактических коммитов, которые сливаются. См. также git-fmt-merge-msg[1]. Полезен только при слиянии.

С параметром --no-log однострочные описания фактических сливаемых коммитов не выводятся.

Добавляет в конец сообщения журнала коммита завершающую строку Signed-off-by от имени автора коммита. Значение подтверждения зависит от проекта, в который вы отправляете изменения. Например, оно может удостоверять, что автор коммита имеет право предоставить эту работу на условиях лицензии проекта или согласен с некоторым подтверждением со стороны участника, например с Сертификатом происхождения разработчика. (См. https://developercertificate.org — вариант, используемый в проектах ядра Linux и Git.) Чтобы понять, как в конкретном проекте используются такие подтверждения, ознакомьтесь с документацией проекта или обратитесь к его руководству.

Параметр --no-signoff можно использовать для отмены более раннего параметра --signoff в командной строке.

В Git нет (и не будет) переменной конфигурации, которая по умолчанию включает параметр командной строки --signoff; подробнее см. запись commit.signoff в gitfaq[7].

Показывает в конце слияния статистику различий. Вывод этой статистики также регулируется параметром конфигурации merge.stat.

С параметром -n или --no-stat статистика различий в конце слияния не выводится.

Показывает в конце слияния краткую сводку.

Создаёт такое состояние рабочего дерева и индекса, как если бы произошло настоящее слияние (за исключением сведений о слиянии), но не создаёт коммит, не перемещает HEAD и не записывает $GIT_DIR/MERGE_HEAD (чтобы следующая команда git commit создала коммит слияния). Это позволяет создать поверх текущей ветки один коммит, результат которого будет таким же, как при слиянии другой ветки (или нескольких веток в случае слияния типа «осьминог»).

С параметром --no-squash выполняет слияние и фиксирует результат. Этот параметр можно использовать для переопределения --squash.

При использовании --squash параметр --commit недопустим, и команда завершится с ошибкой.

Полезен только при слиянии.

По умолчанию запускаются хуки pre-merge и commit-msg. Если указан параметр --no-verify, они пропускаются. См. также githooks[5]. Полезен только при слиянии.

Использует указанную стратегию слияния; параметр можно указать несколько раз, задав порядок их применения. Если параметр -s не указан, вместо него используется встроенный список стратегий (ort при слиянии одной вершины, в противном случае — octopus).

Передаёт выбранной стратегии слияния параметр, относящийся к этой стратегии.

Проверяет, что вершина коммита сливаемой боковой ветки подписана действительным ключом, то есть ключом с действительным идентификатором пользователя: в модели доверия по умолчанию это означает, что подписывающий ключ заверен доверенным ключом. Если вершина коммита боковой ветки не подписана действительным ключом, слияние прерывается.

Полезен только при слиянии.

Синонимы для --stat и --no-stat; эти параметры устарели и будут удалены в будущем.

Автоматически создаёт временную запись в stash перед началом операции, записывает её в ссылку MERGE_AUTOSTASH и применяет её после завершения операции. Это позволяет выполнять операцию с рабочим деревом, содержащим незакоммиченные изменения. Однако используйте этот параметр осторожно: при применении stash после успешного слияния могут возникнуть нетривиальные конфликты.

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

Полезен только при слиянии.

Если вы хотите, чтобы git pull всегда использовал --rebase вместо слияния, см. pull.rebase, branch.<name>.rebase и branch.autoSetupRebase в git-config[1].

+

Это сокращённая запись для --rebase=false.

Получить данные со всех удалённых репозиториев, кроме тех, для которых задана переменная конфигурации remote.<name>.skipFetchAll. Это переопределяет переменную конфигурации fetch.all.

Добавить имена ссылок и имена объектов полученных ссылок к существующему содержимому .git/FETCH_HEAD. Без этого параметра старые данные в .git/FETCH_HEAD будут перезаписаны.

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

Ограничить получение указанным числом коммитов от вершины истории каждой удалённой ветки. Если данные получаются в shallow репозиторий, созданный командой git clone с параметром --depth=<depth> (см. git-clone[1]), углубить или сократить историю до указанного числа коммитов. Теги для углублённых коммитов не получаются.

Аналогично --depth, но задаёт число коммитов от текущей границы неглубокой истории, а не от вершины истории каждой удалённой ветки.

Углубить или сократить историю неглубокого репозитория, включив все достижимые коммиты после <date>.

Углубить или сократить историю неглубокого репозитория, исключив коммиты, достижимые из указанной удалённой ветки или тега. Этот параметр можно указывать несколько раз.

Если исходный репозиторий полный, преобразовать неглубокий репозиторий в полный, сняв все ограничения, накладываемые неглубокими репозиториями.

Если исходный репозиторий неглубокий, получить максимально возможное количество данных, чтобы история текущего репозитория совпадала с историей исходного.

По умолчанию при получении данных из неглубокого репозитория git fetch отклоняет ссылки, для обновления которых требуется изменить .git/shallow. Этот параметр обновляет .git/shallow и принимает такие ссылки.

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

--negotiation-restrict — предпочтительное название этого параметра; --negotiation-tip принимается как синоним.

Этот параметр можно указывать несколько раз; в таком случае Git сообщит о коммитах, достижимых из любого из указанных коммитов.

Аргументом этого параметра может быть шаблон glob для имён ссылок, ссылка или SHA-1 коммита (возможно, сокращённый). Указание шаблона glob равносильно многократному указанию этого параметра — по одному разу для каждого совпадающего имени ссылки.

См. также переменные конфигурации fetch.negotiationAlgorithm и push.negotiate, описанные в git-config[1], а также параметр --negotiate-only ниже.

Гарантировать, что коммиты в указанных вершинах всегда будут отправляться в виде строк «have» во время согласования получения данных, независимо от выбранного алгоритма согласования. Это полезно, чтобы гарантировать учёт общей истории, достижимой из определённых ссылок, даже если --negotiation-restrict ограничивает набор вершин или алгоритм согласования иначе пропустил бы их.

Этот параметр можно указывать несколько раз; в таком случае каждый коммит отправляется безусловно.

Аргументом может быть точное имя ссылки (например, refs/heads/release), хеш объекта или шаблон glob (например, refs/heads/release/{asterisk}). Синтаксис шаблонов совпадает с синтаксисом для --negotiation-restrict.

Если используется --negotiation-restrict, сначала набор have ограничивается этим параметром, а затем расширяется за счёт вершин, указанных в --negotiation-include.

Если этот параметр не указан в командной строке, вместо него используются значения конфигурации remote.<name>.negotiationInclude для текущего удалённого репозитория.

Не получать данные с сервера, а вместо этого вывести предков предоставленных аргументов --negotiation-restrict=, которые являются общими с сервером.

Несовместим с --recurse-submodules=(yes|on-demand). Внутри Git этот параметр используется для реализации параметра push.negotiate; см. git-config[1].

Показать, что будет сделано, не внося изменений.

Вывести данные в стандартный поток вывода в удобном для разбора скриптами формате. Подробности см. в разделе OUTPUT документации git-fetch[1].

Несовместим с --recurse-submodules=(yes|on-demand) и имеет приоритет над параметром конфигурации fetch.output.

Использовать функцию частичного клонирования и запросить у сервера подмножество достижимых объектов в соответствии с заданным фильтром объектов. При использовании --filter предоставленный <filter-spec> используется для частичного получения данных.

Если используется --filter=auto, спецификация фильтра определяется автоматически путём объединения спецификаций фильтров, объявленных сервером для принимаемых клиентом удалённых репозиториев-обещателей (см. gitprotocol-v2[5] и параметр конфигурации promisor.acceptFromServer в git-config[1]).

Подробные сведения обо всех остальных доступных спецификациях фильтров см. в описании параметра --filter=<filter-spec> в git-rev-list[1].

Например, --filter=blob:none отфильтрует все blob-объекты (содержимое файлов), пока они не понадобятся Git. Также --filter=blob:limit=<size> отфильтрует все blob-объекты размером не менее <size>.

При использовании git fetch со спецификацией ссылки <src>:<dst> локальная ветка может быть не обновлена, как описано в разделе <refspec> документации git-fetch[1]. Этот параметр отменяет эту проверку.

Сохранить загруженный pack-файл.

Изменить настроенную спецификацию ссылок, чтобы поместить все ссылки в пространство имён refs/prefetch/. См. задачу prefetch в git-maintenance[1].

Перед получением данных удалить все ссылки отслеживания удалённых веток, которых больше нет в удалённом репозитории. Теги не удаляются, если они получаются только благодаря стандартному автоматическому отслеживанию тегов или параметру --tags. Однако если теги получаются по явной спецификации ссылок (в командной строке или в конфигурации удалённого репозитория, например, если удалённый репозиторий был клонирован с параметром --mirror), они также подлежат удалению. Указание --prune-tags — это сокращённая запись спецификации ссылки на тег.

По умолчанию теги, указывающие на объекты, загружаемые из удалённого репозитория, извлекаются и сохраняются локально. Этот параметр отключает автоматическое следование тегам. Поведение по умолчанию для удалённого репозитория можно задать параметром remote.<name>.tagOpt. См. git-config[1].

При получении ссылок, перечисленных в командной строке, использовать указанную спецификацию ссылок (можно указать несколько раз) для сопоставления ссылок с ветками отслеживания удалённых репозиториев вместо значений переменных конфигурации remote.<name>.fetch для удалённого репозитория. Если для параметра --refmap указать пустой <refspec>, Git проигнорирует настроенные спецификации ссылок и будет использовать только спецификации, переданные в аргументах командной строки. Подробности см. в разделе «Настроенные ветки отслеживания удалённых репозиториев».

Получить все теги из удалённого репозитория (т. е. получить удалённые теги refs/tags/* в локальные теги с теми же именами) в дополнение ко всему, что было бы получено в обычном случае. Использование этого параметра само по себе не приводит к удалению тегов, даже если указан --prune (однако теги всё же могут быть удалены, если они также являются назначением явной спецификации ссылок; см. --prune).

Выполнять все виды получения данных параллельно, используя не более <n> заданий одновременно.

Значение 0 означает, что будет использовано разумное значение по умолчанию.

Если указан параметр --multiple, различные удалённые репозитории будут опрашиваться параллельно. Если получаются данные из нескольких подмодулей, они будут получаться параллельно. Чтобы управлять ими независимо, используйте параметры конфигурации fetch.parallel и submodule.fetchJobs (см. git-config[1]).

Обычно рекурсивное получение данных и получение из нескольких удалённых репозиториев выполняются быстрее в параллельном режиме. По умолчанию получение данных выполняется последовательно, а не параллельно.

Если получение данных из удалённого репозитория прошло успешно, добавить вышестоящую (отслеживаемую) ссылку, используемую командами git-pull[1] без аргументов и другими командами. Дополнительные сведения см. в описании branch.<name>.merge и branch.<name>.remote в git-config[1].

Если этот параметр указан, а репозиторием, из которого выполняется получение данных, управляет git fetch-pack, --exec=<upload-pack> передаётся команде, чтобы указать нестандартный путь к команде, выполняемой на другой стороне.

По умолчанию сведения о ходе выполнения выводятся в стандартный поток ошибок, если он подключён к терминалу, за исключением случая, когда указан -q. Этот флаг принудительно включает вывод сведений о ходе выполнения, даже если стандартный поток ошибок не направлен в терминал.

Передать указанную строку серверу при взаимодействии с использованием протокола версии 2. Указанная строка не должна содержать символ NUL или LF. Обработка сервером параметров, в том числе неизвестных, зависит от конкретного сервера. Если указано несколько параметров --server-option=<option>, все они передаются другой стороне в порядке, заданном в командной строке. Если в командной строке не указан ни один параметр --server-option=<option>, вместо них используются значения переменной конфигурации remote.<name>.serverOption.

По умолчанию Git проверяет, была ли ветка принудительно обновлена во время получения данных. Эту проверку можно отключить с помощью fetch.showForcedUpdates, но параметр --show-forced-updates гарантирует её выполнение. См. git-config[1].

По умолчанию Git проверяет, была ли ветка принудительно обновлена во время получения данных. Передайте --no-show-forced-updates или установите для fetch.showForcedUpdates значение false, чтобы пропустить эту проверку ради повышения производительности. При использовании во время git-pull параметр --ff-only всё равно проверит принудительные обновления перед попыткой выполнить перемотку вперёд. См. git-config[1].

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

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

«Удалённый» репозиторий, являющийся источником операции получения данных или извлечения изменений. Этот параметр может быть URL-адресом (см. раздел URL-адреса Git ниже) или именем удалённого репозитория (см. раздел Удалённые репозитории ниже).

Задаёт, какие ссылки получать и какие локальные ссылки обновлять. Если в командной строке не указаны <refspec>ы, ссылки для получения считываются из переменных remote.<repository>.fetch (см. раздел «НАСТРОЕННЫЕ ВЕТКИ ОТСЛЕЖИВАНИЯ УДАЛЁННЫХ РЕПОЗИТОРИЕВ» в git-fetch[1]).

Формат параметра <refspec>: необязательный знак «плюс» +, за которым следует исходная <src>, двоеточие : и целевая <dst>. Двоеточие можно опустить, если <dst> пуста. <src> обычно является ссылкой или шаблоном glob с одной * для сопоставления набора ссылок, но также может быть полным шестнадцатеричным именем объекта.

<refspec> может содержать * в своей <src> для указания простого сопоставления с шаблоном. Такая спецификация ссылок работает как шаблон glob, который сопоставляется с любой ссылкой, соответствующей шаблону. Шаблон <refspec> должен содержать ровно одну * как в <src>, так и в <dst>. Сопоставленные ссылки будут отображаться в целевое пространство заменой * содержимым, совпавшим с исходным значением.

Если перед спецификацией ссылок стоит ^, она интерпретируется как отрицательная спецификация ссылок. Вместо указания ссылок для получения или локальных ссылок для обновления такая спецификация указывает ссылки, которые нужно исключить. Ссылка считается подходящей, если она соответствует хотя бы одной положительной спецификации ссылок и не соответствует ни одной отрицательной. Отрицательные спецификации ссылок полезны для ограничения области действия шаблонной спецификации, чтобы исключить из неё конкретные ссылки. Отрицательные спецификации ссылок сами могут быть шаблонными, однако они могут содержать только <src> и не задают <dst>. Полные шестнадцатеричные имена объектов также не поддерживаются.

tag <tag> означает то же, что и refs/tags/<tag>:refs/tags/<tag>; этот параметр запрашивает получение всего, вплоть до указанного тега.

Получается удалённая ссылка, соответствующая <src>, и, если <dst> не является пустой строкой, предпринимается попытка обновить соответствующую ей локальную ссылку.

Возможность выполнить это обновление без --force зависит от пространства имён ссылок, в которое выполняется получение, типа получаемого объекта и того, считается ли обновление перемоткой вперёд. В общем случае при получении применяются те же правила, что и при отправке; см. раздел <refspec>... в git-push[1]. Исключения из этих правил, относящиеся к git fetch, перечислены ниже.

До версии Git 2.20, в отличие от отправки с помощью git-push[1], любые обновления refs/tags/* принимались без + в спецификации ссылок (или --force). При получении данных все обновления тегов с удалённого репозитория без разбора считались принудительными. Начиная с версии Git 2.20 получение данных для обновления refs/tags/* работает так же, как и при отправке. То есть любые обновления будут отклонены без + в спецификации ссылок (или --force).

В отличие от отправки с помощью git-push[1], любые обновления за пределами refs/{tags,heads}/* принимаются без + в спецификации ссылок (или --force), будь то замена, например, объекта дерева на blob-объект или одного коммита другим, у которого предыдущий коммит не является предком, и т. п.

В отличие от отправки с помощью git-push[1], конфигурации, изменяющей эти правила, не существует, как и перехватчика pre-fetch, аналогичного перехватчику pre-receive.

Как и при отправке с помощью git-push[1], все описанные выше правила о недопустимых обновлениях можно переопределить, добавив необязательный начальный + к спецификации ссылок (или используя параметр командной строки --force). Единственное исключение: никакое принудительное обновление не заставит пространство имён refs/heads/* принять объект, не являющийся коммитом.