Я сделал некоторые обновления на своем локальном компьютере, перенес их в удаленный репозиторий, и теперь я пытаюсь вытащить изменения на сервер, и я получаю сообщение;
ошибка: ваши локальные изменения в следующих файлах будут перезаписаны слиянием:
WP-содержание / W3TC-конфигурации / master.php
Пожалуйста, передайте свои изменения или спрячьте их, прежде чем сможете объединить.
Итак, я побежал,
git checkout -- wp-content/w3tc-config/master.php
и попробовал еще раз, и я получил то же сообщение. Я предполагаю, что что-то w3tc
изменилось в файле конфигурации на сервере. Мне все равно, идет ли локальная копия или удаленная копия на сервер (я думаю, что удаленная копия лучше всего), я просто хочу иметь возможность объединить остальные мои изменения (обновления плагинов).
Любые идеи?
Ответы:
Вы не можете объединиться с локальными изменениями. Git защищает вас от потери потенциально важных изменений.
У вас есть три варианта:
Зафиксируйте изменения, используя
Спрятать это.
Шкатулка действует как стек, где вы можете помещать изменения и извлекать их в обратном порядке.
Чтобы спрятать, введите
Сделайте слияние, а затем вытяните тайник:
Откажитесь от локальных изменений
используя
git reset --hard
или
git checkout -t -f remote/branch
Или: отменить локальные изменения для определенного файла
с помощью
git checkout filename
источник
git reset --hard
вы также можете удалить неотслеживаемые файлы сgit clean -dfx
git stash
не будут храниться файлы, для которых нет истории. Так что если у вас есть файлы, которые вы еще не добавили, но которые были бы перезаписаны или «созданы» слиянием, то слияние все равно будет заблокировано. В этой ситуации вы также можетеgit stash -u
хранить незафиксированные файлы. Или вы можете просто удалить их!git clean -dfx
было ужасной идеей. Удалены некоторые файлы .gitignored, которые мне действительно нужны.git reset --hard
внесения изменений все еще были изменения!Первая команда временно сохраняет ваши изменения в тайнике и удаляет их из рабочего каталога.
Вторая команда переключает ветви.
Третья команда восстанавливает изменения, которые вы сохранили в тайнике (эта
--index
опция полезна, чтобы убедиться, что промежуточные файлы все еще находятся в стадии подготовки ).источник
git stash pop
вместоgit stash apply
. Первый удаляет его из тайника, в то время как последний все еще держит его тамВы можете попробовать один из следующих методов:
перебазироваться
Для простых изменений попробуйте перебазировать поверх него, потянув за изменения, например:
Таким образом, он будет применять вашу текущую ветку к верхней ветке после загрузки.
Это эквивалентно:
checkout master
,fetch
иrebase origin/master
команда Git.проверять, выписываться
Если вас не волнуют ваши локальные изменения, вы можете переключиться на другую ветку временно (с применением силы) и переключить ее обратно, например,
сброс
Если вас не волнуют ваши локальные изменения, попробуйте сбросить его в HEAD (исходное состояние), например
Если вышеупомянутое не поможет, это могут быть правила в вашем файле нормализации git (
.gitattributes
), поэтому лучше зафиксировать то, что он говорит. Или ваша файловая система не поддерживает разрешения, поэтому вы должны отключить ееfilemode
в своем git config.Связанный: Как заставить "git pull" перезаписать локальные файлы?
источник
git status
какие у вас изменения после сохранения. Если ни один ответ не помогает, рассмотрите возможность добавления нового вопроса.Попробуй это
и попробуйте снова потянуть
источник
git stash -u
, как прокомментировано на stackoverflow.com/questions/15745045/…Итак, ситуация, с которой я столкнулся, была следующей:
кроме, прямо перед этим, был удаленным: так на самом деле это:
То, что происходило, было (я думаю, не на 100% положительным), крюк получения git post начал работать и облажаться из-за изменений движения в репозитории удаленного сервера, которые теоретически не должны были быть затронуты.
Так что я закончил тем, что проследил через ловушку post-receive и обнаружил это: мне пришлось перейти в удаленный репозиторий на сервере, и произошло изменение (которого не было в моем локальном репозитории, который, на самом деле, сказал, что он совпадает, никаких изменений, ничего для фиксации, обновлений и т. д.) Так что пока на локальном сервере не было никаких изменений, на сервере я затем сделал,
git checkout -- some/file.ext
а затем локальные и удаленные репозитории действительно совпали, и я смог продолжить работу и развернуть. Не совсем уверен, как возникла эта ситуация, хотя пара дюжин разработчиков плюс изменения в ИТ могут быть как-то связаны с этим.источник
ВНИМАНИЕ: Это удалит неотслеживаемые файлы, поэтому это не лучший ответ на этот вопрос.
В моем случае я не хотел хранить файлы, так что это сработало для меня:
Git 2.11 и новее:
Старый Git:
Ссылка: http://www.kernel.org/pub/software/scm/git/docs/git-clean.html
-x означает, что игнорируемые файлы также удаляются, а также файлы, неизвестные git.
-d означает удаление неотслеживаемых каталогов в дополнение к неотслеживаемым файлам.
-f требуется, чтобы заставить его работать.
источник
Чтобы сохранить записи о вновь созданных файлах при решении этой проблемы:
Если у вас есть недавно созданные файлы , вы можете создать исправление локальных изменений, извлечь удаленные слияния и применить локальное исправление после завершения удаленного слияния, как описано ниже, шаг за шагом:
git add .
git diff --cached > mypatch.patch
git reset --hard
git pull
git apply mypatch.patch
Git объединяет изменения и создает файлы .rej для изменений, которые не объединяются.
По предложению Anu, если у вас есть проблемы с применением патча, попробуйте:
git apply --reject --whitespace=fix mypatch.patch
Этот ответ git: patch не применяется, подробно рассказывает об этой проблемеНаслаждайтесь продолжением работы над своей функцией и вносите локальные изменения, когда закончите.
источник
error: patch failed: yourfile.py:33 error: yourfile.py: patch does not apply
получена : у меня все еще есть mypatch.patch, но я не знаю, почему он не применяется, и я потерял свои изменения !git apply --reject --whitespace=fix mypatch.patch
, я получил свои изменения, фу !!! [Спасибо] ( stackoverflow.com/a/15375869/6484358 )Просить совершить, прежде чем тянуть
Если нужно :
источник
Для меня только
git reset --hard
сработало.Фиксация не была вариантом, так как нечего было коммитить.
Прятаться было не вариант, потому что нечего было прятать.
Похоже, это могло быть из исключенных файлов
.git/info/exclude
и сgit update-index --assume-unchanged <file>
некоторыми файлами.источник
В моем случае я сделал резервную копию, а затем удалил файл, на который Git жаловался, зафиксировал его, затем смог наконец проверить другую ветку.
Затем я заменил файл, скопировал обратно содержимое и продолжил, как будто ничего не произошло.
источник
Это, вероятно, вызвано проблемами CRLF.
Смотрите: Почему я должен использовать core.autocrlf = true в Git?
Используйте это, чтобы вытащить и принудительно обновить:
источник
Я попробовал первый ответ:
git stash
с наибольшим количеством очков, но сообщение об ошибке все еще выскакивало, и затем я обнаружил, что эта статья фиксирует изменения вместо тайника «Reluctant Commit»и сообщение об ошибке исчезло окончательно:
1:
git add .
2:
git commit -m "this is an additional commit"
3:
git checkout the-other-file-name
тогда это сработало. надеюсь, этот ответ поможет. :)
источник
Если вы используете Git Extensions, вы сможете найти свои локальные изменения,
Working directory
как показано ниже:Если вы не видите никаких изменений, возможно, это из-за неправильного субмодуля. Так что проверьте все предметы со значком подводной лодки, как показано ниже:
Когда вы нашли какое-то незафиксированное изменение:
Выберите строку с помощью
Working directory
, перейдите на вкладку « Разница », щелкните правой кнопкой мыши строки с карандашом (или+
или-
), выберите « Сброс», чтобы сначала зафиксировать или зафиксировать или сохранить, или все, что вы хотите с ним сделать.источник
Для меня это сработало:
git reset --hard
а потом
git pull origin <*current branch>
после того
git checkout <*branch>
источник
Вероятно
помог бы
источник