Устранение конфликтов с помощью удаленных изменений при извлечении из удаленного Git

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

Итак, есть ли способ заставить Git перезаписать любую версию в GitHub, а не беспокоить меня конфликтами?


person David Tuite    schedule 24.01.2011    source источник
comment
дубликат? stackoverflow.com /вопросы/4779715/   -  person    schedule 24.01.2011
comment
@nvm: Нет. Речь идет о реальных конфликтах слияния, а не о неотслеживаемых файлах, которые будут перезаписаны.   -  person Cascabel    schedule 25.01.2011
comment
@user173973 user173973, если это дубликат, то наоборот. Я думаю, что это не связано. Но хорошо, что вы ответили на другой вопрос;)   -  person digitaldonkey    schedule 17.02.2021


Ответы (2)


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

# fetch from the default remote, origin
git fetch
# reset your current branch (master) to origin's master
git reset --hard origin/master

Я бы лично рекомендовал сначала создать резервную ветку в вашем текущем HEAD, чтобы, если вы поймете, что это была плохая идея, вы не потеряли ее из виду.

Если, с другой стороны, вы хотите сохранить эти коммиты и сделать так, чтобы они выглядели так, как будто вы объединились с источником, и заставить слияние сохранять версии только из источника, вы можете использовать стратегию слияния ours:

# fetch from the default remote, origin
git fetch
# create a branch at your current master
git branch old-master
# reset to origin's master
git reset --hard origin/master
# merge your old master, keeping "our" (origin/master's) content
git merge -s ours old-master
person Cascabel    schedule 24.01.2011
comment
Во втором блоке команд git... должно быть «исходное значение git fetch» ​​после второй команды? - person David Tuite; 27.01.2011
comment
@David: Да, в какой-то момент вы должны получить из источника. Извините, я расценил это как неявное. - person Cascabel; 27.01.2011
comment
Нет ничего, что можно было бы оставить подразумеваемым, когда дело доходит до меня и git ;-). А если серьезно, то огромное спасибо. Ваш ответ именно то, что я искал. - person David Tuite; 27.01.2011
comment
Будет ли это работать, если происхождение действительно впереди? например, могу ли я также использовать его, если у меня нет впереди каких-либо коммитов, и на самом деле ветка может быть перемотана вперед? - person Jared Forsyth; 13.10.2013
comment
Спасибо! Сделал вид, что это легко. - person sholsinger; 13.11.2014
comment
Это помогло разрешить конфликт регистра имен файлов в Windows. - person Will B.; 19.12.2016
comment
Зачем создавать резервную копию? если вы облажались, разве вы не можете просто положиться на reflog, чтобы, так сказать, вернуться в прошлое? - person Jonathan Neufeld; 26.09.2018

Вы можете либо использовать ответ из дублирующей ссылки, указанной nvm.

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

git pull -s recursive -X theirs
person Antoine Pelisse    schedule 24.01.2011
comment
Кажется, у меня не работает. Я получаю сообщение об ошибке: неизвестный переключатель «X», используя git git версии 1.5.6.5. Нужно ли обновляться до нестабильной версии? - person David Tuite; 24.01.2011
comment
Кроме того, Антуан, если вы хотите использовать исходную версию всего, а не только противоречивого контента, вы можете - см. Мой ответ. - person Cascabel; 25.01.2011
comment
И, наконец, ответ nvm не является дубликатом. Это был не конфликт слияния (контент отслеживался с обеих сторон, но с различиями), а скорее слияние, которое перезаписывало неотслеживаемый контент. - person Cascabel; 25.01.2011
comment
Да, мне нравится твой ответ. Очень интересное использование стратегии ours. - person Antoine Pelisse; 25.01.2011
comment
Использование стратегии ours становится более очевидным, если вы помните, что правильное направление слияния почти всегда — от тематической ветки к основной. - person Cascabel; 25.01.2011
comment
Извините, когда я сказал «нестабильный», я имел в виду только то, что в репозитории пакетов Debian, похоже, нет более свежей стабильной версии git: packages.debian.org/lenny/git-core - person David Tuite; 27.01.2011
comment
@David Вы можете получить последнюю версию git для debian с backports.debian.org - person Arrowmaster; 28.01.2011
comment
-s recursive по умолчанию, поэтому git pull -X theirs достаточно. - person Cees Timmerman; 21.09.2015
comment
Это именно то, что я искал! - person micahblu; 16.07.2016
comment
@CeesTimmerman Неправда, по крайней мере, в последнем git. Опция X передается в стратегию слияния, которая является только recursive при слиянии двух голов, поэтому ваша команда будет жаловаться "Could not find merge strategy 'theirs'. Available strategies are: octopus ours recursive resolve subtree." - это позор, потому что X можно установить в конфиге (например, git config pull.twohead theirs), а s нельзя. - person OJFord; 13.01.2017
comment
К сожалению, это не работает для меня. У меня еще есть: error: Your local changes to the following files would be overwritten by merge: file.txt Please commit your changes or stash them before you merge. - person Groosha; 16.07.2020