Когда я пытаюсь нажать внесенное мной изменение, я получаю следующую ошибку ...
git.exe push -v --progress "origin" iteration1:iteration1
remote: *********************************************************************
To ssh://git@mycogit/cit_pplus.git
! [remote rejected] iteration1 -> iteration1 (pre-receive hook declined)
error: failed to push some refs to 'ssh://git@mycogit/cit_pplus.git'
В чем дело?
Ответы:
Вы должны спросить любого, кто поддерживает репо в
git@mycogit/cit_pplus.git
.Ваши коммиты были отклонены
pre-receive
хуком этого репо (это настраиваемый пользователем скрипт, предназначенный для анализа входящих коммитов и определения, достаточно ли они хороши для принятия в репо).Также неплохо бы попросить этого человека обновить хук, чтобы он напечатал причины отклонения.
Если сопровождающий - это вы, значит, у вас проблемы с настройкой на стороне сервера. Пожалуйста, поделитесь дополнительной информацией тогда.
источник
git config user.name 'UpdatedUserName'
Могу поспорить, что вы пытаетесь сделать толчок без быстрой перемотки вперед, и крюк блокирует его Если это так, просто запустите
git pull --rebase
перед нажатием, чтобы перебазировать ваши локальные изменения в новейшей кодовой базе.источник
git branch --set-upstream-to=origin/myBranch
. +1 за ваш ответ.git pull --rebase
, пришлось перебазировать снова и смог подтолкнуть ветку. Наконец я обнаружил, что моя ветка стала защищенной.Размер файла важен. Существует ограничение в ~ 120 МБ для одного файла. В моем случае файл .gitignore, использующий Visual Studio, имел в списке файл, но файл все еще был зафиксирован. При использовании git cli мы можем получить более подробную информацию об ошибке.
хук предварительного получения отклонен был в результате большого файла. В основном валидация толчка.
Чтобы решить эту проблему, я удалил последний коммит, используя:
Затем я исключил файл из коммита.
Примечание: Используйте HEAD ~ N, чтобы вернуться к N числу предыдущих коммитов. (т.е. 3, 4) Всегда используйте ключ --soft, чтобы сохранить изменения в папке
Надеюсь, поможет.
источник
Это может быть связано с тем, что у вас не было прав доступа для отправки коммита в ветку, например
master
. Вы можете попросить сопровождающего дать вам право выдвигать коммиты.источник
В моем случае я получил это сообщение, потому что ветвь была помечена как «Защищенная» в GitLab.
источник
Protected Branches
найти его.Я получил это сообщение, когда на сервере GitLab произошли некоторые изменения. На следующий день толчок работал нормально. В любом случае, как отмечали другие, уточните у своего сопровождающего.
источник
У меня была эта проблема при попытке объединить изменения с размером файла больше, чем разрешено удаленным хранилищем (в моем случае это был GitHub)
источник
Я столкнулся с этой же проблемой.
Для меня это решило переключиться на другую ветку и затем вернуться к первоначальной.
Не уверен, что причина подчеркивания была, но это исправило это.
источник
Bitbucket : проверьте наличие разрешений для филиалов в настройках (может быть «Запретить все»). Если это не сработает, просто клонируйте вашу ветку в новую локальную ветку , перенесите изменения на удаленную (будет создана новая удаленная ветка) и создайте PR.
источник
Если это кому-то поможет:
У меня было пустое хранилище без главной ветки для снятия защиты (в Gitlab), поэтому перед запуском
git push -u origin --all
git push -u origin master
первым,--all
&--tags
)источник
Я столкнулся с той же ошибкой, после проверки у меня был доступ разработчика и я не мог опубликовать новую ветку. Добавление более высоких прав доступа решило эту проблему. (Gitlab)
источник
Я получил эту ошибку с GitHub Gist. Я пытался отправить коммит с файлами в подкаталогах. Оказалось, гист может иметь файлы только в корневом каталоге.
источник
"snippets\\csharp.json"
которого на окнах возникали неприятности.Удалите параметр защищенной ветви или разрешите дополнительные роли, такие как разработчики или администраторы, чтобы позволить этим пользователям, испытывающим эту ошибку, выполнять слияния и переносить.
источник
В моем случае у нас есть хуки для сообщений о коммитах, наш серверный скрипт принимает коммиты, если они имеют специальный формат для сообщений о коммите
"<JIRA ID><Message>"
. Он (ловит) отклоняет коммит, если соответствующий билет Jira не существует или в сообщении коммита есть специальные символы. Я сталкиваюсь с этой ошибкой, когда я добавляю /, [,> и т. Д. В сообщении коммита, удаление этих работает нормально.источник
Это на самом деле происходит, когда YACC включен на стороне сервера в BitBucket. YACC позволяет указывать имена проблем JIRA в сообщении фиксации. Поэтому всякий раз, когда вы что-то делаете, сохраняйте свой номер JIRA в сообщении о коммите, а затем дополнительно вы можете добавить свое собственное сообщение.
источник
Я использовал GitKraken, и мы создали локальную ветвь, затем мы объединили две удаленные ветви в ней, а затем мы попытались подтолкнуть локальную ветвь к источнику. Он не работал с тем же сообщением об ошибке.
Решение было создать местное отделение и толкать его первым к зарождению , а затем выполнить слияние.
источник
Проблема: «PUSH Failed refs / head / - крюк предварительного получения отклонен»
Я столкнулся с проблемой невозможности перенести мои изменения в мою исходную ветку и что-либо в основную ветку репозитория конкретного проекта, так как размер этого репо превысил жесткий лимит 2 ГБ. Это была ошибка. Это потому, что мы неосознанно поместили тестовые данные в bitbucket из других ветвей тестирования.
Итак, попытка проверки заключается в том, что то же самое с другими репозиториями проекта, и у них не было никаких проблем.
Fix:
Мой коллега заметил, что когда мы клонировали проект локально, размер проекта составлял 110 МБ. Итак, мы начали очищать ранее объединенные ветки и активные ветки, которые больше не нужны. Как только эта очистка была сделана для нескольких веток, мы поняли, что размер репо резко сократился с 2 ГБ до 120 МБ. Затем мы попытались перенести изменения в мою ветку, и это сработало.
источник
В моем случае у меня был новый репозиторий, я выдвинул ветку («UCA-46», а не «master»), сделал ребазинг, принудительно подтолкнул снова и получил ошибку. Веб-хуков не было. Я выполнил,
git pull --rebase
как советовал @ThiefMaster , пришлось перебазировать снова и смог нажать на ветку. Но это был странный и сложный путь.Затем я увидел, что обработчик ошибок предварительного приема Git отклонен . Я обнаружил, что моя ветвь стала защищенной . Я снял защиту и мог снова толкнуть.
источник
Я получил это при попытке подтолкнуть к Dokku экземпляр. Оказывается, диск был заполнен на моем сервере.
Ран:
du -f
И результат был:
источник
Для меня авторизация на удаленном git сервере решит проблему.
источник
В моем случае это потому, что я случайно добавил гигантский файл к своему незафиксированному пушу, и я не смог от него избавиться, независимо от того, что я делал после нажатия или сброса или rm.
Моё грязное, но работоспособное решение - переименовать текущий каталог, повторно клонировать каталог в локальный и отразить изменения вручную в локальном каталоге ...
Звучит не очень хорошо, но работает ...
источник
Ошибка для меня заключалась в том, что в проекте не было создано ни одной ветви, и моя роль была разработчиком, поэтому я не мог создать какую-либо ветку, требовать, чтобы они дали мне соответствующие разрешения и все в порядке сейчас!
источник
Ветвь по умолчанию (например
master
) еще не существует для вашего пульта. Поэтому сначала вам нужно создатьmaster
ветку на удаленном сервере git (например, создатьREADME.md
файл по умолчанию ), а затем попробоватьpush
все существующие локальные ветки с помощью этой команды:источник
Для меня все работало нормально, пока Bitbucket автоматически не изменил свою политику сегодня (21 апреля 2020 года). Это происходит в соответствии с новой функцией, недавно представленной сегодня, под названием Workspaces , поэтому я подозреваю, что это как-то связано с этим.
Обходной путь : я (как администратор) следовал инструкциям, чтобы добавить адрес электронной почты для пользователей в пользовательском интерфейсе (адрес электронной почты, который вы используете, можно найти
git config --list
источник
Указание версии node.js может решить проблему следующим образом
источник