Git pull не обновляет файлы
Обновлено: 21.11.2024
Извлекать ветки и/или теги (совместно именуемые ссылками) из одного или нескольких других репозиториев вместе с объектами, необходимыми для завершения их истории. Обновлены ветки удаленного отслеживания (см. описание способов управления этим поведением ниже).
По умолчанию любой тег, указывающий на извлекаемые истории, также извлекается; эффект заключается в извлечении тегов, указывающих на интересующие вас ветки. Это поведение по умолчанию можно изменить с помощью параметров --tags или --no-tags или путем настройки remote. .tagОпт. Используя refspec, который явно выбирает теги, вы также можете получать теги, которые не указывают на интересующие вас ветки.
git fetch может выполнять выборку либо из одного именованного репозитория или URL-адреса, либо из нескольких репозиториев одновременно, если он задан и есть пульты. запись в конфигурационном файле. (См. git-config[1]).
Если удаленный не указан, по умолчанию будет использоваться удаленный источник, если для текущей ветви не настроена восходящая ветвь.
Имена извлеченных ссылок вместе с именами объектов, на которые они указывают, записываются в .git/FETCH_HEAD . Эта информация может использоваться сценариями или другими командами git, такими как git-pull[1].
ВАРИАНТЫ
Получить все пульты.
Добавить имена ссылок и имена объектов извлеченных ссылок к существующему содержимому .git/FETCH_HEAD . Без этой опции старые данные в .git/FETCH_HEAD будут перезаписаны.
Используйте атомарную транзакцию для обновления локальных ссылок. Либо обновляются все ссылки, либо в случае ошибки ссылки не обновляются.
Ограничьте выборку указанным количеством коммитов из верхушки истории каждой удаленной ветки. При выборке в репозиторий shallow, созданный git clone с параметром --depth= (см. git-clone[1]), увеличьте или сократите историю до указанного количества коммитов. Теги для углубленных коммитов не извлекаются.
Аналогичен параметру --depth, за исключением того, что он указывает количество коммитов от текущей неглубокой границы, а не от вершины истории каждой удаленной ветки.
Углубить или сократить историю неглубокого репозитория, чтобы включить все доступные коммиты после .
Углубить или сократить историю неглубокого репозитория, чтобы исключить коммиты, доступные из указанной удаленной ветки или тега. Этот параметр можно указать несколько раз.
Если исходный репозиторий завершен, преобразуйте неглубокий репозиторий в полный, сняв все ограничения, накладываемые неглубокими репозиториями.
Если исходный репозиторий неглубокий, извлеките как можно больше, чтобы текущий репозиторий имел ту же историю, что и исходный репозиторий.
По умолчанию при выборке из мелкого репозитория git fetch отклоняет ссылки, требующие обновления .git/shallow. Эта опция обновляет .git/shallow и принимает такие ссылки.
По умолчанию Git будет сообщать серверу о коммитах, доступных из всех локальных ссылок, чтобы найти общие коммиты и попытаться уменьшить размер получаемого пакетного файла. Если указано, Git будет сообщать только о коммитах, доступных из данных советов. Это полезно для ускорения выборки, когда пользователь знает, какая локальная ссылка, скорее всего, имеет общие фиксации с извлекаемой исходной ссылкой.
Эта опция может быть указана более одного раза; если это так, Git сообщит о коммитах, доступных из любого из заданных коммитов.
Аргументом этой опции может быть подстановка имен ссылок, ссылка или (возможно, сокращенный) SHA-1 фиксации. Указание глобуса эквивалентно указанию этого параметра несколько раз, по одному для каждого совпадающего имени ссылки.
См. также переменные конфигурации fetch.negotiationAlgorithm и push.negotiate, описанные в git-config[1], и параметр --negotiate-only ниже.
Не получать ничего с сервера, а вместо этого вывести предков предоставленных --negotiation-tip=* аргументов, которые у нас общие с сервером.
Внутренне это используется для реализации параметра push.negotiate, см. git-config[1].
Покажите, что будет сделано без внесения каких-либо изменений.
Запишите список извлеченных удаленных ссылок в файле FETCH_HEAD непосредственно в $GIT_DIR . Это значение по умолчанию. Передача --no-write-fetch-head из командной строки указывает Git не записывать файл. При использовании параметра --dry-run файл никогда не записывается.
Когда git fetch используется с : refspec, он может отказаться обновлять локальную ветку, как описано в части ниже. Этот параметр переопределяет эту проверку.
Сохранить загруженный пакет.
Разрешить указывать несколько аргументов и. Можно не указывать s.
Запустите git Maintenance run --auto в конце, чтобы при необходимости выполнить автоматическое обслуживание репозитория. ( --[no-]auto-gc является синонимом.) Это включено по умолчанию.
Запишите график коммитов после выборки. Это переопределяет параметр конфигурации fetch.writeCommitGraph .
Измените настроенную спецификацию ссылок, чтобы поместить все ссылки в пространство имен refs/prefetch/.См. задачу предварительной выборки в git-maintenance[1].
Перед извлечением удалите все ссылки на удаленное отслеживание, которые больше не существуют на удаленном сервере. Теги не подлежат сокращению, если они извлекаются только из-за автоматического следования тегов по умолчанию или из-за опции --tags. Однако, если теги извлекаются из-за явного указания refspec (либо в командной строке, либо в удаленной конфигурации, например, если удаленный сервер был клонирован с опцией --mirror), они также подлежат сокращению. Предоставление --prune-tags является сокращением для предоставления тега refspec.
Дополнительную информацию см. в разделе ОБРЕЗКА ниже.
Перед извлечением удалите все локальные теги, которые больше не существуют на удаленном компьютере, если включен параметр --prune. Эту опцию следует использовать более осторожно, в отличие от --prune она удалит все созданные локальные ссылки (локальные теги). Этот параметр является сокращением для предоставления явного тега refspec вместе с --prune , см. обсуждение этого в его документации.
Дополнительную информацию см. в разделе ОБРЕЗКА ниже.
По умолчанию теги, указывающие на объекты, загруженные из удаленного репозитория, извлекаются и сохраняются локально. Этот параметр отключает автоматическое отслеживание тегов. Поведение по умолчанию для пульта дистанционного управления может быть указано с помощью пульта дистанционного управления. Настройка .tagOpt. См. git-config[1].
При извлечении ссылок, перечисленных в командной строке, используйте указанную спецификацию ссылок (можно указать более одного раза), чтобы сопоставить ссылки с ветвями удаленного отслеживания вместо значений переменных конфигурации remote.*.fetch для удаленного репозитория. . Предоставление пустого параметра --refmap заставляет Git игнорировать настроенные спецификации ссылок и полностью полагаться на спецификации ссылок, предоставленные в качестве аргументов командной строки. Дополнительные сведения см. в разделе «Настроенные ветки удаленного отслеживания».
Выбрать все теги с удаленного устройства (т. е. преобразовать удаленные теги refs/tags/* в локальные теги с тем же именем) в дополнение к тому, что в противном случае было бы получено. Использование только этой опции не подвергает теги сокращению, даже если используется --prune (хотя теги могут быть удалены в любом случае, если они также являются целью явной спецификации ссылки; см. --prune ).
Этот параметр определяет, должны ли и при каких условиях также извлекаться новые фиксации заполненных подмодулей. Его можно использовать как логическую опцию, чтобы полностью отключить рекурсию, если установлено значение нет, или безоговорочно выполнить рекурсию во все заполняемые подмодули, если установлено значение да, что является значением по умолчанию, когда этот параметр используется без значения. Используйте on-demand для рекурсии в заполненный подмодуль только тогда, когда суперпроект получает фиксацию, которая обновляет ссылку подмодуля на фиксацию, которой еще нет в локальном клоне подмодуля. По умолчанию используется on-demand, если не установлен fetch.recurseSubmodules (см. git-config[1]).
Количество параллельных дочерних элементов, которые будут использоваться для всех форм выборки.
Если был указан параметр --multiple, разные удаленные устройства будут загружаться параллельно. Если выбрано несколько подмодулей, они будут загружаться параллельно. Чтобы управлять ими независимо, используйте настройки конфигурации fetch.parallel и submodule.fetchJobs (см. git-config[1]).
Как правило, параллельная рекурсивная и мультиудаленная выборка выполняется быстрее. По умолчанию выборки выполняются последовательно, а не параллельно.
Отключить рекурсивную выборку подмодулей (это имеет тот же эффект, что и использование параметра --recurse-submodules=no).
Если удаленный объект получен успешно, добавьте восходящую (отслеживающую) ссылку, используемую безаргументной git-pull[1] и другими командами. Для получения дополнительной информации см. ветку. .слияние и ветвление. .remote в git-config[1].
к путям, напечатанным в информативных сообщениях, таких как "Выбор подмодуля foo". Этот параметр используется внутри при рекурсии по подмодулям.
Этот параметр используется для временного предоставления неотрицательного значения по умолчанию для параметра --recurse-submodules. Все другие методы настройки рекурсии подмодуля fetch (например, настройки в gitmodules[5] и git-config[1]) переопределяют этот параметр, равно как и прямое указание --[no-]recurse-submodules.
По умолчанию git fetch отказывается обновлять заголовок, соответствующий текущей ветке. Этот флаг отключает проверку. Это исключительно для внутреннего использования git pull для связи с git fetch, и если вы не реализуете свой собственный Porcelain, вы не должны его использовать.
Если указано, а репозиторий для извлечения обрабатывается git fetch-pack, --exec= передается команде, чтобы указать путь не по умолчанию для команды, выполняемой на другом конце. .
Передайте --quiet в git-fetch-pack и отключите все другие внутренние команды git. Ход выполнения не передается в стандартный поток ошибок.
Состояние выполнения сообщается в стандартном потоке ошибок по умолчанию, когда он подключен к терминалу, если не указан параметр -q.Этот флаг принудительно устанавливает состояние выполнения, даже если стандартный поток ошибок не направлен на терминал.
Передать данную строку на сервер при обмене данными по протоколу версии 2. Данная строка не должна содержать символы NUL или LF. Обработка сервером параметров сервера, включая неизвестные, зависит от сервера. Если задано несколько параметров --server-option=, все они отправляются другой стороне в порядке, указанном в командной строке.
По умолчанию 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 ниже), либо именем удаленного устройства (см. раздел ПУЛЬТЫ ниже).
Имя, относящееся к списку репозиториев в качестве значения remotes. в файле конфигурации. (См. git-config[1]).
Указывает, какие ссылки нужно получить и какие локальные ссылки обновить. Когда в командной строке нет s, ссылки для извлечения считываются с удаленного компьютера. вместо этого переменные .fetch (см. НАСТРАИВАЕМЫЕ ФИЛИАЛЫ УДАЛЕННОГО ОТСЛЕЖИВАНИЯ ниже).
Формат параметра: необязательный плюс + , за которым следует источник , за которым следует двоеточие : , за которым следует конечная ссылка . Двоеточие можно опустить, если оно пусто. обычно это ссылка, но это также может быть полное шестнадцатеричное имя объекта.
A может содержать *, чтобы указать простое совпадение с образцом. Такая refspec функционирует как glob, который соответствует любой ссылке с таким же префиксом. Шаблон должен иметь * как в , так и в . Он сопоставит ссылки с местом назначения, заменив * на содержимое, соответствующее источнику.
Если спецификация ссылки начинается с префикса ^ , она будет интерпретироваться как отрицательная спецификация ссылки. Вместо того, чтобы указывать, какие ссылки извлекать или какие локальные ссылки обновлять, такая спецификация ссылок вместо этого указывает ссылки, которые необходимо исключить. Ссылка будет считаться соответствующей, если она соответствует хотя бы одной положительной спецификации ссылки и не соответствует ни одной отрицательной спецификации ссылки. Отрицательные спецификации ссылок могут быть полезны для ограничения объема спецификации ссылок шаблона, чтобы она не включала определенные ссылки. Отрицательные спецификации ссылок сами по себе могут быть спецификациями ссылок шаблонов. Однако они могут содержать только и не указывать . Полные шестнадцатеричные имена объектов также не поддерживаются.
тег означает то же, что и refs/tags/ :refs/tags/ ; он запрашивает выборку всего до данного тега.
Выбирается совпадающая удаленная ссылка, и если это не пустая строка, предпринимается попытка обновить совпадающую с ней локальную ссылку.
Разрешено ли это обновление без --force, зависит от пространства имен ref, в которое оно извлекается, типа извлекаемого объекта и от того, считается ли обновление ускоренной перемоткой вперед. Как правило, для выборки применяются те же правила, что и для отправки, см. раздел git-push[1] для того, что это такое. Исключения из этих правил, относящихся к git fetch, указаны ниже.
До Git версии 2.20, в отличие от отправки с помощью git-push[1], любые обновления refs/tags/* принимались без + в refspec (или --force ). При извлечении мы беспорядочно считали все обновления тегов с удаленного устройства принудительными. Начиная с Git версии 2.20, выборка для обновления refs/tags/* работает так же, как и при отправке. т.е. любые обновления будут отклонены без + в refspec (или --force ).
В отличие от отправки с помощью git-push[1], любые обновления за пределами refs//* будут приниматься без + в refspec (или --force ), будь то подкачка, например. объект дерева для большого двоичного объекта или коммит для другого коммита, у которого нет предыдущего коммита в качестве предка и т. д.
В отличие от отправки с помощью git-push[1], здесь нет конфигурации, которая изменит эти правила, и нет ничего похожего на обработчик предварительной выборки, аналогичный обработчику предварительного получения.
Как и в случае отправки с помощью git-push[1], все описанные выше правила о том, что не разрешено в качестве обновления, можно переопределить, добавив необязательный начальный + к refspec (или используя параметр командной строки --force). . Единственным исключением из этого правила является то, что никакие принудительные меры не заставят пространство имен refs/heads/* принять незафиксированный объект.
Чтение спецификаций ссылок, по одной на строку, из стандартного ввода в дополнение к тем, которые предоставлены в качестве аргументов. Формат "тег" не поддерживается.
URL-адреса GIT
Как правило, URL-адреса содержат информацию о транспортном протоколе, адрес удаленного сервера и путь к репозиторию.В зависимости от транспортного протокола часть этой информации может отсутствовать.
Я использую Git для совместной работы с другими пользователями, но сегодня я не могу получить последние изменения в некоторых файлах с помощью "git pull" и не вижу изменений в "git log".
В чем может быть проблема?
Кажется, ничего нет для получения обновлений. Вы уверены, что файлы правильно зафиксированы другим пользователем и находятся в том же репозитории? Отсутствие журналов вызывает сомнения в этом направлении.
У меня та же проблема (я единственный, кто занимается этой проблемой). Это сводит меня с ума! В течение последних нескольких дней я выполнял ручное слияние, потому что извлечения просто не происходило. Но ручное слияние приводит к появлению всевозможных предупреждений, что пугает всю команду.
10 ответов 10
что сработало для меня,
- удалить папку .git
- скопировать .git из другого репозитория
- сейчас git checkout
Прежде чем удалять, попробуйте
Вам нужно будет заменить master на соответствующую ветку, которая теперь по умолчанию является main .
Последние два шага (извлечение и сброс) мне помогли. Кстати, «копировать .git из другого репо» не должно работать, так как каждый .git содержит информацию, относящуюся к репозиторию, которому он принадлежит.
Что помогло мне
Это показало мне, что имена некоторых файлов слишком длинные, чтобы git мог их извлечь из моего репозитория, и, следовательно, несоответствие и неправильные сборки.
Поэтому я побежал за исправлением и снова сделал полную перезагрузку.
К счастью, это сработало.
В моем случае проблема заключалась в наличии файла index.lock в папке .git. Я удалил это, и вытягивание сработало.
Проверьте текущую ветку.
Если вы не в ветке, вы находитесь в режиме HEAD, и git pull ничего не объединит.
Этот журнал git поможет убедиться, что вы видите какие-либо новые коммиты в извлеченных ветвях (то есть ветках удаленного отслеживания).
Я использую этот псевдоним git log для отображения этих коммитов в виде графика.
У вас может быть незавершенное слияние, которое препятствует извлечению. Проверьте, не выполняется ли фиксация.
Я просто хотел добавить еще один случай, когда это могло произойти. Я использовал разреженную кассу. По какой-то причине у меня был каталог в моем рабочем дереве, который, как я думал, был включен в разреженную проверку (я думал, что он указан в .git/info/sparse-checkout ), но не был (я удалил его из .git/info /sparse-checkout по какой-то причине я сейчас забыл.) Так что это просто игнорировалось pull, checkout, reset или любыми другими командами. Это было очень запутанно, пока я не начал копировать разреженную конфигурацию проверки в новом, свежем клоне и не понял ошибку.
Это произойдет только в том случае, если вы используете разреженную кассу. Если вы не используете разреженную проверку, этого не может произойти. (Проверьте git config, чтобы увидеть, включен ли sparseCheckout, и проверьте наличие .git/info/sparse-checkout, но вы бы знали, если бы делали это, так как я думаю, что пользователь все равно должен настраивать его вручную. ) (Погуглите, если вам интересно, что это такое — это всего лишь простой механизм исключения файлов и каталогов из проверки, которые в противном случае отслеживались бы/извлекались/извлекались и т. д.)
После смены источника на SSH все снова пошло гладко.
(Чтобы получить URL-адрес SSH, просто нажмите кнопку "Клонировать" в веб-интерфейсе Gitlab/Github и выберите "Клонировать с помощью SSH")
Есть 2 возможных сценария:
1. Если у вас есть учетная запись в Bitbucket, gitlab и т. д.
Возможно, вам придется сначала выполнить синхронизацию с вашим каталогом fork, а затем выполнить git pull в вашей локальной ветке. По сути, вам нужно перебазировать свою копию форка, чтобы синхронизироваться с удаленным мастером и выполнить git pull в вашей локальной копии.
2. Просто попробуйте перебазировать локальную рабочую копию, чтобы она синхронизировалась с удаленным мастером.
git reset --hard origin/master
у меня работает, но вам нужно зайти внутрь папки, а затем использовать эту команду не только в родительской папке.
для меня это были коммиты, которые я сделал локально. Эти коммиты изменяют что-то, что я хочу вытащить. Таким образом, git pull не получает файл из источника
При работе над проектом в команде вы можете столкнуться с подобными сообщениями об ошибках при попытке выполнить "git pull" в своем репозитории:
Причина подобных сообщений об ошибках довольно проста: у вас есть локальные изменения, которые будут перезаписаны входящими новыми изменениями, которые "git pull" принесет.
По очевидным причинам безопасности Git никогда просто не перезапишет ваши изменения. Это также означает, что в Git нет функции принудительного извлечения, но мы, конечно, можем выполнить пару шагов для эмуляции такой команды.
Шаг 1. Очистка рабочей копии
Во-первых, вам нужно убедиться, что ваша рабочая копия больше не содержит этих конфликтующих изменений. Этого можно добиться двумя способами:
a) Сохранение локальных изменений в тайнике
Если вы хотите сохранить свои локальные изменения, вы можете безопасно хранить их в тайнике. Они будут доступны на случай, если вы захотите вернуть их позже.
b) Отказ от локальных изменений
Если вы уверены, что они вам больше не нужны, вы можете полностью отменить локальные изменения:
Если у вас также есть неотслеживаемые/новые файлы, вам также придется использовать команду "git clean", чтобы избавиться от них:
Будьте осторожны с этими командами: отмена локальных изменений и неотслеживаемых файлов невозможна!
Шаг 2. Потяните еще раз
После того, как вы очистите все локальные изменения/неотслеживаемые файлы, которые могли бы быть перезаписаны, пулл наконец заработает:
Автосохранение в башне
Если вы используете клиент Tower Git, вы заметите, что он помогает вам избежать следующих ситуаций: всякий раз, когда у вас есть незафиксированные локальные изменения и вы хотите выполнить действие, такое как получение, получение или слияние, Tower автоматически предложит безопасно сохраните эти изменения в тайнике.
Таким образом, вам не нужно предпринимать никаких дополнительных действий и больше не нужно об этом думать.
Подробнее
- Прочитайте главу «Интеграция удаленных изменений» в нашей бесплатной онлайн-книге.
- Часто задаваемые вопросы о Git и управлении версиями
Получите нашу популярную памятку по Git бесплатно!
Самые важные команды вы найдете на лицевой стороне, а полезные советы — на обратной. Более 100 000 разработчиков скачали его, чтобы сделать Git немного проще.
О нас
Как создатели Tower, лучшего клиента Git для Mac и Windows, мы помогаем более чем 100 000 пользователей в таких компаниях, как Apple, Google, Amazon, Twitter и Ebay, получить максимальную отдачу от Git.
Как и в случае с Tower, наша миссия с этой платформой – помочь людям стать лучшими профессионалами.
Вот почему мы бесплатно предоставляем наши руководства, видеоролики и памятки (об управлении версиями в Git и многих других темах).
© Tower, 2010-2022. Упомянутые названия продуктов и логотипы являются собственностью соответствующих владельцев.
Включает изменения из удаленного репозитория в текущую ветку. Если текущая ветвь находится позади удаленной, то по умолчанию она перемотает текущую ветвь вперед, чтобы она соответствовала удаленной. Если текущая ветвь и удаленная разошлись, пользователю необходимо указать, как согласовать расходящиеся ветки с --rebase или --no-rebase (или соответствующим параметром конфигурации в pull.rebase ).
Точнее, git pull запускает git fetch с заданными параметрами, а затем, в зависимости от параметров конфигурации или флагов командной строки, вызывает либо git rebase, либо git merge для согласования расходящихся ветвей.
должно быть именем удаленного репозитория, переданным в git-fetch[1]. может назвать произвольную удаленную ссылку (например, имя тега) или даже набор ссылок с соответствующими ветвями удаленного отслеживания (например, refs/heads/*:refs/remotes/origin/*), но обычно это имя ветки в удаленном репозитории.
Значения по умолчанию для и
считываются из конфигурации "удаленный" и "слияние" для текущей ветки, установленной git-branch[1] --track .
Предположим, что существует следующая история и текущая ветвь является «главной»:
Затем «git pull» извлечет и воспроизведет изменения из удаленной основной ветки, поскольку она отклонилась от локальной основной ветки (т. е. E) до текущей фиксации ( C ) поверх основной, и запишет результат в новую фиксацию. вместе с именами двух родительских коммитов и сообщением журнала от пользователя, описывающим изменения.
Подробнее см. в git-merge[1], в том числе о том, как представляются и обрабатываются конфликты.
В Git 1.7.0 или более поздних версиях для отмены конфликтующего слияния используйте git reset --merge . Предупреждение. В старых версиях Git запуск git pull с незафиксированными изменениями не рекомендуется: хотя это и возможно, это оставляет вас в состоянии, из которого может быть трудно выйти в случае конфликта. р>
Если какие-либо удаленные изменения пересекаются с локальными незафиксированными изменениями, слияние будет автоматически отменено, а рабочее дерево останется нетронутым. Как правило, лучше получить любые локальные изменения в рабочем состоянии, прежде чем извлекать или скрывать их с помощью git-stash[1].
ВАРИАНТЫ
Это передается как в базовый git-fetch для подавления отчетов во время передачи, так и в базовый git-merge для подавления выходных данных во время слияния.
Передайте --verbose в git-fetch и git-merge.
Эта опция определяет, должны ли извлекаться новые коммиты заполненных подмодулей, а также должны ли обновляться рабочие деревья активных подмодулей (см. git-fetch[1], git-config[1] и gitmodules[5]). .
Если проверка выполняется с помощью перебазирования, локальные фиксации подмодулей также перебазируются.
Если обновление выполняется посредством слияния, конфликты подмодулей разрешаются и извлекаются.
Параметры, связанные со слиянием
Выполните слияние и зафиксируйте результат. Эту опцию можно использовать для переопределения --no-commit. Полезно только при слиянии.
С --no-commit выполнить слияние и остановить непосредственно перед созданием коммита слияния, чтобы дать пользователю возможность проверить и дополнительно настроить результат слияния перед фиксацией.
Обратите внимание, что быстрые обновления не создают фиксацию слияния, поэтому невозможно остановить эти слияния с помощью --no-commit. Таким образом, если вы хотите, чтобы ваша ветка не была изменена или обновлена командой слияния, используйте --no-ff с --no-commit.
Вызовите редактор перед выполнением успешного механического слияния, чтобы дополнительно отредактировать автоматически сгенерированное сообщение слияния, чтобы пользователь мог объяснить и обосновать слияние. Можно использовать параметр --no-edit, чтобы принять автоматически сгенерированное сообщение (как правило, это не рекомендуется).
Старые сценарии могут зависеть от исторического поведения, когда пользователь не может редактировать сообщение журнала слияния. Они увидят открытый редактор при запуске git merge . Чтобы облегчить настройку таких скриптов на обновленное поведение, для переменной среды GIT_MERGE_AUTOEDIT в их начале можно установить значение no.
Этот параметр определяет, как сообщение слияния будет очищаться перед фиксацией. См. git-commit[1] для более подробной информации. Кроме того, если задано значение scissors , ножницы будут добавлены к MERGE_MSG перед передачей механизму фиксации в случае конфликта слияния.
Обновляйте новую историю только в том случае, если нет другой локальной истории. Это значение по умолчанию, если не предоставлен метод согласования расходящихся историй (через флаги --rebase=*).
При слиянии вместо перемещения указывает, как обрабатывается слияние, когда объединенная история уже является потомком текущей истории. Если запрашивается слияние, --ff используется по умолчанию, за исключением случаев слияния аннотированного (и, возможно, подписанного) тега, который не хранится на своем естественном месте в иерархии ссылок/тегов/, и в этом случае предполагается --no-ff. р>
С --ff , когда это возможно, разрешайте слияние как перемотку вперед (только обновите указатель ветки, чтобы он соответствовал объединенной ветке; не создавайте фиксацию слияния). Если это невозможно (когда объединенная история не является потомком текущей истории), создайте фиксацию слияния.
С помощью --no-ff создайте фиксацию слияния во всех случаях, даже если вместо этого слияние может быть разрешено как ускоренная перемотка вперед.
GPG-подписать результирующий коммит слияния. Аргумент keyid является необязательным и по умолчанию соответствует идентификатору коммиттера; если он указан, он должен быть прикреплен к опции без пробела. --no-gpg-sign полезен для отмены как переменной конфигурации commit.gpgSign, так и ранее --gpg-sign .
Помимо имен веток, заполните сообщение журнала однострочными описаниями не более чем фактических коммитов, которые объединяются. См. также git-fmt-merge-msg[1]. Полезно только при слиянии.
С параметром --no-log не перечисляйте однострочные описания фактически объединяемых коммитов.
Опция --no-signoff может использоваться для отмены предыдущей опции --signoff в командной строке.
Показать diffstat в конце слияния. Диффстат также управляется параметром конфигурации merge.stat.
С параметром -n или --no-stat не показывать diffstat в конце слияния.
Создайте рабочее дерево и состояние индекса так, как если бы произошло реальное слияние (за исключением информации о слиянии), но на самом деле не делайте фиксацию, не перемещайте HEAD и не записывайте $GIT_DIR/MERGE_HEAD (чтобы вызвать следующую команду git commit для создания коммита слияния). Это позволяет вам создать один коммит поверх текущей ветки, эффект которого будет таким же, как слияние другой ветки (или больше, в случае осьминога).
С помощью --no-squash выполните слияние и зафиксируйте результат. Эту опцию можно использовать для переопределения --squash.
С --squash, --commit не разрешен и завершится ошибкой.
Полезно только при слиянии.
По умолчанию запускаются обработчики pre-merge и commit-msg. Когда задан --no-verify, они игнорируются. См. также гитхуки[5]. Полезно только при слиянии.
Использовать указанную стратегию слияния; могут быть предоставлены более одного раза, чтобы указать их в том порядке, в котором они должны быть опробованы. Если опция -s отсутствует, вместо нее используется встроенный список стратегий ( ort при слиянии одной головы, octopus в противном случае).
Передать конкретный параметр стратегии слияния в стратегию слияния.
Убедитесь, что фиксация наконечника объединяемой боковой ветки подписана действительным ключом, т. е.ключ с действительным идентификатором пользователя: в модели доверия по умолчанию это означает, что ключ подписи был подписан доверенным ключом. Если фиксация наконечника боковой ветви не подписана действительным ключом, слияние прерывается.
Полезно только при слиянии.
Синонимы --stat и --no-stat; они устарели и будут удалены в будущем.
По умолчанию команда git merge отказывается объединять истории, не имеющие общего предка. Эту опцию можно использовать для обхода этой безопасности при объединении историй двух проектов, которые начали свою жизнь независимо друг от друга. Поскольку это очень редкий случай, не существует переменной конфигурации, позволяющей включить это по умолчанию, и она не будет добавлена.
Полезно только при слиянии.
Если установлено значение true, после извлечения текущая ветвь перебазируется поверх восходящей ветки. Если есть ветвь удаленного отслеживания, соответствующая вышестоящей ветке, и вышестоящая ветвь была перебазирована с момента последней выборки, перебазирование использует эту информацию, чтобы избежать перебазирования нелокальных изменений.
Если установлено значение merges , выполните перебазирование с помощью git rebase --rebase-merges, чтобы локальные коммиты слияния были включены в перебазирование (подробности см. в git-rebase[1]).
При значении false объединить восходящую ветвь с текущей ветвью.
В интерактивном режиме включить интерактивный режим перебазирования.
См. ветку pull.rebase . .rebase и branch.autoSetupRebase в git-config[1], если вы хотите, чтобы git pull всегда использовал --rebase вместо слияния.
Это сокращение от --rebase=false.
Параметры, связанные с получением
Получить все пульты.
Добавить имена ссылок и имена объектов извлеченных ссылок к существующему содержимому .git/FETCH_HEAD . Без этой опции старые данные в .git/FETCH_HEAD будут перезаписаны.
Используйте атомарную транзакцию для обновления локальных ссылок. Либо обновляются все ссылки, либо в случае ошибки ссылки не обновляются.
Ограничьте выборку указанным количеством коммитов из верхушки истории каждой удаленной ветки. При выборке в репозиторий shallow, созданный git clone с параметром --depth= (см. git-clone[1]), увеличьте или сократите историю до указанного количества коммитов. Теги для углубленных коммитов не извлекаются.
Аналогичен параметру --depth, за исключением того, что он указывает количество коммитов от текущей неглубокой границы, а не от вершины истории каждой удаленной ветки.
Углубить или сократить историю неглубокого репозитория, чтобы включить все доступные коммиты после .
Углубить или сократить историю неглубокого репозитория, чтобы исключить коммиты, доступные из указанной удаленной ветки или тега. Этот параметр можно указать несколько раз.
Если исходный репозиторий завершен, преобразуйте неглубокий репозиторий в полный, сняв все ограничения, накладываемые неглубокими репозиториями.
Если исходный репозиторий неглубокий, извлеките как можно больше, чтобы текущий репозиторий имел ту же историю, что и исходный репозиторий.
По умолчанию при выборке из мелкого репозитория git fetch отклоняет ссылки, требующие обновления .git/shallow. Эта опция обновляет .git/shallow и принимает такие ссылки.
По умолчанию Git будет сообщать серверу о коммитах, доступных из всех локальных ссылок, чтобы найти общие коммиты и попытаться уменьшить размер получаемого пакетного файла. Если указано, Git будет сообщать только о коммитах, доступных из данных советов. Это полезно для ускорения выборки, когда пользователь знает, какая локальная ссылка, скорее всего, имеет общие фиксации с извлекаемой исходной ссылкой.
Эта опция может быть указана более одного раза; если это так, Git сообщит о коммитах, доступных из любого из заданных коммитов.
Аргументом этой опции может быть подстановка имен ссылок, ссылка или (возможно, сокращенный) SHA-1 фиксации. Указание глобуса эквивалентно указанию этого параметра несколько раз, по одному для каждого совпадающего имени ссылки.
См. также переменные конфигурации fetch.negotiationAlgorithm и push.negotiate, описанные в git-config[1], и параметр --negotiate-only ниже.
Не получать ничего с сервера, а вместо этого вывести предков предоставленных --negotiation-tip=* аргументов, которые у нас общие с сервером.
Внутренне это используется для реализации параметра push.negotiate, см. git-config[1].
Покажите, что будет сделано без внесения каких-либо изменений.
Когда git fetch используется с : refspec, он может отказаться обновлять локальную ветку, как описано в части документации git-fetch[1]. Этот параметр переопределяет эту проверку.
Сохранить загруженный пакет.
Измените настроенную спецификацию ссылок, чтобы поместить все ссылки в пространство имен refs/prefetch/. См. задачу предварительной выборки в git-maintenance[1].
Перед извлечением удалите все ссылки на удаленное отслеживание, которые больше не существуют на удаленном сервере. Теги не подлежат сокращению, если они извлекаются только из-за автоматического следования тегов по умолчанию или из-за опции --tags.Однако, если теги извлекаются из-за явного указания refspec (либо в командной строке, либо в удаленной конфигурации, например, если удаленный сервер был клонирован с опцией --mirror), они также подлежат сокращению. Предоставление --prune-tags является сокращением для предоставления тега refspec.
По умолчанию теги, указывающие на объекты, загруженные из удаленного репозитория, извлекаются и сохраняются локально. Этот параметр отключает автоматическое отслеживание тегов. Поведение по умолчанию для пульта дистанционного управления может быть указано с помощью пульта дистанционного управления. Настройка .tagOpt. См. git-config[1].
При извлечении ссылок, перечисленных в командной строке, используйте указанную спецификацию ссылок (можно указать более одного раза), чтобы сопоставить ссылки с ветвями удаленного отслеживания вместо значений переменных конфигурации remote.*.fetch для удаленного репозитория. . Предоставление пустого параметра --refmap заставляет Git игнорировать настроенные спецификации ссылок и полностью полагаться на спецификации ссылок, предоставленные в качестве аргументов командной строки. Дополнительные сведения см. в разделе «Настроенные ветки удаленного отслеживания».
Выбрать все теги с удаленного устройства (т. е. преобразовать удаленные теги refs/tags/* в локальные теги с тем же именем) в дополнение к тому, что в противном случае было бы получено. Использование только этой опции не подвергает теги сокращению, даже если используется --prune (хотя теги могут быть удалены в любом случае, если они также являются целью явной спецификации ссылки; см. --prune ).
Количество параллельных дочерних элементов, которые будут использоваться для всех форм выборки.
Если был указан параметр --multiple, разные удаленные устройства будут загружаться параллельно. Если выбрано несколько подмодулей, они будут загружаться параллельно. Чтобы управлять ими независимо, используйте настройки конфигурации fetch.parallel и submodule.fetchJobs (см. git-config[1]).
Как правило, параллельная рекурсивная и мультиудаленная выборка выполняется быстрее. По умолчанию выборки выполняются последовательно, а не параллельно.
Если удаленный объект получен успешно, добавьте восходящую (отслеживающую) ссылку, используемую безаргументной git-pull[1] и другими командами. Для получения дополнительной информации см. ветку. .слияние и ветвление. .remote в git-config[1].
Если указано, а репозиторий для извлечения обрабатывается git fetch-pack, --exec= передается команде, чтобы указать путь не по умолчанию для команды, выполняемой на другом конце. .
Состояние выполнения сообщается в стандартном потоке ошибок по умолчанию, когда он подключен к терминалу, если не указан параметр -q. Этот флаг принудительно устанавливает состояние выполнения, даже если стандартный поток ошибок не направлен на терминал.
Передать данную строку на сервер при обмене данными по протоколу версии 2. Данная строка не должна содержать символы NUL или LF. Обработка сервером параметров сервера, включая неизвестные, зависит от сервера. Если задано несколько параметров --server-option=, все они отправляются другой стороне в порядке, указанном в командной строке.
По умолчанию 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 ниже), либо именем удаленного устройства (см. раздел ПУЛЬТЫ ниже).
Указывает, какие ссылки нужно получить и какие локальные ссылки обновить. Когда в командной строке нет s, ссылки для извлечения считываются с удаленного компьютера. вместо этого переменные .fetch (см. раздел «НАСТРОЙКИ УДАЛЕННОГО ОТСЛЕЖИВАНИЯ ВЕТВЕЙ» в git-fetch[1]).
Формат параметра: необязательный плюс + , за которым следует источник , за которым следует двоеточие : , за которым следует конечная ссылка . Двоеточие можно опустить, если оно пусто. обычно это ссылка, но это также может быть полное шестнадцатеричное имя объекта.
A может содержать *, чтобы указать простое совпадение с образцом. Такая refspec функционирует как glob, который соответствует любой ссылке с таким же префиксом. Шаблон должен иметь * как в , так и в . Он сопоставит ссылки с местом назначения, заменив * на содержимое, соответствующее источнику.
Если спецификация ссылки начинается с префикса ^ , она будет интерпретироваться как отрицательная спецификация ссылки. Вместо того, чтобы указывать, какие ссылки извлекать или какие локальные ссылки обновлять, такая спецификация ссылок вместо этого указывает ссылки, которые необходимо исключить. Ссылка будет считаться соответствующей, если она соответствует хотя бы одной положительной спецификации ссылки и не соответствует ни одной отрицательной спецификации ссылки.Отрицательные спецификации ссылок могут быть полезны для ограничения объема спецификации ссылок шаблона, чтобы она не включала определенные ссылки. Отрицательные спецификации ссылок сами по себе могут быть спецификациями ссылок шаблонов. Однако они могут содержать только и не указывать . Полные шестнадцатеричные имена объектов также не поддерживаются.
тег означает то же, что и refs/tags/ :refs/tags/ ; он запрашивает выборку всего до данного тега.
Выбирается совпадающая удаленная ссылка, и если это не пустая строка, предпринимается попытка обновить совпадающую с ней локальную ссылку.
Разрешено ли это обновление без --force, зависит от пространства имен ref, в которое оно извлекается, типа извлекаемого объекта и от того, считается ли обновление ускоренной перемоткой вперед. Как правило, для выборки применяются те же правила, что и для отправки, см. раздел git-push[1] для того, что это такое. Исключения из этих правил, относящихся к git fetch, указаны ниже.
До Git версии 2.20, в отличие от отправки с помощью git-push[1], любые обновления refs/tags/* принимались без + в refspec (или --force ). При извлечении мы беспорядочно считали все обновления тегов с удаленного устройства принудительными. Начиная с Git версии 2.20, выборка для обновления refs/tags/* работает так же, как и при отправке. т.е. любые обновления будут отклонены без + в refspec (или --force ).
В отличие от отправки с помощью git-push[1], любые обновления за пределами refs//* будут приниматься без + в refspec (или --force ), будь то подкачка, например. объект дерева для большого двоичного объекта или коммит для другого коммита, у которого нет предыдущего коммита в качестве предка и т. д.
В отличие от отправки с помощью git-push[1], здесь нет конфигурации, которая изменит эти правила, и нет ничего похожего на обработчик предварительной выборки, аналогичный обработчику предварительного получения.
Как и в случае отправки с помощью git-push[1], все описанные выше правила о том, что не разрешено в качестве обновления, можно переопределить, добавив необязательный начальный + к refspec (или используя параметр командной строки --force). . Единственным исключением из этого правила является то, что никакие принудительные меры не заставят пространство имен refs/heads/* принять незафиксированный объект.
Читайте также: