Как заставить «git pull» перезаписывать локальные файлы?

7193

Как заставить перезаписать локальные файлы на git pull?

Сценарий следующий:

  • Член команды модифицирует шаблоны для сайта, над которым мы работаем
  • Они добавляют некоторые изображения в каталог изображений (но забывают добавить их под контролем исходного кода)
  • Они отправляют изображения по почте, позже, мне
  • Я добавляю изображения под контроль исходного кода и помещаю их в GitHub вместе с другими изменениями.
  • Они не могут получать обновления из GitHub, потому что Git не хочет перезаписывать свои файлы.

Это ошибка, которую я получаю:

ошибка: неотслеживаемый файл рабочего дерева 'public / images / icon.gif' будет перезаписан слиянием

Как заставить Git перезаписать их? Этот человек дизайнер. Обычно я разрешаю все конфликты вручную, поэтому на сервере установлена ​​самая последняя версия, которую им просто нужно обновить на своем компьютере.

Якуб Трошок
источник
17
Любой, кто читает это, кто думает, что они могут потерять файлы, я был в этом положении и обнаружил, что буфер Sublime Text спас меня - если я над чем-то работаю, то случайно удалите все, пытаясь решить проблему, подобную этой, или используя ответ на этот вопрос и если файлы будут открыты в Sublime (что есть хорошие шансы), тогда файлы все равно будут там, есть Sublime, либо просто там, либо в истории отмены
Тони Ли
64
git reset --hard origin/branch_to_overwrite
Эндрю Аткинсон
1
в основном, только сделать от разработки после первоначальной проверки -b. делай свою работу, затем возвращайся назад.
ldgorman
1
Краткий ответ: удалите и заново создайте ветку. 1. Удалить ветку: git branch <branch> -D2. Сбросить коммит до конфликта: git reset <commit> --hard3. Воссоздать ветку: git branch <branch>4. Установить отслеживание на сервере: git --set-upstream-to=origin/<branch> <branch> 5. Pull: git pull`
Nino Filiu
1
Чтобы поменять все CRLF на LF-концовки (начни с чистого git config core.autocrlf false; git ls-files -z | xargs -0 rm; git checkout .
Хлоя

Ответы:

10047

Важно: если у вас есть какие-либо локальные изменения, они будут потеряны. С --hardопцией или без нее любые локальные коммиты, которые не были переданы, будут потеряны. [*]

Если у вас есть файлы, которые не отслеживаются Git (например, загруженный пользовательский контент), эти файлы не будут затронуты.


Я думаю, что это правильный путь:

git fetch --all

Тогда у вас есть два варианта:

git reset --hard origin/master

ИЛИ Если вы находитесь в другой ветке:

git reset --hard origin/<branch_name>

Объяснение:

git fetch загружает последние с удаленного, не пытаясь объединить или перебазировать что-либо.

Затем git resetсбрасывает основную ветку к тому, что вы только что получили. --hardОпция изменяет все файлы в вашем рабочем дереве , чтобы соответствовать файлам вorigin/master


Поддерживать текущие локальные коммиты

[*] : Стоит отметить, что можно сохранить текущие локальные коммиты, создав ветку masterперед сбросом:

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master

После этого все старые коммиты будут сохранены new-branch-to-save-current-commits.

Незавершенные изменения

Однако незафиксированные изменения (даже поэтапные) будут потеряны. Убедитесь, что вы спрятали и передали все, что вам нужно. Для этого вы можете запустить следующее:

git stash

А затем повторно применить эти незафиксированные изменения:

git stash pop
РНК
источник
14
Осторожно! Если у вас есть локальные unpressed коммиты, это удалит их из вашей ветки! Это решение сохраняет неотслеживаемые файлы в хранилище без изменений, но перезаписывает все остальное.
Matthijs P
479
Это популярный вопрос, поэтому я хотел бы уточнить в верхнем комментарии здесь. Я только что выполнил команды, как описано в этом ответе, и он не удалил ВСЕ локальные файлы. Только удаленно отслеживаемые файлы были перезаписаны, и каждый локальный файл, который был здесь, остался нетронутым.
Красный
14
если вы git reset --hard origin/branch-name
тянете из репозитория, чье
97
Учитывая количество возражений на этот вопрос и ответ, я думаю, что git должен включать такую ​​команду, какgit pull -f
Sophivorus
7
Подтверждает, что не было нажатий до того, как можно будет восстановить хард ресет с помощью git reflogсписка всех коммитов, в том числе и без базы. Пока вы не очистите свою локальную копию с помощью git gc, тогда все потеряно
Коен.
937

Попробуй это:

git reset --hard HEAD
git pull

Это должно делать то, что вы хотите.

Трэвис Ридер
источник
16
Я сделал это, и некоторые локальные файлы, которые больше не были в репо, остались на диске.
Петр Овсяк,
26
Я не думаю, что это правильно. Выше будет выполнено слияние, а не перезапись, которая была запрошена в вопросе: «Как заставить git перезаписать их?» У меня нет ответа, я сейчас его ищу .. в данный момент я переключаюсь на ветку с кодом, который хочу сохранить "git checkout BranchWithCodeToKeep", затем делаю "git branch -D BranchToOverwrite" и затем наконец msgstr "git checkout -b BranchToOverwrite". Теперь у вас будет точный код из BranchWithCodeToKeep в ветви BranchToOverwrite без необходимости выполнять слияние.
фелбус
252
вместо слияния, используя 'git pull', попробуйте git fetch --all, а затем 'git reset --hard origin / master'
Ллойд Мур
5
да, решение @lloydmoore работает для меня. Может быть с ответом, а не просто комментарий.
Макс Уильямс
2
Это вернет текущие изменения обратно к последнему полученному ответу. Затем git pull объединяет изменения из последней ветки. Это сделало именно то, что я хотел сделать .. Спасибо!
Codeversed
460

ВНИМАНИЕ: git cleanудаляет все ваши неотслеживаемые файлы / каталоги и не может быть отменен.


Иногда просто clean -fне помогает. Если у вас нет отслеживаемых каталогов, опция -d также необходима:

# WARNING: this can't be undone!

git reset --hard HEAD
git clean -f -d
git pull

ВНИМАНИЕ: git cleanудаляет все ваши неотслеживаемые файлы / каталоги и не может быть отменен.

Сначала рассмотрите использование флага -n( --dry-run). Это покажет вам, что будет удалено, фактически ничего не удаляя:

git clean -n -f -d

Пример вывода:

Would remove untracked-file-1.txt
Would remove untracked-file-2.txt
Would remove untracked/folder
...
Давид Авсаджанишвили
источник
33
Круто ... Запустил это против моего репозитория dotfiles ... В моем домашнем каталоге. Хорошо, что у меня там не было ничего важного ...
Лаури
7
Я думаю, что описание сценария проясняет, что он действительно не хочет выбрасывать контент. Скорее, он хочет прекратить мерзавец перезаписывать файлы. @ Лаури, этого не должно было случиться с тобой. К сожалению, люди, кажется, неправильно поняли суть описания сценария - см. Мое предложение.
Ежик
19
НАКОНЕЦ . git clean -f -d удобно, когда make clean не может очистить все.
earthmeLon
7
@crizCraig, если они не добавлены в.gitignore
Кровоточащие пальцы
5
@earthmeLon, для этого вы можете захотеть git clean -dfx. В -xигнорируемых .gitignore. Обычно ваши продукты сборки будут в .gitignore.
Пол Дрэйпер
384

Как и Ежик, я думаю, что ответы ужасны. Но хотя ежик может быть лучше, я не думаю, что он такой элегантный, как мог бы быть. Я нашел способ сделать это с помощью «выборки» и «слияния» с определенной стратегией. Что должно сделать так, чтобы ваши локальные изменения сохранялись до тех пор, пока они не являются одним из файлов, которые вы пытаетесь перезаписать.

Сначала сделайте коммит ваших изменений

 git add *
 git commit -a -m "local file server commit message"

Затем извлеките изменения и перезапишите, если есть конфликт

 git fetch origin master
 git merge -s recursive -X theirs origin/master

«-X» - это имя опции, а «их» - значение для этой опции. Вы решаете использовать «свои» изменения, а не «свои», если есть конфликт.

Ричард Керси
источник
56
Это лучший ответ, который я видел до сих пор. Я не пробовал, но в отличие от других ответов, это не попытка уничтожить все ваши неотслеживаемые файлы, что очень опасно по очевидным причинам.
Хайз
5
То же самое - это работало для меня, когда я выполнял очень большое слияние (GitHub pull request), когда я просто хотел принять все это поверх того, что у меня было. Хороший ответ! В моем случае последние две команды были: 1) get fetch other-repo; 2)git merge -s recursive -X theirs other-repo/master
quux00
2
Это перезапишет любые конфликты с файлами репозитория, а не с вашими локальными, правильно?
Натан Ф.
2
Лучший ответ. Самый высокий принятый ответ оставил меня в моем случае на отстраненной голове. Я переключился обратно на местную мастер-ветку и побежалgit merge -X theirs origin/master
petergus
2
Проблема с этим (превосходным) ответом состоит в том, что он добавляет все локальные файлы, которые иногда могут не соответствовать вашим ожиданиям. Вы можете просто хотеть добавить определенные файлы, которые были опущены. Но самое лучшее в этом то, что он заставляет его делать то, что он должен был сделать - добавлять их локально. Вам, вероятно, не понадобится их стратегия -X, так как они одного и того же изображения. На самом деле, я бы посоветовал сначала отменить это, просто чтобы выяснить, есть ли какие-либо аномалии, и добавить их, если они есть, после проверки, что «их» всегда является правильным выбором. Но тогда я параноик.
Боб Кернс
279

Вместо того, чтобы делать:

git fetch --all
git reset --hard origin/master

Я бы посоветовал сделать следующее:

git fetch origin master
git reset --hard origin/master

Не нужно извлекать все пульты и ветки, если вы собираетесь сбросить в исходную / основную ветку, верно?

Johanneke
источник
3
Ваш ответ как раз то, что вам нужно для вашего представителя. Я должен спросить, это также удаляет все неотслеживаемые файлы?
Николас Де Джей
5
Да, большая часть моего представителя пришла отсюда :) Это также удалит все неотслеживаемые файлы. Что-то, о чем я забыл и мне до боли напомнили всего 2 дня назад ...
Йоханнеке
1
См. Комментарии к этому другому ответу: stackoverflow.com/a/8888015/2151700
Йоханнеке
Это не удалило мои неотслеживаемые файлы; что на самом деле то, что я ожидал. Есть ли причина, по которой это может быть для некоторых людей, а не для других?
аричардс
На неотслеживаемые файлы не влияет git reset. Если вы хотите, чтобы они также были удалены, сделайте это git add .сначала, до того, какgit reset --hard
Йоханнеке
131

Похоже, лучше всего сначала сделать:

git clean

Чтобы удалить все неотслеживаемые файлы, а затем продолжить с обычного git pull...

Якуб Трошок
источник
4
Я пытался использовать «git clean» для решения той же проблемы, но она не разрешила. git status говорит: «Ваша ветвь и« origin / master »разошлись, # и имеют 2 и 9 разных коммитов соответственно». и git pull говорит что-то похожее на то, что у вас есть выше.
рабство
43
git clean - довольно тупой инструмент, и он может выбросить много вещей, которые вы, возможно, захотите оставить. Лучше удалить или переименовать файлы, на которые жалуется git, до тех пор, пока извлечение не будет успешным.
Нил Мэйхью
2
Я не думаю, что это работает в целом. Разве нет способа сделать дистанционный клон git с помощью принудительного git pull?
математика
10
@mathick:git fetch origin && git reset --hard origin/master
Arrowmaster
3
Это git cleanлучший ответ здесь? Похоже, удаление файлов не обязательно то, что хочет ОП. Они попросили «перезапись локальных файлов», а не удаление.
Джон Аллен
111

Внимание, это навсегда удалит ваши файлы, если в вашем файле gitignore есть записи каталога / *.

Некоторые ответы кажутся ужасными. Ужасно в смысле того, что случилось с @Lauri, следуя предложению Давида Авсаджанишвили.

Скорее (git> v1.7.6):

git stash --include-untracked
git pull

Позже вы можете очистить тайник истории.

Вручную, один за другим:

$ git stash list
stash@{0}: WIP on <branch>: ...
stash@{1}: WIP on <branch>: ...

$ git stash drop stash@{0}
$ git stash drop stash@{1}

Жестоко, все сразу:

$ git stash clear

Конечно, если вы хотите вернуться к тому, что вы спрятали:

$ git stash list
...
$ git stash apply stash@{5}
еж
источник
2
Нет, я так не думаю. Копирование просто удаляет незафиксированные файлы. Выше также перемещает (прячет) файлы, которые git не отслеживает. Это предотвращает удаление файлов, которые были добавлены на удаленный компьютер, которые еще не были загружены на ваш компьютер, но которые вы создали (!). Все без разрушения незавершенной работы. Надеюсь, что имеет смысл?
Ежик
3
Если у вас нет 1.7.6, вы можете --include-untrackedпросто имитировать git addвесь ваш репо, а затем сразу же его копировать.
nategood
3
Я согласен с ежиком. Если вы сделаете здесь популярные ответы, вы, скорее всего, обнаружите, что вы непреднамеренно убили много вещей, которые вы действительно не хотели потерять.
Guardius
1
У меня были другие неотслеживаемые файлы - кроме того, который объединение / вытягивание хотело перезаписать, поэтому это решение работало лучше всего. git stash applyвернул все мои неотслеживаемые файлы за исключением (справедливо) тех, которые слияние уже создало: «уже существует, нет проверки». Работал отлично.
BigBlueHat
2
Это самый чистый ответ, и он должен быть принятым. Для того, чтобы сохранить некоторые набрав вы можете использовать сокращенную форму: git stash -u.
ccpizza
93

Эта команда может оказаться полезной для удаления локальных изменений:

git checkout <your-branch> -f

А затем выполните очистку (удаляет неотслеживаемые файлы из рабочего дерева):

git clean -f

Если вы хотите удалить неотслеживаемые каталоги в дополнение к неотслеживаемым файлам:

git clean -fd
Вишал
источник
Я думаю, что описание сценария проясняет, что он действительно не хочет выбрасывать контент. Скорее, он хочет прекратить мерзавец перезаписывать файлы. Смотрите мое предложение.
Ежик
3
Хотя этот ответ может не полностью соответствовать описанию, он все же избавил меня от разочарования, связанного с мерзостью возврата каретки (событие с autocrlf false). Когда git reset --hard HEAD не оставляет измененных файлов «no», эти флаги «-f» весьма полезны. Огромное спасибо.
Келлиндил
88

Вместо слияния git pullпопробуйте это:

git fetch --all

с последующим:

git reset --hard origin/master,

Ллойд Мур
источник
61

Единственное, что сработало для меня, было:

git reset --hard HEAD~5

Это вернет вам пять коммитов, а затем

git pull

Я нашел это, посмотрев, как отменить слияние Git .

Крис Билланте
источник
Это было то , что в конечном счете работало для меня , когда я была сила оттолкнула мою ветвь происхождения репо и продолжала получать слияние конфликтов при попытке вытащить его на мой удаленный репозиторий ..
jwfrench
Привет, на самом деле это трюк, work aroundно очень эффективный. Поскольку некоторые конфликты могут возникать всего за несколько коммитов, то отмена 5 коммитов обеспечит отсутствие конфликтов с удаленным кодом.
Хоанг Ле
54

Проблема со всеми этими решениями заключается в том, что они все либо слишком сложны, либо, что еще важнее, они удаляют все неотслеживаемые файлы с веб-сервера, что нам не нужно, поскольку всегда есть необходимые файлы конфигурации, которые находятся на сервер а не в репозитории Git.

Вот самое чистое решение, которое мы используем:

# Fetch the newest code
git fetch

# Delete all files which are being added, so there
# are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    rm -f -- "$file"
done

# Checkout all files which were locally modified
for file in `git diff --name-status | awk '/^[CDMRTUX]/ {print $2}'`
do
    git checkout -- "$file"
done

# Finally pull all the changes
# (you could merge as well e.g. 'merge origin/master')
git pull
  • Первая команда выбирает новейшие данные.

  • Вторая команда проверяет, есть ли какие-либо файлы, которые добавляются в хранилище, и удаляет те неотслеживаемые файлы из локального хранилища, которые могут вызвать конфликты.

  • Третья команда проверяет все файлы, которые были локально изменены.

  • Наконец, мы делаем попытку обновления до последней версии, но на этот раз без каких-либо конфликтов, так как неотслеживаемые файлы, которые находятся в репозитории, больше не существуют, и все локально измененные файлы уже такие же, как в репозитории.

Страхиня Кустудич
источник
Использование «git merge origin / master» в качестве последней строки (как вы говорите в заметке) вместо «git pull» будет быстрее, поскольку вы уже отменили любые изменения в git-репо.
Джош
1
Да, конечно, git merge origin/masterбудет быстрее и, вероятно, еще безопаснее. Поскольку, если кто-то внес изменения во время удаления файлов этого сценария (что, скорее всего, не произойдет, но возможно), вся попытка может завершиться неудачей. Единственная причина, которую я привел, pullзаключается в том, что кто-то может работать не над основной веткой, а над другой веткой, и я хотел, чтобы скрипт был универсальным.
Страхиня Кустудич
Если у вас есть локально созданные файлы, такие как файлы опций, поместите их в .gitignore.
Себи
53

Прежде всего, попробуйте стандартный способ:

git reset HEAD --hard # To remove all not committed changes!
git clean -fd         # To remove all untracked (non-git) files and folders!

Предупреждение : вышеуказанные команды могут привести к потере данных / файлов, только если они не зафиксированы! Если вы не уверены, сначала сделайте резервную копию всей вашей папки репозитория.

Тогда потяните это снова.

Если вышеперечисленное не поможет и вам не нужны ваши неотслеживаемые файлы / каталоги (на всякий случай сделайте резервную копию сначала), попробуйте выполнить следующие простые шаги:

cd your_git_repo  # where 'your_git_repo' is your git repository folder
rm -rfv *         # WARNING: only run inside your git repository!
git pull          # pull the sources again

Это удалит все файлы git (за исключением .git/dir, где у вас есть все коммиты) и извлечет его снова.


Почему git reset HEAD --hardв некоторых случаях может произойти сбой?

  1. Пользовательские правила в .gitattributes file

    Наличие eol=lfправила в .gitattributes может привести к тому, что git изменит некоторые изменения файла, преобразовав окончания строк CRLF в LF в некоторых текстовых файлах.

    Если это так, вы должны зафиксировать эти изменения CRLF / LF (просмотрев их git status) или попробовать: git config core.autcrlf falseвременно игнорировать их.

  2. Несовместимость файловой системы

    Когда вы используете файловую систему, которая не поддерживает атрибуты разрешений. Например, у вас есть два репозитория, один для Linux / Mac ( ext3/ hfs+) и другой для файловой системы на основе FAT32 / NTFS.

    Как вы заметили, существует два разных типа файловых систем, поэтому та, которая не поддерживает разрешения Unix, в основном не может сбросить разрешения для файлов в системе, которая не поддерживает такого рода разрешения, поэтому независимо от того, как --hardвы пытаетесь, git всегда обнаруживать некоторые «изменения».

kenorb
источник
47

У меня такая же проблема. Никто не дал мне это решение, но оно сработало для меня.

Я решил это:

  1. Удалить все файлы. Оставьте только .gitкаталог.
  2. git reset --hard HEAD
  3. git pull
  4. git push

Теперь это работает.

Джон Джон Пихлер
источник
1
Тоже самое. Иногда работает только очень сложное решение, часто бывает так, что недостаточно только перезагрузки и очистки ...
jdehaan
41

Бонус:

Говоря о pull / fetch / merge в предыдущих ответах, я хотел бы поделиться интересным и продуктивным приемом:

git pull --rebase

Эта команда является самой полезной командой в моей жизни в Git, которая сэкономила много времени.

Перед отправкой вашего нового коммита на сервер, попробуйте эту команду, и она автоматически синхронизирует последние изменения сервера (с выборкой + слиянием) и поместит ваш коммит наверху в журнале Git. Нет необходимости беспокоиться о ручном извлечении / слиянии.

Найти детали в Что делает "git pull --rebase"? ,

Саззад Хисейн Хан
источник
3
Короче говоря git pull -r.
Кенорб
29

У меня была аналогичная проблема. Я должен был сделать это:

git reset --hard HEAD
git clean -f
git pull
Райан
источник
6
используйте git cleanс осторожностью
nategood
29

Я суммировал другие ответы. Вы можете выполнить git pullбез ошибок:

git fetch --all
git reset --hard origin/master
git reset --hard HEAD
git clean -f -d
git pull

Предупреждение : этот скрипт очень мощный, поэтому вы можете потерять свои изменения.

Роберт Мун
источник
2
Это перезапишет измененные файлы (файлы, которые были ранее проверены) и удалит неотслеживаемые файлы (файлы, которые никогда не были проверены). Именно то, что я искал, спасибо!
Styfle
3
Я подозреваю, что третья строка git reset --hard HEADможет быть избыточной; Моя локальная страница resetруководства (2.6.3) говорит, что во второй строке git reset --hard origin/master «по умолчанию используется HEAD во всех формах».
аричардс
2
@arichards Я думаю, что ваш подозреваемый прав, но если вторая строка не будет работать (по любой причине), третья строка будет работать хорошо для сброса. Это решение не нуждается в оптимизации. Я просто суммировал другие ответы. Это все. Спасибо за ваш комментарий. :)
Роберт Мун
28

Исходя из моего собственного подобного опыта, решение, предложенное Страхиной Кустудич, выше, безусловно, является лучшим. Как уже отмечали другие, простой сброс настроек удалит все неотслеживаемые файлы, которые могут включать в себя множество вещей, которые вы не хотите удалять, например файлы конфигурации. Более безопасным является удаление только тех файлов, которые будут добавлены, и в этом отношении вы, вероятно, также захотите извлечь любые локально-модифицированные файлы, которые будут обновлены.

Имея это в виду, я обновил сценарий Кустудича, чтобы сделать именно это. Я также исправил опечатку (отсутствует в оригинале).

#/bin/sh

# Fetch the newest code
git fetch

# Delete all files which are being added,
# so there are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    echo "Deleting untracked file $file..."
    rm -vf "$file"
done

# Checkout all files which have been locally modified
for file in `git diff HEAD..origin/master --name-status | awk '/^M/ {print $2}'`
do
    echo "Checking out modified file $file..."
    git checkout $file
done

# Finally merge all the changes (you could use merge here as well)
git pull
Рольф Кайзер
источник
Использование «git merge origin / master» в качестве последней строки (как вы говорите в заметке) вместо «git pull» будет быстрее, поскольку вы уже отменили любые изменения в git-репо.
Джош
Требуется извлечение измененных файлов, так что это работает 100% раз. Я обновил свой сценарий с этим давно, но забыл обновить здесь. Я также использую это немного по-другому, чем вы. Я извлекаю файлы, которые имеют любой тип модификации, не только M, поэтому он работает постоянно.
Страхиня Кустудич
24

Я полагаю, что есть две возможные причины конфликта, которые должны быть устранены отдельно, и, насколько я могу судить, ни один из приведенных выше ответов не касается обоих:

  • Локальные файлы, которые не были отслежены, необходимо удалить вручную (безопаснее) или, как предлагается в других ответах, путем git clean -f -d

  • Локальные коммиты, которые не находятся в удаленной ветке, также должны быть удалены. ИМО самый простой способ добиться этого с помощью: git reset --hard origin/master(замените 'master' на ту ветку, над которой вы работаете, и запустите git fetch originпервую)

Tiho
источник
22

Более простым способом было бы:

git checkout --theirs /path/to/file.extension
git pull origin master

Это заменит ваш локальный файл на файл в git

Максимус 69
источник
21

Кажется, что большинство ответов здесь сосредоточены на masterотрасли; однако бывают случаи, когда я работаю над одной и той же веткой функций в двух разных местах, и я хочу, чтобы ребаз в одной из них отражался в другой, не перепрыгивая через обручи.

На основе сочетания ответа РНКА и ответ Торека к подобному вопросу , я придумал это , который работает отлично:

git fetch
git reset --hard @{u}

Запустите это из ветки, и она будет только сбрасывать вашу локальную ветку на исходную версию.

Это также можно поместить в git alias ( git forcepull):

git config alias.forcepull "!git fetch ; git reset --hard @{u}"

Или в вашем .gitconfigфайле:

[alias]
  forcepull = "!git fetch ; git reset --hard @{u}"

Наслаждайтесь!

JacobEvelyn
источник
Этот ответ также хорош, потому что он работает независимо от того, в какой ветке вы находитесь!
листовая мука
19

У меня была такая же проблема и по какой-то причине даже не стал git clean -f -dбы это делать. И вот почему: по какой-то причине, если Git игнорирует ваш файл (я полагаю, через запись .gitignore), он все еще беспокоится о перезаписи этого с более поздним извлечением , но очистка не удалит его, если вы не добавите -x.

Tierlieb
источник
19

Я знаю гораздо более простой и менее болезненный метод:

$ git branch -m [branch_to_force_pull] tmp
$ git fetch
$ git checkout [branch_to_force_pull]
$ git branch -D tmp

Это оно!

ddmytrenko
источник
18

Я просто решил это сам:

git checkout -b tmp # "tmp" or pick a better name for your local changes branch
git add -A
git commit -m 'tmp'
git pull
git checkout master # Or whatever branch you were on originally
git pull
git diff tmp

где последняя команда дает список ваших локальных изменений. Продолжайте изменять ветку «tmp» до тех пор, пока она не станет приемлемой, а затем вернитесь к master с помощью:

git checkout master && git merge tmp

В следующий раз вы, вероятно, сможете справиться с этим более понятным способом, посмотрев «ветку git stash», хотя stash, вероятно, доставит вам неприятности с первых нескольких попыток, поэтому проведите первый эксперимент на некритическом проекте ...

Саймон Б.
источник
17

У меня странная ситуация , что ни git cleanили git resetработы. Я должен удалить конфликтующий файл git index, используя следующий скрипт для каждого неотслеживаемого файла:

git rm [file]

Тогда я могу тянуть просто отлично.

Чэнь Чжан
источник
16

git fetch --all && git reset --hard origin/master && git pull

Сьюдж
источник
14

Несмотря на исходный вопрос, ответы на часто задаваемые вопросы могут вызвать проблемы у людей, которые имеют аналогичную проблему, но не хотят терять свои локальные файлы. Например, см. Комментарии Аль-Панка и crizCraig.

Следующая версия фиксирует ваши локальные изменения во временной ветке ( tmp), проверяет исходную ветку (я так полагаю master) и объединяет обновления. Вы можете сделать это с помощью stash, но я обнаружил, что обычно проще использовать подход ветвления / слияния.

git checkout -b tmp
git add *; git commit -am "my temporary files"
git checkout master

git fetch origin master
git merge -s recursive -X theirs origin master

где мы предполагаем , что другой репозиторий находится origin master.

Snowcrash
источник
13

Эти четыре команды работают для меня.

git reset --hard HEAD
git checkout origin/master
git branch -D master
git checkout -b master

Проверить / вытащить после выполнения этих команд

git pull origin master

Я много пробовал, но наконец-то добился успеха с этими командами.

вишеш чандра
источник
2
"git branch -D master" удалить ветку. так что будь осторожен с этим. Я предпочитаю использовать «git checkout origin / master -b <новое имя ветви>», которое создает новую ветку с новым именем, и вам нужно 3,4 строки. Также рекомендуется использовать "git clean -f".
Чанд Приянкара
13

Просто делать

git fetch origin branchname
git checkout -f origin/branchname // This will overwrite ONLY new included files
git checkout branchname
git merge origin/branchname

Таким образом, вы избегаете всех нежелательных побочных эффектов, таких как удаление файлов или каталогов, которые вы хотели сохранить, и т. Д.

user2696128
источник
12

Сбросьте индекс и заголовок до origin/master, но не сбрасывайте рабочее дерево:

git reset origin/master

источник
Я лично нашел это наиболее полезным. Затем он сохраняет ваше рабочее дерево, чтобы вы могли проверить его снова. Для моей проблемы у меня были те же самые файлы, которые были добавлены, так что он застрял. Странно, я знаю.
Джейсон Себринг
12

Требования:

  1. Отслеживайте локальные изменения, чтобы никто их здесь не потерял.
  2. Сделайте так, чтобы локальный репозиторий соответствовал удаленному репозиторию источника.

Решение:

  1. Копите местные изменения.
  2. Принесите с чистым из файлов и каталогов , игнорирующих .gitignore и жесткий сброс к происхождению .

    git stash --include-untracked
    git fetch --all
    git clean -fdx
    git reset --hard origin/master
    
vezenkov
источник