Git push не отправляет файлы
Обновлено: 21.11.2024
Поделиться изменениями, внесенными в коммиты и ветки, с помощью команды push. Отправляйте свои ветки в удаленный репозиторий. Git добавляет ваши коммиты в существующую удаленную ветку или создает новую ветку с теми же коммитами, что и ваша локальная ветка.
Git гарантирует, что отправленные изменения согласуются с удаленной ветвью. Другие могут получить ваши коммиты и объединить их в свою локальную копию ветки. Отправленные ветки, которые завершили работу, проверяются и объединяются с основной веткой вашего репозитория с помощью запроса на вытягивание.
В этом руководстве вы узнаете, как:
Поделитесь своим кодом с push
В Visual Studio 2019 версии 16.8 и более поздних версиях есть новое меню Git для управления рабочим процессом Git с меньшим переключением контекста, чем в Team Explorer. Процедуры, представленные в этой статье на вкладке Visual Studio 2019, предоставляют информацию об использовании возможностей Git, а также Team Explorer. Дополнительные сведения см. в разделе Сравнение Git и Team Explorer.
В Team Explorer выберите «Домой», а затем выберите «Синхронизировать», чтобы открыть синхронизацию.
Вы также можете перейти к Синхронизации из представления «Изменения», выбрав «Синхронизировать» сразу после фиксации.
Выберите «Отправить», чтобы отправить вашу фиксацию в удаленный репозиторий.
При первой отправке в репозиторий вы увидите следующее сообщение вместо списка исходящих коммитов: Текущая ветвь не отслеживает удаленную ветвь. Отправьте свои изменения в новую ветку на исходном удаленном сервере и установите восходящую ветку. Выберите «Отправить», чтобы отправить изменения в новую ветку в удаленном репозитории и установить восходящую ветку. В следующий раз, когда вы отправите изменения, вы увидите список коммитов.
Перейдите в Team Explorer > Настройки > Настройки репозитория. Убедитесь, что вы ввели правильные параметры пользователя, электронной почты, пультов и другие параметры.
Команда push обновляет удаленную ветку в источнике коммитами из вашей локальной ветки.
Когда вы запустите git push , вы увидите вывод, аналогичный следующему примеру:
Если удаленной ветки не существует, выполните следующую команду, чтобы создать удаленную ветку в источнике .
Команда добавляет ваши коммиты из вашей локальной ветки в исходную ветку. Эта команда устанавливает отношение отслеживания вышестоящего уровня в Git, чтобы в следующий раз при отправке или извлечении данных из этой локальной ветки вам не нужно было указывать имя удаленной ветки.
Разрешить конфликты слияния перед отправкой
Если между вашими локальными фиксациями и удаленной ветвью возникают конфликты, вы должны разрешить эти конфликты, прежде чем отправлять свои изменения. Сначала извлеките изменения из других. Вы можете разрешить конфликты и зафиксировать изменения, а затем повторить команду push.
Я вношу изменения в какой-то файл в своем локальном репозитории git, а затем хочу отправить изменения в удаленный репозиторий git, из которого был клонирован локальный файл, через ssh.
После запуска "git commit -a" на моей локальной стороне, чтобы отправить изменения на удаленный, я запускаю
Однако я проверил удаленные файлы, и они не изменились! Есть идеи?
С уважением и благодарностью!
16 ответов 16
Вы пробовали следующее?
Используйте git remote, чтобы узнать имена ваших пультов. Удаленным по умолчанию является origin , который автоматически создается при клонировании репозитория.
@CharlieParker, может быть, вы изменили конфигурацию push.default с текущей на простую? simple — это значение по умолчанию, начиная с Git 2.0. До Git 2.0 сопоставление использовалось по умолчанию.
@knittl Я получил эту ошибку. фатальный: «источник» не является репозиторием git фатальный: не удалось прочитать из удаленного репозитория. Убедитесь, что у вас есть правильные права доступа и репозиторий существует.
@vishal Я не понимаю ваш последний комментарий, и он не отвечает на мой вопрос. Что показывает git remote или git remote -v? Содержит ли он строку происхождения? Если нет, то какие пульты у вас настроены (т.е. показаны командой)?
Я обнаружил, что проблема заключалась в том, что я не добавил файлы в обновление, а также сообщение. Я исправил это с помощью следующих команд:
Надеюсь, это кому-нибудь поможет ;)
Возможно, вы вставили в не голый репозиторий, то есть в репозиторий, к которому прикреплена рабочая копия. Вы не должны были игнорировать предупреждение, которое git push выдает, если заметит, что это так.
В любом случае войдите на удаленную машину, перейдите в репозиторий и сделайте
Вот так. В следующий раз пушить только в голые репозитории. :)
Мне удалось решить эту проблему, как вы сказали, но я все еще в замешательстве и не понимаю, что делаю. Означает ли не-голый, что я могу редактировать файлы в репозитории напрямую, а голый означает, что файлы в репозитории не позволяют редактировать? Какое предупреждение выдает git push, которого я не заметил? Спасибо!
«Голый» репозиторий — это репозиторий, у которого нет рабочей копии, т.е. в нем нельзя редактировать никакие файлы. Путь к репозиторию напрямую содержит все, что обычно находится в папке .git не голого репозитория, а по сути голый репозиторий — это только эта папка. При отправке в не голый репозиторий вы не изменяете файлы, которые в настоящее время извлечены. Вам необходимо обновить рабочий код отдельно, например. с помощью git checkout или git reset .
Просто не отправляйте данные в репозиторий, к которому прикреплено рабочее дерево. Предупреждение есть не просто так! Если вы не понимаете, к каким последствиям может привести отправка в нечистый репозиторий, тогда не делайте этого. Не ищите обходных путей, а вместо этого используйте разумную структуру: отправляйте в голый репозиторий где-нибудь в другом месте. а затем вытащите из пункта назначения.
У меня была та же проблема, и это было из-за того, что я выписался до точки в истории (в данном случае тега), а не до конца (головы) какой-либо ветки или мастера. Я внесу изменения и зафиксирую их, и я увижу изменения в своей локальной истории. Когда я запустил git push, git заявил, что все в порядке, но изменение на самом деле не было отправлено на сервер (что можно увидеть, проверив журналы или повторно клонировав репо и проверив его журналы). Лучшим признаком этой ошибки является сообщение "Голова отсоединена от ____"
Решение
Что действительно нужно сделать (если вы сделали то, что сделал я), так это создать новую линию разработки, создав ветку и переключившись на эту ветку до внесения изменений. р>
Затем, после фиксации изменений, если вы хотите, чтобы изменения были отправлены на сервер, вам нужно отправить саму ветку на сервер.
Теперь, если вы клонируете репозиторий, вы должны увидеть свои изменения в журналах. Однако в следующий раз, когда вы клонируете репозиторий, чтобы иметь возможность перейти к той точке, которую вы только что изменили, вам нужно будет проверить эту ветку, так как по умолчанию вы будете находиться на основной линии, которая находится «дальше» вниз по линии разработки, откуда вы разветвились.
После того как вы добавили новые файлы в репозиторий Git или изменили файлы, которые уже находятся под контролем версий Git, и вы довольны их текущим состоянием, вы можете поделиться результатами своей работы. Это включает их локальную фиксацию для записи моментального снимка вашего репозитория в историю проекта, а затем отправку их в удаленный репозиторий, чтобы они стали доступными для других.
Задайте свое имя пользователя Git
Git должен знать ваше имя пользователя, чтобы связать коммиты с личностью. Если вы не задали свое имя пользователя, JetBrains Rider предложит вам указать его при первой попытке зафиксировать изменения.
Откройте Терминал и выполните одну из следующих команд:
Чтобы задать имя для каждого репозитория Git на вашем компьютере, используйте $ git config --global user.name "John Smith"
Чтобы задать имя для одного репозитория, используйте $ git config user.name "John Smith"
Локальная фиксация изменений
Откройте вертикальное окно инструмента фиксации, расположенное слева:
Когда ваши изменения будут готовы к фиксации, выберите соответствующие файлы или весь список изменений.
Если вы нажмете Ctrl+K , будет выбран весь активный список изменений.
Вы также можете выбрать файлы в узле Unversioned Files — JetBrains Rider создаст и зафиксирует эти файлы за один шаг.
Если вы хотите добавить локальные изменения к последней фиксации вместо создания отдельной фиксации, выберите параметр «Изменить».
Введите сообщение фиксации. Вы можете щелкнуть, чтобы выбрать из списка последних сообщений о фиксации.
Вы также можете отредактировать сообщение фиксации позже, до того, как вы отправите фиксацию.
Вы можете настроить правила сообщения о фиксации на странице Управление версиями | Страница фиксации настроек IDE Ctrl+Alt+S . Существует также быстрое исправление и действие «Переформатировать», которое переносит длинную строку или переформатирует сообщение.
Вы также можете определить шаблон фиксации, который будет использоваться в качестве сообщения фиксации по умолчанию. Укажите шаблонный текст, который вы хотите использовать в файле .txt, и выполните следующую команду в терминале, чтобы добавить его в конфигурацию Git: git config --local commit.template
Если вам необходимо выполнить проверки перед фиксацией, загрузить файлы на сервер после фиксации или выполнить фиксацию с дополнительными параметрами, нажмите :
Доступны следующие параметры:
Автор: если вы фиксируете изменения, сделанные другим человеком, вы можете указать автора этих изменений.
Подтвердить фиксацию: выберите, хотите ли вы подписать свою фиксацию, чтобы подтвердить, что изменения, которые вы собираетесь зарегистрировать, были сделаны вами или что вы берете на себя ответственность за код, который вы фиксируете.
Если этот параметр включен, в конце сообщения о фиксации автоматически добавляется следующая строка: Подписано:
В области «Перед фиксацией» выберите действия, которые должен выполнить JetBrains Rider перед фиксацией выбранных файлов в локальном репозитории.
Доступны следующие параметры:
Переформатировать код: выполнить форматирование кода в соответствии с правилами форматирования кода.
Изменить код . Измените порядок кода в соответствии с настройками макета файла и типа.
Оптимизируйте импорт: удалите лишние операторы импорта.
Проверить TODO ( ): просмотр элементов TODO, соответствующих указанному фильтру. Нажмите «Настроить», чтобы выбрать существующий фильтр TODO, или откройте страницу настроек TODO и определите новый применяемый фильтр.
Очистка: пакетное применение быстрых исправлений из проверок очистки кода. Щелкните Выбрать профиль, чтобы выбрать профиль, из которого среда IDE будет выполнять проверки.
Когда будете готовы, нажмите «Зафиксировать» или «Зафиксировать и отправить» ( Ctrl+Alt+K ), чтобы отправить изменения в удаленный репозиторий сразу после фиксации. Вы сможете просмотреть текущую фиксацию, а также все другие фиксации, прежде чем они будут отправлены на удаленный сервер.
Зафиксировать часть файла
Иногда, когда вы вносите изменения, относящиеся к конкретной задаче, вы также применяете другие несвязанные модификации кода, влияющие на тот же файл. Включение всех таких изменений в одну фиксацию может быть не лучшим вариантом, так как их будет сложнее просмотреть, отменить, отобрать и т. д.
JetBrains Rider позволяет зафиксировать такие изменения отдельно одним из следующих способов:
выберите измененные фрагменты кода, которые вы хотите включить в фиксацию, прямо в диалоговом окне «Зафиксировать изменения» и оставьте другие изменения отложенными, чтобы вы могли зафиксировать их позже.
помещайте разные фрагменты кода в разные списки изменений на лету, когда вы редактируете код, а затем фиксируйте эти списки изменений отдельно.
Вы также можете создать новый список изменений и сделать его активным, тогда все изменения, которые вы сделаете после этого, попадут в этот список изменений, а все изменения, которые вы сделали до этого, останутся там, где они есть.
Выберите фрагменты, которые хотите зафиксировать
Откройте вертикальное окно инструмента фиксации.
Чтобы отобразить различия между версией репозитория и локальной версией выбранного файла, в окне инструмента фиксации щелкните на панели инструментов или нажмите Ctrl+D .
Установите флажки рядом с каждым фрагментом измененного или вновь добавленного кода, который вы хотите зафиксировать, и оставьте остальные изменения невыбранными:
Вы также можете выбрать «Переместить в другой список изменений…» в контекстном меню измененного фрагмента, чтобы разделить изменения между разными списками изменений, которые вы можете зафиксировать отдельно.
Чтобы назначить собственное сочетание клавиш для этого действия, найдите действие «Переместить строки в другой список изменений…» в разделе «Системы управления версиями» на странице «Раскладка клавиш» в настройках IDE Ctrl+Alt+S .
Нажмите "Подтвердить" . Невыбранные изменения останутся в текущем списке изменений, чтобы вы могли зафиксировать их отдельно.
Поместить изменения в разные списки изменений
Когда вы вносите изменения в файл в редакторе, щелкните соответствующий маркер изменения в поле.
Если в разделе «Редактор» нет маркеров изменений, убедитесь, что параметр «Выделять измененные строки в разделе» включен в меню «Редактор | Общая страница настроек IDE Ctrl+Alt+S .
На появившейся панели инструментов выберите целевой список изменений для измененного фрагмента кода (или создайте новый список изменений):
Зафиксируйте каждый список изменений отдельно.
Использование тестовой области Git для фиксации изменений
Если вы больше привыкли к концепции промежуточного хранения изменений для фиксации вместо использования списков изменений, в которых измененные файлы размещаются автоматически, выберите параметр «Включить промежуточную область» в разделе «Управление версиями | Git-страница настроек IDE Ctrl+Alt+S .
Использование области подготовки позволяет легко фиксировать изменения в одном и том же файле по отдельности (включая перекрывающиеся изменения) и видеть, какие изменения уже подготовлены, не переключая фокус с редактора.
При переходе от использования списков изменений к тестовой области Git все существующие списки изменений будут удалены, поэтому убедитесь, что вы зафиксировали или отложили их, чтобы предотвратить потерю данных.
Изменения этапа для фиксации
Выполните одно из следующих действий:
Чтобы подготовить файл целиком, в окне инструмента фиксации выберите этот файл и щелкните справа рядом с ним или нажмите Ctrl+Alt+A .
Чтобы подготовить определенный фрагмент внутри файла, в редакторе щелкните маркер изменения в поле рядом с измененным фрагментом и нажмите "Стандарт" .
Поэтапные изменения (включая изменения, внесенные вне JetBrains Rider) помечаются маркером изменения в форме рамки в редакторе:
Чтобы внести детальные изменения, такие как одна строка вместо фрагмента кода, или даже одно из нескольких изменений в одну строку, в окне инструмента «Зафиксировать» выберите файл, содержащий изменение, и выберите «Сравнить HEAD, поэтапное и локальное». Версии из контекстного меню.
Откроется трехстороннее средство просмотра различий, в котором на левой панели отображается версия репозитория, на правой панели — локальная версия, а на центральной панели — полнофункциональный редактор, в котором вы можете вносить изменения, которые хотите применить.
Когда будете готовы, зафиксируйте изменения, как описано в разделе Локальная фиксация изменений.
Отправить изменения в удаленный репозиторий
Прежде чем отправлять изменения, синхронизируйте их с удаленным и убедитесь, что ваша локальная копия репозитория обновлена, чтобы избежать конфликтов.
JetBrains Rider позволяет загружать изменения из любой ветки в отслеживаемую ветку или в любую другую удаленную ветку.
Выполните одно из следующих действий:
Чтобы отправить изменения из текущей ветки, нажмите Ctrl+Shift+K или выберите Git | Нажмите из главного меню.
Чтобы отправить изменения из любой локальной ветви, имеющей удаленную, выберите эту ветвь во всплывающем окне "Ветви" и выберите "Отправить" из списка действий.
Открывается диалоговое окно Push Commits, в котором отображаются все репозитории Git (для проектов с несколькими репозиториями) и список всех коммитов, сделанных в текущей ветке в каждом репозитории с момента последней отправки.
Если у вас есть проект, использующий несколько репозиториев, которые не управляются синхронно, по умолчанию выбирается только текущий репозиторий (подробные сведения о том, как включить синхронное управление репозиториями, см. в разделе Настройки управления версиями: Git).
Вы можете нажать Ctrl+Q для выбранного коммита, чтобы отобразить дополнительную информацию, такую как автор коммита, время, хэш и сообщение коммита.
Если в репозитории нет пультов, появится ссылка Определить удаленный. Щелкните эту ссылку и укажите удаленное имя и URL-адрес в открывшемся диалоговом окне. Он будет сохранен, и вы сможете отредактировать его позже через Git | Управление удаленными репозиториями (подробности см. в разделе Добавление удаленного репозитория).
Если вы хотите изменить целевую ветку, в которую вы хотите нажать, вы можете щелкнуть имя ветки. Метка превращается в текстовое поле, в котором вы можете ввести название существующей ветки или создать новую ветку. Вы также можете щелкнуть ссылку «Изменить все цели» в правом нижнем углу, чтобы изменить имена всех ветвей одновременно.
Обратите внимание, что вы не можете изменить локальную ветвь: текущая ветвь для каждого выбранного репозитория будет отправлена.
Вы также можете переключиться в режим редактирования, нажав Enter или F2 для выбранного элемента.
Если у вас есть коммиты, которые вы сделали, но пока не хотите отправлять в удаленную ветку, на вкладке «Журнал» окна инструмента Git выберите последний коммит, который вы хотите отправить, и выберите параметр «Отправить все сюда…» из список действий.
Открывается диалоговое окно Push Commits, в котором отображаются все фиксации до выбранного хэша фиксации.
Если вы хотите предварительно просмотреть изменения перед их отправкой, выберите нужную фиксацию. Правая панель показывает изменения, включенные в выбранную фиксацию. Вы можете использовать кнопки на панели инструментов для просмотра сведений о коммите.
Если автор фиксации отличается от текущего пользователя, эта фиксация помечается звездочкой.
Если вы выберете весь репозиторий, все файлы из всех коммитов будут перечислены на правой панели.
Если один и тот же файл был изменен в течение нескольких коммитов, он будет указан только один раз, если вы выберете эти коммиты или весь репозиторий, и если вы вызовете средство просмотра различий для этого файла, все изменения будут заархивированы вместе.
Нажмите кнопку Push, когда будете готовы, и выберите операцию, которую вы хотите выполнить, в раскрывающемся меню: Push или Force push (эквивалентно push --force-with-lease ).
Эти варианты выбора доступны только в том случае, если текущая ветвь не указана в поле Защищенные ветки (см. Настройки управления версиями: Git), в противном случае вы можете выполнить только операцию отправки.
Обновите рабочую копию, если отправка отклонена
Если отправка отклонена из-за того, что ваша рабочая копия устарела, JetBrains Rider отображает диалоговое окно «Отклонена отправка» при условии, что параметр «Автообновление, если отправка текущей ветки была отклонена» на странице настроек Git диалогового окна «Настройки/Настройки» не установлен. выбрано. Сделайте следующее:
Если в вашем проекте используется несколько репозиториев Git, укажите, какой из них вы хотите обновить. Если вы хотите обновить все репозитории, независимо от того, был ли для них отклонен push или нет, выберите опцию Обновить все репозитории.Если этот флажок снят, будут обновлены только затронутые репозитории.
Если вы хотите, чтобы JetBrains Rider автоматически применяла процедуру обновления при следующем отклонении push-уведомления с использованием метода обновления, выбранного в этом диалоговом окне, выберите параметр Запомнить выбор метода обновления и автоматически обновлять в будущем.
После того, как вы покинете это диалоговое окно, будет установлен флажок Автообновление, если отправка текущей ветки была отклонена на странице настроек Git диалогового окна Настройки/Настройки, а примененный метод обновления станет методом по умолчанию.
Чтобы изменить стратегию обновления, снимите этот флажок, чтобы вызвать диалоговое окно "Отклонение отправки" в следующий раз, когда будет отклонена отправка текущей ветки, примените другую процедуру обновления и еще раз выберите параметр "Запомнить выбор метода обновления".
Выберите метод обновления (перебазировать или объединить), нажав кнопку "Перебазировать" или "Объединить" соответственно.
Когда мне нужно использовать принудительное нажатие?
Когда вы запускаете push , Git откажется выполнять операцию, если в удаленном репозитории есть изменения, которые вам не хватает и которые вы собираетесь перезаписать локальной копией репозитория. Обычно вам нужно выполнить pull для синхронизации с удаленным, прежде чем вы обновите его своими изменениями.
Команда --force push отключает эту проверку и позволяет вам перезаписать удаленный репозиторий, тем самым стирая его историю и вызывая потерю данных. Под капотом, когда вы выбираете принудительную отправку, JetBrains Rider выполняет операцию push --force-with-lease, которая является более безопасным вариантом, помогающим вам гарантировать, что вы не перезаписываете чужие коммиты (см. git push для получения дополнительной информации о принудительной отправке). варианты).
Возможная ситуация, когда вам все еще может понадобиться выполнить --force push, — это когда вы перемещаете отправленную ветку, а затем хотите отправить ее на удаленный сервер. В этом случае, когда вы попытаетесь отправить изменения, Git отклонит ваши изменения, потому что удаленная ссылка не является предком локальной ссылки. Если вы выполните pull в этой ситуации, вы получите две копии ветки, которые затем нужно будет объединить.
Обновляет удаленные ссылки, используя локальные ссылки, при этом отправляя объекты, необходимые для завершения заданных ссылок.
Вы можете заставить репозиторий происходить с репозиторием каждый раз, когда вы добавляете в него данные, устанавливая там перехватчики. См. документацию для git-receive-pack[1].
Если в командной строке не указано, куда вставлять данные с аргументом, используется конфигурация branch.*.remote для текущей ветки, чтобы определить, куда вставлять данные. Если конфигурация отсутствует, по умолчанию используется origin.
Если в командной строке не указано, что нужно нажать . arguments или --all , --mirror , --tags , команда находит значение по умолчанию, сверяясь с конфигурацией remote.*.push, и, если оно не найдено, учитывает конфигурацию push.default, чтобы решить, что отправлять (см. git- config[1] для значения push.default ).
Если ни в командной строке, ни в конфигурации не указано, что отправлять, используется поведение по умолчанию, которое соответствует простому значению для push.default : текущая ветвь помещается в соответствующую восходящую ветвь, но в качестве меры безопасности. , отправка прерывается, если имя вышестоящей ветки не совпадает с именем локальной.
ВАРИАНТЫ
Удаленный репозиторий, который является местом назначения операции отправки. Этот параметр может быть либо URL-адресом (см. раздел URL-адреса GIT ниже), либо именем удаленного устройства (см. раздел ПУЛЬТЫ ниже).
Укажите, какую ссылку назначения следует обновить с помощью исходного объекта. Формат параметра: необязательный плюс + , за которым следует исходный объект , за которым следует двоеточие : , за которым следует конечная ссылка .
Часто это имя ветки, которую вы хотите отправить, но это может быть любое произвольное "выражение SHA-1", например master~4 или HEAD (см. gitrevisions[7]).
Сообщает, какая ссылка на удаленной стороне обновляется с помощью этого нажатия. Здесь нельзя использовать произвольные выражения, должна быть указана фактическая ссылка. Если git push [ ] без каких-либо аргументов настроен на обновление некоторой ссылки в пункте назначения с помощью удаленного. Переменная конфигурации .push, часть : может быть опущена — такая отправка обновит ссылку, которая обычно обновляется без какой-либо командной строки. В противном случае отсутствие : означает обновление той же ссылки, что и .
Если не начинается с refs/ (например, refs/heads/master ), мы попытаемся сделать вывод, где в refs/* в пункте назначения он находится, основываясь на типе отправки и неоднозначности.
Если недвусмысленно ссылается на ссылку на удаленном компьютере, нажмите на эту ссылку.
Если разрешается в ссылку, начинающуюся с refs/heads/ или refs/tags/, добавьте ее перед .
В будущем могут быть добавлены другие разрешения неоднозначности, но сейчас любые другие случаи будут выдавать ошибку, указывающую, что мы пытались, и в зависимости от конфигурации совета.pushUnqualifiedRefname (см. / пространство имен, которое вы, возможно, хотели отправить.
Объект, на который ссылается, используется для обновления ссылки на удаленной стороне. Разрешено ли это, зависит от того, где в refs/* находится ссылка, как подробно описано ниже, в этих разделах «обновление» означает любые модификации, кроме удаления, которые, как указано после следующих нескольких разделов, обрабатываются по-разному.
Пространство имен refs/heads/* будет принимать только объекты фиксации и обновлять только в том случае, если их можно перемотать вперед.
Пространство имен refs/tags/* будет принимать объекты любого типа (в качестве коммитов можно пометить деревья и большие двоичные объекты), и любые их обновления будут отклонены.
Можно поместить объект любого типа в любое пространство имен за пределами refs//* . В случае с тегами и фиксациями они будут рассматриваться так, как если бы они были фиксациями внутри refs/heads/* для целей разрешения обновления.
Т.е. ускоренная перемотка коммитов и тегов за пределами refs//* разрешена, даже в тех случаях, когда то, что перебрасывается вперед, является не фиксацией, а объектом тега, который указывает на новую фиксацию, которая является ускоренной перемоткой зафиксируйте последний тег (или зафиксируйте), который он заменяет. Замена тега совершенно другим тегом также разрешена, если он указывает на тот же коммит, а также добавление удаленного тега, т.е. нажатие коммита, на который указывает существующий объект тега, или новый объект тега, на который указывает существующий коммит. .
Объекты деревьев и больших двоичных объектов за пределами refs//* будут обрабатываться так же, как если бы они находились внутри refs/tags/* , любое их обновление будет отклонено.
Все описанные выше правила, касающиеся того, что не разрешено в качестве обновления, можно переопределить, добавив необязательный начальный + к refspec (или используя параметр командной строки --force). Единственным исключением из этого является то, что никакие принудительные меры не заставят пространство имен refs/heads/* принять незафиксированный объект. Хуки и конфигурация также могут переопределять или изменять эти правила, см., например. receive.denyNonFastForwards в git-config[1] и pre-receive and update в githooks[5].
Нажатие пустого позволяет удалить ссылку из удаленного репозитория. Удаление всегда принимается без начального + в refspec (или --force ), за исключением случаев, когда это запрещено конфигурацией или ловушками. См. Receive.denyDeletes в git-config[1] и предварительное получение и обновление в githooks[5].
Специальная спецификация refspec : (или +: для разрешения обновлений без перемотки вперед) указывает Git на отправку «совпадающих» веток: для каждой ветки, которая существует на локальной стороне, удаленная сторона обновляется, если ветвь того же имя уже существует на удаленной стороне.
тег означает то же, что и refs/tags/ :refs/tags/ .
Отправить все ветки (например, refs в refs/heads/ ); нельзя использовать с другими .
Удалите удаленные ветки, у которых нет локального аналога. Например, удаленная ветка tmp будет удалена, если локальная ветка с таким именем больше не существует. Это также относится к refspecs, например. git push --prune remote refs/heads/*:refs/tmp/* гарантирует, что удаленные refs/tmp/foo будут удалены, если refs/heads/foo не существует.
Вместо того, чтобы называть каждую ссылку для отправки, указывает, что все ссылки в разделе refs/ (включая, помимо прочего, refs/heads/ , refs/remotes/ и refs/tags/ ) будут зеркалироваться в удаленный репозиторий. Вновь созданные локальные ссылки будут переданы на удаленный конец, локально обновленные ссылки будут принудительно обновлены на удаленном конце, а удаленные ссылки будут удалены с удаленного конца. Это значение по умолчанию, если опция конфигурации удалена. .зеркало установлено.
Делайте все, кроме фактической отправки обновлений.
Создать машиночитаемый вывод. Строка состояния вывода для каждой ссылки будет разделена табуляцией и отправлена на стандартный вывод вместо стандартного вывода. Будут даны полные символические имена ссылок.
Все перечисленные ссылки удаляются из удаленного репозитория. Это то же самое, что предварять все ссылки двоеточием.
Передаются все ссылки под ссылками/тегами, в дополнение к спецификациям ссылок, явно указанным в командной строке.
Отправлять все ссылки, которые были бы отправлены без этой опции, а также отправлять аннотированные теги в ссылках/тегах, которые отсутствуют на удаленном сервере, но указывают на фиксацию, достижимую из отправляемых ссылок. Это также можно указать с помощью переменной конфигурации push.followTags. Дополнительные сведения см. в разделе push.followTags в git-config[1].
GPG-подписать push-запрос на обновление ссылок на принимающей стороне, чтобы разрешить его проверку перехватчиками и/или ведение журнала. Если false или --no-signed , попытка подписи не предпринимается. Если задано значение true или --signed , отправка завершится ошибкой, если сервер не поддерживает подписанные отправки. Если установлено значение if-asked , подписывайте тогда и только тогда, когда сервер поддерживает подписанные push-уведомления. Нажатие также завершится ошибкой, если вызов gpg --sign завершится ошибкой. Подробную информацию о принимающей стороне см. в git-receive-pack[1].
Используйте атомарную транзакцию на удаленной стороне, если она доступна. Либо обновляются все ссылки, либо в случае ошибки ссылки не обновляются. Если сервер не поддерживает атомарную отправку, отправка завершится ошибкой.
Передать заданную строку на сервер, который передает ее на перехватчик предварительного и пост-получения. Данная строка не должна содержать символы NUL или LF. Когда задано несколько --push-option=, все они отправляются другой стороне в порядке, указанном в командной строке. Если в командной строке не указан параметр --push-option=, вместо него используются значения переменной конфигурации push.pushOption.
Путь к программе git-receive-pack на удаленном конце. Иногда полезно при отправке в удаленный репозиторий через ssh, когда у вас нет программы в каталоге по умолчанию $PATH.
--[no-]force-with-lease --force-with-lease= --force-with-lease= :
Обычно "git push" отказывается обновлять удаленную ссылку, которая не является предком локальной ссылки, используемой для ее перезаписи.
Этот параметр отменяет это ограничение, если текущее значение удаленной ссылки является ожидаемым. В противном случае "git push" не работает.
Представьте, что вам нужно перебазировать то, что вы уже опубликовали. Вам придется обойти правило «перемотать вперед», чтобы заменить историю, которую вы изначально опубликовали, на перебазированную историю. Если кто-то другой построил поверх вашей исходной истории, пока вы перемещаете базу, кончик ветки на удалении может продвинуться вперед с их фиксацией, и слепое нажатие --force потеряет свою работу.
Этот параметр позволяет сказать, что вы ожидаете, что обновляемая история — это то, что вы перебазировали и хотите заменить. Если удаленная ссылка по-прежнему указывает на указанную вами фиксацию, вы можете быть уверены, что другие люди ничего не сделали с этой ссылкой. Это похоже на аренду ссылки без явной блокировки, и удаленная ссылка обновляется только в том случае, если «аренда» все еще действительна.
--force-with-lease без указания деталей защитит все удаленные ссылки, которые будут обновлены, требуя, чтобы их текущее значение совпадало с веткой удаленного отслеживания, которая у нас есть для них.
--force-with-lease= , без указания ожидаемого значения, защитит именованную ссылку (отдельно), если она будет обновлена, требуя, чтобы ее текущее значение было таким же, как в ветке удаленного отслеживания у нас есть для этого.
--force-with-lease= : защитит именованную ссылку (отдельно), если она будет обновлена, требуя, чтобы ее текущее значение совпадало с указанным значением (которое может отличаться от ветвь удаленного отслеживания, которая у нас есть для refname, или нам даже не нужно иметь такую ветвь удаленного отслеживания, когда используется эта форма). Если это пустая строка, то именованная ссылка еще не должна существовать.
Обратите внимание, что все формы, кроме --force-with-lease= : которые явно указывают ожидаемое текущее значение ссылки, все еще являются экспериментальными, и их семантика может измениться по мере того, как мы приобретаем опыт работы с этой функцией.
"--no-force-with-lease" отменит все предыдущие --force-with-lease в командной строке.
Общее замечание о безопасности: указание этой опции без ожидаемого значения, т. е. --force-with-lease или --force-with-lease= очень плохо взаимодействует со всем, что неявно запускает git fetch на удаленном компьютере, чтобы быть нажимается в фоновом режиме, например git fetch origin в вашем репозитории в cronjob.
Защита, которую он предлагает по сравнению с --force, гарантирует, что последующие изменения, на которых не основывалась ваша работа, не будут уничтожены, но это тривиально не работает, если какой-то фоновый процесс обновляет ссылки в фоновом режиме. У нас нет ничего, кроме информации об удаленном отслеживании, которую можно использовать в качестве эвристики для ссылок, которые вы, как ожидается, видели и готовы уничтожить.
Если ваш редактор или какая-либо другая система запускает git fetch в фоновом режиме для вас, способ смягчить это — просто настроить другой удаленный:
Теперь, когда фоновый процесс запускает git fetch origin, ссылки на origin-push не будут обновляться, поэтому такие команды, как:
Сбой, если вы вручную не запустите git fetch origin-push . Этот метод, конечно, полностью побежден чем-то, что запускает git fetch --all , в этом случае вам нужно либо отключить его, либо сделать что-то более утомительное, например:
Т.е. создайте базовый тег для версий исходного кода, которые вы видели и хотите перезаписать, затем перепишите историю и, наконец, принудительно принудительно внесите изменения в мастер, если удаленная версия все еще находится в базе, независимо от того, что ваши локальные удаленные/происхождение/ master был обновлен в фоновом режиме.
В качестве альтернативы можно указать --force-if-includes в качестве вспомогательной опции вместе с --force-with-lease[= ] (т. е. без указания того, на какой именно коммит должна указывать ссылка на удаленной стороне или на какой ссылки на удаленной стороне защищены) во время "push" проверит, интегрированы ли локально обновления из ссылок удаленного отслеживания, которые могли быть неявно обновлены в фоновом режиме, прежде чем разрешать принудительное обновление.
Обычно команда отказывается обновлять удаленную ссылку, которая не является предком локальной ссылки, использованной для ее перезаписи.Кроме того, при использовании параметра --force-with-lease команда отказывается обновлять удаленную ссылку, текущее значение которой не соответствует ожидаемому.
Этот флаг отключает эти проверки и может привести к потере коммитов в удаленном репозитории; используйте его с осторожностью.
Обратите внимание, что --force применяется ко всем отправляемым ссылкам, поэтому его использование с push.default, установленным на соответствие, или с несколькими пунктами назначения, настроенными с помощью remote.*.push, может перезаписать ссылки, отличные от текущей ветки (включая локальную). refs, которые строго отстают от своего удаленного аналога). Чтобы принудительно отправить только одну ветку, используйте + перед refspec для отправки (например, git push origin +master, чтобы принудительно отправить в главную ветку). См. . раздел выше для подробностей.
Принудительное обновление только в том случае, если подсказка ссылки на удаленное отслеживание была интегрирована локально.
Этот параметр включает проверку, которая проверяет, доступен ли конец ссылки для удаленного отслеживания из одной из записей «reflog» локальной ветки, находящейся в ней, для перезаписи. Проверка гарантирует, что любые обновления с удаленного устройства были включены локально, отклоняя принудительное обновление, если это не так.
Если параметр передается без указания --force-with-lease или указывается вместе с параметром --force-with-lease= : , это означает "нет операции".
Указание --no-force-if-includes отключает это поведение.
Эта опция эквивалентна аргументу. Если указаны оба, аргумент командной строки имеет приоритет.
Для каждой ветки, которая обновлена или успешно отправлена, добавьте ссылку на исходную (отслеживающую) ветку, используемую безаргументной git-pull[1] и другими командами. Для получения дополнительной информации см. ветку. .merge в git-config[1].
Эти параметры передаются в git-send-pack[1]. Тонкая передача значительно уменьшает объем отправляемых данных, когда отправитель и получатель имеют много общих объектов. По умолчанию --thin .
Подавлять все выходные данные, включая список обновленных ссылок, если не возникает ошибка. Ход выполнения не передается в стандартный поток ошибок.
Состояние выполнения сообщается в стандартном потоке ошибок по умолчанию, когда он подключен к терминалу, если не указан параметр -q. Этот флаг принудительно устанавливает состояние выполнения, даже если стандартный поток ошибок не направлен на терминал.
Может использоваться, чтобы убедиться, что все коммиты подмодулей, используемые ревизиями, которые нужно отправить, доступны в ветке удаленного отслеживания. Если используется check, Git проверит, что все коммиты подмодулей, которые были изменены в ревизиях, которые нужно отправить, доступны по крайней мере на одном удаленном подмодуле. Если какие-либо фиксации отсутствуют, отправка будет прервана и завершена с ненулевым статусом. Если используется on-demand, будут отправлены все подмодули, которые были изменены в отправляемых версиях. Если по требованию не удалось отправить все необходимые ревизии, оно также будет прервано и завершится с ненулевым статусом. Если используется только, все подмодули будут рекурсивно отправлены, а суперпроект останется невыполненным. Значение no или использование --no-recurse-submodules может использоваться для переопределения переменной конфигурации push.recurseSubmodules, когда рекурсия подмодуля не требуется.
Переключить хук pre-push (см. githooks[5]). По умолчанию используется --verify, что дает хуку возможность предотвратить отправку. С --no-verify ловушка полностью обходится.
Использовать только адреса IPv4, игнорируя адреса IPv6.
Использовать только адреса IPv6, игнорируя адреса IPv4.
URL-адреса GIT
Как правило, URL-адреса содержат информацию о транспортном протоколе, адрес удаленного сервера и путь к репозиторию. В зависимости от транспортного протокола часть этой информации может отсутствовать.
Читайте также: