Как заставить перезаписать локальные файлы на git pull
?
Сценарий следующий:
- Член команды модифицирует шаблоны для сайта, над которым мы работаем
- Они добавляют некоторые изображения в каталог изображений (но забывают добавить их под контролем исходного кода)
- Они отправляют изображения по почте, позже, мне
- Я добавляю изображения под контроль исходного кода и помещаю их в GitHub вместе с другими изменениями.
- Они не могут получать обновления из GitHub, потому что Git не хочет перезаписывать свои файлы.
Это ошибка, которую я получаю:
ошибка: неотслеживаемый файл рабочего дерева 'public / images / icon.gif' будет перезаписан слиянием
Как заставить Git перезаписать их? Этот человек дизайнер. Обычно я разрешаю все конфликты вручную, поэтому на сервере установлена самая последняя версия, которую им просто нужно обновить на своем компьютере.
git reset --hard origin/branch_to_overwrite
git branch <branch> -D
2. Сбросить коммит до конфликта:git reset <commit> --hard
3. Воссоздать ветку:git branch <branch>
4. Установить отслеживание на сервере:git --set-upstream-to=origin/<branch> <branch> 5. Pull:
git pull`git config core.autocrlf false; git ls-files -z | xargs -0 rm; git checkout .
Ответы:
Важно: если у вас есть какие-либо локальные изменения, они будут потеряны. С
--hard
опцией или без нее любые локальные коммиты, которые не были переданы, будут потеряны. [*]Если у вас есть файлы, которые не отслеживаются Git (например, загруженный пользовательский контент), эти файлы не будут затронуты.
Я думаю, что это правильный путь:
Тогда у вас есть два варианта:
ИЛИ Если вы находитесь в другой ветке:
Объяснение:
git fetch
загружает последние с удаленного, не пытаясь объединить или перебазировать что-либо.Затем
git reset
сбрасывает основную ветку к тому, что вы только что получили.--hard
Опция изменяет все файлы в вашем рабочем дереве , чтобы соответствовать файлам вorigin/master
Поддерживать текущие локальные коммиты
[*] : Стоит отметить, что можно сохранить текущие локальные коммиты, создав ветку
master
перед сбросом:После этого все старые коммиты будут сохранены
new-branch-to-save-current-commits
.Незавершенные изменения
Однако незафиксированные изменения (даже поэтапные) будут потеряны. Убедитесь, что вы спрятали и передали все, что вам нужно. Для этого вы можете запустить следующее:
А затем повторно применить эти незафиксированные изменения:
источник
git reset --hard origin/branch-name
git pull -f
git reflog
списка всех коммитов, в том числе и без базы. Пока вы не очистите свою локальную копию с помощьюgit gc
, тогда все потеряноПопробуй это:
Это должно делать то, что вы хотите.
источник
ВНИМАНИЕ:
git clean
удаляет все ваши неотслеживаемые файлы / каталоги и не может быть отменен.Иногда просто
clean -f
не помогает. Если у вас нет отслеживаемых каталогов, опция -d также необходима:ВНИМАНИЕ:
git clean
удаляет все ваши неотслеживаемые файлы / каталоги и не может быть отменен.Сначала рассмотрите использование флага
-n
(--dry-run
). Это покажет вам, что будет удалено, фактически ничего не удаляя:Пример вывода:
источник
.gitignore
git clean -dfx
. В-x
игнорируемых .gitignore. Обычно ваши продукты сборки будут в .gitignore.Как и Ежик, я думаю, что ответы ужасны. Но хотя ежик может быть лучше, я не думаю, что он такой элегантный, как мог бы быть. Я нашел способ сделать это с помощью «выборки» и «слияния» с определенной стратегией. Что должно сделать так, чтобы ваши локальные изменения сохранялись до тех пор, пока они не являются одним из файлов, которые вы пытаетесь перезаписать.
Сначала сделайте коммит ваших изменений
Затем извлеките изменения и перезапишите, если есть конфликт
«-X» - это имя опции, а «их» - значение для этой опции. Вы решаете использовать «свои» изменения, а не «свои», если есть конфликт.
источник
get fetch other-repo
; 2)git merge -s recursive -X theirs other-repo/master
git merge -X theirs origin/master
Вместо того, чтобы делать:
Я бы посоветовал сделать следующее:
Не нужно извлекать все пульты и ветки, если вы собираетесь сбросить в исходную / основную ветку, верно?
источник
git add .
сначала, до того, какgit reset --hard
Похоже, лучше всего сначала сделать:
Чтобы удалить все неотслеживаемые файлы, а затем продолжить с обычного
git pull
...источник
git fetch origin && git reset --hard origin/master
git clean
лучший ответ здесь? Похоже, удаление файлов не обязательно то, что хочет ОП. Они попросили «перезапись локальных файлов», а не удаление.Внимание, это навсегда удалит ваши файлы, если в вашем файле gitignore есть записи каталога / *.
Некоторые ответы кажутся ужасными. Ужасно в смысле того, что случилось с @Lauri, следуя предложению Давида Авсаджанишвили.
Скорее (git> v1.7.6):
Позже вы можете очистить тайник истории.
Вручную, один за другим:
Жестоко, все сразу:
Конечно, если вы хотите вернуться к тому, что вы спрятали:
источник
--include-untracked
просто имитироватьgit add
весь ваш репо, а затем сразу же его копировать.git stash apply
вернул все мои неотслеживаемые файлы за исключением (справедливо) тех, которые слияние уже создало: «уже существует, нет проверки». Работал отлично.git stash -u
.Эта команда может оказаться полезной для удаления локальных изменений:
А затем выполните очистку (удаляет неотслеживаемые файлы из рабочего дерева):
Если вы хотите удалить неотслеживаемые каталоги в дополнение к неотслеживаемым файлам:
источник
Вместо слияния
git pull
попробуйте это:git fetch --all
с последующим:
git reset --hard origin/master
,источник
Единственное, что сработало для меня, было:
Это вернет вам пять коммитов, а затем
Я нашел это, посмотрев, как отменить слияние Git .
источник
work around
но очень эффективный. Поскольку некоторые конфликты могут возникать всего за несколько коммитов, то отмена 5 коммитов обеспечит отсутствие конфликтов с удаленным кодом.Проблема со всеми этими решениями заключается в том, что они все либо слишком сложны, либо, что еще важнее, они удаляют все неотслеживаемые файлы с веб-сервера, что нам не нужно, поскольку всегда есть необходимые файлы конфигурации, которые находятся на сервер а не в репозитории Git.
Вот самое чистое решение, которое мы используем:
Первая команда выбирает новейшие данные.
Вторая команда проверяет, есть ли какие-либо файлы, которые добавляются в хранилище, и удаляет те неотслеживаемые файлы из локального хранилища, которые могут вызвать конфликты.
Третья команда проверяет все файлы, которые были локально изменены.
Наконец, мы делаем попытку обновления до последней версии, но на этот раз без каких-либо конфликтов, так как неотслеживаемые файлы, которые находятся в репозитории, больше не существуют, и все локально измененные файлы уже такие же, как в репозитории.
источник
git merge origin/master
будет быстрее и, вероятно, еще безопаснее. Поскольку, если кто-то внес изменения во время удаления файлов этого сценария (что, скорее всего, не произойдет, но возможно), вся попытка может завершиться неудачей. Единственная причина, которую я привел,pull
заключается в том, что кто-то может работать не над основной веткой, а над другой веткой, и я хотел, чтобы скрипт был универсальным..gitignore
.Прежде всего, попробуйте стандартный способ:
Предупреждение : вышеуказанные команды могут привести к потере данных / файлов, только если они не зафиксированы! Если вы не уверены, сначала сделайте резервную копию всей вашей папки репозитория.
Тогда потяните это снова.
Если вышеперечисленное не поможет и вам не нужны ваши неотслеживаемые файлы / каталоги (на всякий случай сделайте резервную копию сначала), попробуйте выполнить следующие простые шаги:
Это удалит все файлы git (за исключением
.git/
dir, где у вас есть все коммиты) и извлечет его снова.Почему
git reset HEAD --hard
в некоторых случаях может произойти сбой?Пользовательские правила в
.gitattributes file
Наличие
eol=lf
правила в .gitattributes может привести к тому, что git изменит некоторые изменения файла, преобразовав окончания строк CRLF в LF в некоторых текстовых файлах.Если это так, вы должны зафиксировать эти изменения CRLF / LF (просмотрев их
git status
) или попробовать:git config core.autcrlf false
временно игнорировать их.Несовместимость файловой системы
Когда вы используете файловую систему, которая не поддерживает атрибуты разрешений. Например, у вас есть два репозитория, один для Linux / Mac (
ext3
/hfs+
) и другой для файловой системы на основе FAT32 / NTFS.Как вы заметили, существует два разных типа файловых систем, поэтому та, которая не поддерживает разрешения Unix, в основном не может сбросить разрешения для файлов в системе, которая не поддерживает такого рода разрешения, поэтому независимо от того, как
--hard
вы пытаетесь, git всегда обнаруживать некоторые «изменения».источник
У меня такая же проблема. Никто не дал мне это решение, но оно сработало для меня.
Я решил это:
.git
каталог.git reset --hard HEAD
git pull
git push
Теперь это работает.
источник
Бонус:
Говоря о pull / fetch / merge в предыдущих ответах, я хотел бы поделиться интересным и продуктивным приемом:
git pull --rebase
Эта команда является самой полезной командой в моей жизни в Git, которая сэкономила много времени.
Перед отправкой вашего нового коммита на сервер, попробуйте эту команду, и она автоматически синхронизирует последние изменения сервера (с выборкой + слиянием) и поместит ваш коммит наверху в журнале Git. Нет необходимости беспокоиться о ручном извлечении / слиянии.
Найти детали в Что делает "git pull --rebase"? ,
источник
git pull -r
.У меня была аналогичная проблема. Я должен был сделать это:
источник
git clean
с осторожностьюЯ суммировал другие ответы. Вы можете выполнить
git pull
без ошибок:Предупреждение : этот скрипт очень мощный, поэтому вы можете потерять свои изменения.
источник
git reset --hard HEAD
может быть избыточной; Моя локальная страницаreset
руководства (2.6.3) говорит, что во второй строкеgit reset --hard origin/master
«по умолчанию используется HEAD во всех формах».Исходя из моего собственного подобного опыта, решение, предложенное Страхиной Кустудич, выше, безусловно, является лучшим. Как уже отмечали другие, простой сброс настроек удалит все неотслеживаемые файлы, которые могут включать в себя множество вещей, которые вы не хотите удалять, например файлы конфигурации. Более безопасным является удаление только тех файлов, которые будут добавлены, и в этом отношении вы, вероятно, также захотите извлечь любые локально-модифицированные файлы, которые будут обновлены.
Имея это в виду, я обновил сценарий Кустудича, чтобы сделать именно это. Я также исправил опечатку (отсутствует в оригинале).
источник
Я полагаю, что есть две возможные причины конфликта, которые должны быть устранены отдельно, и, насколько я могу судить, ни один из приведенных выше ответов не касается обоих:
Локальные файлы, которые не были отслежены, необходимо удалить вручную (безопаснее) или, как предлагается в других ответах, путем
git clean -f -d
Локальные коммиты, которые не находятся в удаленной ветке, также должны быть удалены. ИМО самый простой способ добиться этого с помощью:
git reset --hard origin/master
(замените 'master' на ту ветку, над которой вы работаете, и запуститеgit fetch origin
первую)источник
Более простым способом было бы:
Это заменит ваш локальный файл на файл в git
источник
Кажется, что большинство ответов здесь сосредоточены на
master
отрасли; однако бывают случаи, когда я работаю над одной и той же веткой функций в двух разных местах, и я хочу, чтобы ребаз в одной из них отражался в другой, не перепрыгивая через обручи.На основе сочетания ответа РНКА и ответ Торека к подобному вопросу , я придумал это , который работает отлично:
Запустите это из ветки, и она будет только сбрасывать вашу локальную ветку на исходную версию.
Это также можно поместить в git alias (
git forcepull
):git config alias.forcepull "!git fetch ; git reset --hard @{u}"
Или в вашем
.gitconfig
файле:Наслаждайтесь!
источник
У меня была такая же проблема и по какой-то причине даже не стал
git clean -f -d
бы это делать. И вот почему: по какой-то причине, если Git игнорирует ваш файл (я полагаю, через запись .gitignore), он все еще беспокоится о перезаписи этого с более поздним извлечением , но очистка не удалит его, если вы не добавите-x
.источник
Я знаю гораздо более простой и менее болезненный метод:
Это оно!
источник
Я просто решил это сам:
где последняя команда дает список ваших локальных изменений. Продолжайте изменять ветку «tmp» до тех пор, пока она не станет приемлемой, а затем вернитесь к master с помощью:
В следующий раз вы, вероятно, сможете справиться с этим более понятным способом, посмотрев «ветку git stash», хотя stash, вероятно, доставит вам неприятности с первых нескольких попыток, поэтому проведите первый эксперимент на некритическом проекте ...
источник
У меня странная ситуация , что ни
git clean
илиgit reset
работы. Я должен удалить конфликтующий файлgit index
, используя следующий скрипт для каждого неотслеживаемого файла:Тогда я могу тянуть просто отлично.
источник
git fetch --all && git reset --hard origin/master && git pull
источник
Несмотря на исходный вопрос, ответы на часто задаваемые вопросы могут вызвать проблемы у людей, которые имеют аналогичную проблему, но не хотят терять свои локальные файлы. Например, см. Комментарии Аль-Панка и crizCraig.
Следующая версия фиксирует ваши локальные изменения во временной ветке (
tmp
), проверяет исходную ветку (я так полагаюmaster
) и объединяет обновления. Вы можете сделать это с помощьюstash
, но я обнаружил, что обычно проще использовать подход ветвления / слияния.где мы предполагаем , что другой репозиторий находится
origin master
.источник
Эти четыре команды работают для меня.
Проверить / вытащить после выполнения этих команд
Я много пробовал, но наконец-то добился успеха с этими командами.
источник
Просто делать
Таким образом, вы избегаете всех нежелательных побочных эффектов, таких как удаление файлов или каталогов, которые вы хотели сохранить, и т. Д.
источник
Сбросьте индекс и заголовок до
origin/master
, но не сбрасывайте рабочее дерево:источник
Требования:
Решение:
Принесите с чистым из файлов и каталогов , игнорирующих .gitignore и жесткий сброс к происхождению .
источник