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

вопрос создан в Sun, Dec 23, 2018 12:00 AM

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

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

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

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

  

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

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

    
6223
  1. любой, кто читает это, кто думает, что они могут потерять файлы, я был в этой позиции и обнаружил, что буфер Sublime Text спас меня - если я над чем-то работаю, то случайно удалите все, пытаясь решить проблему, аналогичную этой, или воспользовавшись ответом на этот вопрос и открыв файлы в Sublime (что есть хорошие шансы), тогда файлы все равно будут там, есть Sublime, либо просто там, или в истории отмены
    2016-01-20 08: 51: 22Z
  2. git reset --hard origin/branch_to_overwrite
    2016-03-22 08: 37: 48Z
  3. в основном, только отрываться от разработки после начальной проверки -b. сделай свою работу, затем вернись обратно.
    2018-08-22 09: 09: 33Z
  4. Краткий ответ: удалить и заново создать ветку. 1. Удалить ветку: 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`
    2018-09-24 08: 54: 52Z
  5. Чтобы изменить все окончания CRLF на LF, (start clean) git config core.autocrlf false; git ls-files -z | xargs -0 rm; git checkout .
    2019-01-17 02: 46: 59Z
30 ответов                              30                         

Важно: если у вас есть какие-либо локальные изменения, они будут потеряны. С опцией --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
    
8671
2018-07-17 21: 53: 17Z
  1. Осторожно! Если у вас есть локальные unpressed коммиты, это удалит их из вашей ветки! Это решение не отслеживаетсяФайл не хранится в репозитории, но перезаписывает все остальное.
    2012-05-17 08: 18: 25Z
  2. Это популярный вопрос, поэтому я хотел бы уточнить верхний комментарий здесь. Я только что выполнил команды, как описано в этом ответе, и он не удалил ВСЕ локальные файлы. Только удаленно отслеживаемые файлы были перезаписаны, а все локальные файлы, которые были здесь, остались нетронутыми.
    2012-11-22 10: 38: 05Z
  3. Это сработало для меня, и мои локальные файлы НЕ были удалены.
    2013-05-21 18: 16: 11Z
  4. в случае, если вы извлекаете из репозитория, чье имя удаленной ветви отличается от "master", используйте git reset --hard origin/branch-name
    2013-12-17 11: 17: 24Z
  5. Учитывая количество возражений на этот вопрос и ответ, я думаю, что git должен включать в себя такую ​​команду, как git pull -f
    2014-08-26 01: 33: 48Z

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

 
git reset --hard HEAD
git pull

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

    
842
2017-01-14 15: 10: 38Z
  1. Я сделал это, и некоторые локальные файлы, которые больше не были в репо, остались на диске.
    2011-04-08 16: 00: 57Z
  2. Я не думаю, что это правильно. Выше будет выполнено слияние, а не перезапись, которая была запрошена в вопросе: «Как заставить git перезаписать их?» У меня нет ответа, я сейчас его ищу .. в данный момент я переключаюсь на ветку с кодом, который хочу сохранить "git checkout BranchWithCodeToKeep", затем делаю "git branch -D BranchToOverwrite" и затем наконец msgstr "git checkout -b BranchToOverwrite". Теперь у вас будет точный код из BranchWithCodeToKeep для ветви BranchToOverwrite без необходимости выполнять слияние.
    2011-07-13 10: 11: 31Z
  3. вместо слияния с использованием 'git pull', попробуйте git fetch --all, за которым следует 'git reset --hard origin /master'
    2012-02-21 14: 56: 54Z
  4. да, решение @lloydmoore работает для меня. Может быть ответом, а не просто комментарием.
    2012-11-19 09: 54: 51Z
  5. Это вернет текущие изменения обратно к последней извлеченной фиксации ветвления. Затем git pull объединяет изменения из последней ветки. Это было именно то, что я хотел сделать .. Спасибо!
    2014-12-05 17: 42: 09Z

ВНИМАНИЕ: 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
...
    
430
2018-08-17 19: 32: 32Z
  1. Круто ... Запустил это в моем репозитории dotfiles ... В моем домашнем каталоге. Хорошо, что у меня там не было ничего важного ...
    2011-12-11 10: 35: 13Z
  2. Я думаю, что описание сценария проясняет, что он действительно не хочет выбрасывать контент. Скорее всего, он хочет прекратить мерзавец перезаписывать файлы. @ Лаури, этого не должно было случиться с тобой. К сожалению, люди, кажется, неправильно поняли суть описания сценария - см. Мое предложение.
    2012-02-11 23: 05: 41Z
  3. FINALLY . git clean -f -d удобно, когда make clean не может очистить все.
    2012-06-23 04: 32: 08Z
  4. @ crizCraig, если они не добавлены в .gitignore
    2013-06-13 06: 58: 23Z
  5. @ earthmeLon, для этого вам может потребоваться git clean -dfx. -x игнорирует .gitignore. Обычно ваши продукты для сборки будут в .gitignore.
    2015-08-12 18: 28: 00Z

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

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

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

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

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

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

    
357
2017-02-23 13: 45: 53Z
  1. Это лучший ответ, который я когда-либо видел. Я не пробовал, но, в отличие от других ответов, он не пытается уничтожить все ваши неотслеживаемые файлы, что очень опасно по понятным причинам.
    2012-05-07 09: 36: 16Z
  2. То же самое - это работало для меня при выполнении очень большого слияния (запрос на GitHub), когда я просто хотел принять все это поверх того, что у меня было. Хороший ответ! В моем случае последние две команды были: 1) get fetch other-repo; 2) git merge -s recursive -X theirs other-repo/master
    2012-07-27 01: 44: 56Z
  3. Это перезапишет любые конфликты с файлами репозиториев, а не с вашими локальными, правильно?
    2014-12-05 11: 40: 52Z
  4. Лучший ответ. Самый высокий принятый ответ оставил меня в моем случае на отстраненной голове. Я переключился обратно на локальную главную ветку и запустил git merge -X theirs origin/master
    2016-03-11 12: 46: 21Z
  5. Подожди ... не имеет git add * и git commit -a <more-options-here> имеют одинаковый эффект? Зачем вам оба?
    2017-04-25 20: 41: 26Z

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

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

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

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

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

    
259
2016-09-14 09: 46: 30Z
  1. Ваш ответ - именно то, что вам нужно для вашего представителя. Я должен спросить, это также удаляет все неотслеживаемые файлы?
    2014-01-07 06: 38: 09Z
  2. Да, большинство моихрепутация идет отсюда :) Это также удалит все неотслеживаемые файлы. Что-то, что я забыл и мне до боли напомнили всего 2 дня назад ...
    2014-01-09 12: 01: 15Z
  3. Просмотрите комментарии к этому другому ответу: stackoverflow.com/a/8888015 /2151700
    2014-01-09 12: 02: 55Z
  4. Это не удалило мои неотслеживаемые файлы; что на самом деле то, что я ожидал. Есть ли причина, по которой это может быть для одних людей, а не для других?
    2016-04-19 15: 27: 08Z
  5. Не отслеживаемые файлы не затрагиваются сбросом git. Если вы хотите, чтобы они также были удалены, сначала выполните git add ., а не git reset --hard
    2017-08-15 09: 12: 21Z

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

 
git clean

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

    
128
2017-01-14 15: 10: 01Z
  1. Я пытался использовать «git clean» для решения той же проблемы, но она не разрешила. git status говорит: «Ваша ветвь и« origin /master »разошлись, # и имеют 2 и 9 разных коммитов соответственно». и git pull говорит что-то похожее на то, что у вас есть выше.
    2009-09-24 04: 25: 42Z
  2. git clean - довольно тупой инструмент, который может отбросить множество вещей, которые вы можете захотеть оставить. Лучше удалять или переименовывать файлы, на которые жалуется git, до тех пор, пока извлечение не будет успешным.
    2010-07-02 13: 21: 35Z
  3. Я не думаю, что это работает в целом. Разве нет способа сделать дистанционное клонирование git с помощью принудительного git pull?
    2010-11-29 18: 30: 01Z
  4. @ mathick: git fetch origin && git reset --hard origin/master
    2011-02-23 04: 24: 56Z
  5. Является ли git clean лучшим ответом здесь? Похоже, удаление файлов не обязательно то, что хочет ОП. Они попросили «перезапись локальных файлов», а не удаление.
    2014-03-04 08: 28: 11Z

Предупреждение. это навсегда удалит ваши файлы, если в вашем файле 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}
    
106
2018-03-07 07: 00: 46Z
  1. Нет, я так не думаю. Копирование просто удаляет незафиксированные файлы. Выше также перемещает (прячет) файлы, которые git не отслеживает. Это предотвращает удаление файлов, которые были добавлены на удаленный компьютер, которые еще не были загружены на ваш компьютер, но которые вы создали (!). Все без разрушения незавершенной работы. Надеюсь, это имеет смысл?
    2012-03-20 23: 54: 34Z
  2. Если у вас нет 1.7.6, вы можете имитировать --include-untracked, просто временно сделав git add-весь ваш репо, а затем сразу же спрятать его.
    2012-05-01 22: 48: 15Z
  3. Я согласен с ежом. Если вы сделаете популярные ответы здесь, вы, скорее всего, обнаружите, что вы случайно убили много вещей, которые вы действительно не хотели терять.
    2013-01-31 21: 28: 03Z
  4. У меня были другие неотслеживаемые файлы - кроме того, который объединение /вытягивание хотело перезаписать, поэтому это решение работало лучше всего. git stash apply вернул все мои неотслеживаемые файлы, за исключением (справедливо) тех, которые слияние уже создало: «уже существует, нет проверки». Работал отлично.
    2013-04-25 04: 55: 09Z
  5. Это самый чистый ответ, и он должен быть принятым. Чтобы сохранить набор текста, вы можете использовать короткую форму: git stash -u.
    2017-03-23 ​​08: 30: 32Z

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

 
git checkout <your-branch> -f

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

 
git clean -f

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

 
git clean -fd
    
91
2017-01-14 15: 12: 22Z
  1. Я думаю, что описание сценария проясняет, что он действительно не хочет выбрасывать контент. Скорее всего, он хочет прекратить мерзавец перезаписывать файлы. Смотрите мое предложение.
    2012-02-11 23: 03: 53Z
  2. Хотя этот ответ может не вписываться точно в описание, он все же избавил меня от разочарования, связанного с git twiddling с возвратами каретки (событие с autocrlf false). Когда git reset --hard HEAD не оставляет измененных файлов «no», эти флаги «-f» весьма полезны. Большое спасибо.
    2013-01-16 10: 28: 58Z

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

git fetch --all

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

git reset --hard origin/master.

    
84
2018-03-21 07: 21: 12Z

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

 
git reset --hard HEAD~5

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

 
git pull

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

    
57
2017-05-23 10: 31: 37Z
  1. Это было то, что в конечном итоге сработало для меня, так как я принудительно подтолкнул свою ветку к исходному репо и продолжал получать конфликты слияния при попытке вытащить его в мое удаленное репо ..
    2014-05-07 05: 16: 17Z
  2. Привет, на самом деле это трюк для work around, но действительно эффективный. Поскольку некоторые конфликты могут возникать всего за несколько коммитов, то отмена 5 коммитов обеспечит отсутствие конфликтов с удаленным кодом.
    2014-11-21 10: 03: 43Z

Проблема со всеми этими решениями заключается в том, что все они либо слишком сложны, либоПроблема igger в том, что они удаляют все неотслеживаемые файлы с веб-сервера, что нам не нужно, поскольку всегда есть необходимые файлы конфигурации, которые находятся на сервере, а не в репозитории 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
  • Первая команда выбирает новейшие данные.

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

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

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

52
2014-05-23 21: 14: 30Z
  1. Использование "git merge origin /master" в качестве последней строки (как вы говорите в заметке) вместо "git pull" будет быстрее, так как вы уже потянули любые изменения из репозитория git.
    2013-05-06 06: 21: 24Z
  2. Да, конечно, git merge origin/master будет быстрее и, вероятно, еще безопаснее. Поскольку, если кто-то внес изменения во время удаления файлов этого сценария (что, скорее всего, не произойдет, но возможно), вся попытка может завершиться неудачей. Единственная причина, по которой я добавил pull, заключается в том, что кто-то, возможно, не работает над основной веткой, но какая-то другая ветка, и я хотел, чтобы скрипт был универсальным.
    2013-09-01 22: 25: 37Z
  3. Если вы создали локально созданные файлы, например файлы опций, поместите их в .gitignore.
    2017-11-21 11: 41: 39Z

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

Я решил это следующим образом:

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

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

    
42
2019-01-18 23: 00: 30Z
  1. То же самое здесь. Иногда работает только очень сложное решение, часто бывает так, что недостаточно только перезагрузки и очистки ...
    2011-12-15 11: 28: 09Z

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

 
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 всегда обнаруживает некоторые "изменения".

41
2019-01-31 15: 48: 34Z

Бонус:

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

git pull --rebase

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

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

Найти подробности в Что делает "git pull --rebase"? .

    
35
2018-04-27 13: 02: 41Z

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

 
git reset --hard HEAD
git clean -f
git pull
    
27
2011-11-06 16: 35: 34Z
  1. используйте git clean с осторожностью
    2012-03-30 16: 39: 22Z

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

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

 
#/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
    
27
2015-08-13 23: 12: 27Z
  1. Использование "git merge origin /master" в качестве последней строки (как вы говорите в заметке) вместо "git pull" будет быстрее, так как вы уже потянули любые изменения из репозитория git.
    2013-05-06 06: 20: 47Z
  2. Требуется извлечение измененных файлов, поэтому это работает 100% раз. Я обновил свой сценарий с этим давно, но забыл обновить здесь. Я также использую это немного по-другому, чем вы. Я извлекаю файлы, которые имеют любой тип модификации, не только M, поэтому он работает постоянно.
    2013-09-01 22: 48: 40Z

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

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

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

    
27
2017-01-14 15: 42: 28Z
  1. Это перезапишет измененные файлы (файлы, которые были ранее проверены) и удалит неотслеживаемые файлы (файлы, которые никогда не были проверены). Именно то, что я искал, спасибо!
    2016-03-03 16: 01: 46Z
  2. Я подозреваю, что третья строка git reset --hard HEAD может быть избыточной; Моя локальная страница руководства (2.6.3) говорит, что reset во второй строке git reset --hard origin/master "по умолчанию HEAD во всех формах."
    2016-04-19 15: 40: 52Z
  3. @ arichards Я думаю, что ваш подозреваемый прав, но если вторая строка не будет работать (по любой причине), третья строка будет работать хорошо для сброса. Это решение не нуждается в оптимизации. Я просто суммировал другие ответы. Это все. Спасибо за ваш комментарий. :)
    2016-04-20 02: 12: 45Z

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

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

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

23
2011-12-12 20: 05: 07Z

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

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

 
git fetch
git reset --hard @{u}

Запустите его из ветки, и он вернет только локальную ветвь к исходной версии.

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

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

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

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

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

    
20
2017-05-23 12: 18: 32Z
  1. Этот ответ также хорош, потому что он работает независимо от того, в какой ветке вы находитесь!
    2018-09-11 20: 14: 56Z

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

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

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

    
20
2015-05-05 08: 03: 29Z

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

    
19
2015-03-18 19: 46: 19Z

Я только что решил это сам:

 
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» до тех пор, пока она не станет приемлемой, а затем вернитесь к мастеру с помощью:

 
git checkout master && git merge tmp

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

18
2017-01-14 15: 13: 29Z

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

 
git rm [file]

Тогда я могу тянуть очень хорошо.

    
17
2017-12-05 04: 35: 20Z

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

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

Вот и все!

    
17
2018-09-05 16: 52: 42Z

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

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

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

 
git pull origin master

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

    
13
2014-03-20 04: 24: 02Z
  1. "git branch -D master" удалить ветку. так что будь осторожен с этим. Я предпочитаю использовать "git checkout origin /master -b < имя новой ветви >" которые создают новую ветку с новым именем, и вам нужно 3,4 строки. Также рекомендуется использовать "git clean -f".
    2014-04-05 11: 49: 57Z

Несмотря на исходный вопрос, ответы на часто задаваемые вопросы могут вызвать проблемы у людей, у которых есть похожая проблема, но они не хотят терять свои локальные файлы. Например, см. Комментарии Аль-Панка и 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.

    
13
2015-03-18 19: 43: 07Z

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

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

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

    
12
2017-01-14 15: 48: 47Z

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

 
git reset origin/master
    
11
2013-02-15 13: 41: 43Z
  1. Мне лично это показалось наиболее полезным. Затем он сохраняет ваше рабочее дерево, чтобы вы могли проверить его снова. Для моей проблемы у меня были те же самые файлы, которые были добавлены, так что он застрял. Странно, я знаю.
    2014-01-04 21: 03: 59Z

Я прочитал все ответы, но искал единственную команду для этого. Вот что я сделал. Добавлен псевдоним git для .gitconfig

 
[alias]
      fp = "!f(){ git fetch ${1} ${2} && git reset --hard ${1}/${2};};f"

Запустите вашу команду как

 
git fp origin master

эквивалентно

 
git fetch origin master
git reset --hard origin/master
    
9
2016-07-08 13: 11: 14Z

Требования:

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

Решение:

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

     
    git stash --include-untracked
    git fetch --all
    git clean -fdx
    git reset --hard origin/master
    
9
2017-01-14 15: 44: 53Z
источник размещен Вот