Здесь есть ошибка в ваших рассуждениях:
[после] git reset --hard не должно быть локальных изменений (Проверено через git статус также)
Тот факт, что git status говорит:
nothing to commit, working tree clean
, не означает, что нет никаких «локальных изменений». Это означает, что нет незафиксированных изменений.
О git pull: я рекомендую не использовать
Оба вида git pull - с --rebase - или без *1022* - означает запустить git fetch, затем запустить вторую Git команду . Версия с --rebase означает использовать git rebase в качестве второй команды вместо команды по умолчанию . Команда по умолчанию зависит от того, как вы настроили свой git pull; если вы вообще не настраивали его, по умолчанию используется git merge.
Команда git pull предназначена для удобства. После вашего git fetch вы обычно захотите включить извлеченные коммиты, и для этого вы обычно будете использовать git merge или git rebase. Команда git pull объединяет обе фиксации - выборку-затем-слияние или выборку-затем-перебазирование - в одну более удобную команду. Проблемы с их объединением включают:
Это означает, что вы не можете вставлять какие-либо команды между двумя командами. Вы не можете посмотреть, что получил git fetch, пока не попытаетесь их включить. Это немного похоже на открытие двери, когда звонит дверной звонок, а затем прыжок в доставленную коробку, в которой, как вы ожидаете, лежат подушки. Что, если вместо этого они принесут коробку змей? Возможно, будет разумно посмотреть перед прыжком. 1
Если что-то пойдет не так (как здесь), вы не можете знаю, что делать для восстановления.
Синтаксис команды pull странный: он отличается от всех других команд Git сложным для объяснения способами. Это, по крайней мере, похоже на git push, но размышление в этом направлении вводит в заблуждение, потому что pull и pu sh не очень хорошо сочетаются go: противоположность pu sh действительно fetch, а не pull.
1 Есть обоснованные возражения против этой философии . Вы можете отменять действия, если знаете как. Если вы хорошо разбираетесь во всем, Git, не стесняйтесь выбирать тот метод, который лучше всего подходит для вас. Я сам использую комбинацию pull или fetch-then-command.
Так почему же возникают конфликты?
Ваше изображение показывает, что вы уже в фазе частичного слияния, слияния или перебазирования-все еще продолжается, но еще не завершено git pull, который выполнил одну из этих вторых команд. Когда вы находитесь в этом состоянии, многие команды Git не могут выполняться. Это включает git pull.
Чтобы выйти из этого состояния, вы должны либо завершить sh выполняющуюся команду - будь то git merge или git rebase - или полностью остановить ее. Чтобы полностью остановить его, вы можете использовать:
git merge --abort, если выполняется слияние; или git rebase --abort, если выполняется перебазирование; или git reset --hard, независимо от того, какая из этих двух выполняется.
Все три команды вернут вас туда, где вы были до начала, с некоторыми оговорками. (Я не буду go вдаваться в подробности, так как у меня мало времени.)
Мы не можем с уверенностью сказать точно , почему у вас возникают конфликты - не без доступа к вашему репозиторию , тем не мение. Но важная вещь, которую нужно знать о Git, это то, что Git означает коммитит . Коммиты - это единица хранения, с которой вы работаете в Git. Коммиты в основном постоянны - они существуют до тех пор, пока вы найдете их - и полностью, полностью, на 100% доступны только для чтения. Вы никогда не сможете изменить что-либо в любом коммите.
Каждый коммит имеет уникальный ha sh ID. Этот ha sh ID одинаков для каждый Git везде. Это упрощает обмен коммитами между вашим Git и любым другим Git. Они просто проверяют: есть ли у них обоих этот ha sh ID? Если это так, у них обоих есть , что фиксация. Если нет, тот, у кого есть фиксация, может передать ее другой Git.
Каждая фиксация хранит полный снимок всех ваших файлов. Файлы внутри фиксации заморожены: никакая часть фиксации не может быть изменена, включая сохраненные файлы. Сами файлы хранятся в специальном, только для чтения, сжатом и Git -only формате, в котором Git также выполняет дедупликацию, поэтому тот факт, что каждый коммит имеет каждый файл ничего не стоит: если у тысячи коммитов есть тысяча копий какого-то файла, но все эти копии одинаковы, в действительности есть только одна копия.
Любое имя ветки или любое другое имя, такое как имя тега или имя удаленного отслеживания, просто сохраняет необработанный ha sh ID одной фиксации . Это сами коммиты, которые формируются в структуры. См. Что именно мы подразумеваем под «ветвью»? Имена веток идентифицируют последний коммит в некоторых сериях коммитов.
Когда вы запустите git fetch, ваш Git вызовет другие Git и получит любые новые коммиты от них. Ваш Git и их Git просматривают различные идентификаторы ha sh и выясняют, какие коммиты у них есть, а у вас нет. Ваш Get получает их коммиты, и теперь вы делитесь коммитами, но у вас могут быть коммиты они нет.
Когда вы запускаете git merge, вы выбираете их коммиты - обычно имя удаленного отслеживания, например origin/master или origin/dev, и часто у вас есть собственный master или dev`, возможно, для другого last commit - и сообщите свой Git: объедините то, что у меня есть сейчас, с тем, что в этом коммите . Если у вас есть коммиты, которых нет, и у них есть коммиты, которых вы не делали раньше, это объединение может привести к конфликтам слияния.
Когда вы запускаете git rebase, вы выбираете выпустите их коммит и сообщите свои Git: копии коммитов, которые у меня есть сейчас, что они этого не делают, чтобы они основывались на своем последнем коммите . Этот процесс копирования может привести к конфликтам слияния.
Если у вас есть коммиты, которых нет, и вы не ожидали, что будет иметь коммиты, которых не было, вы должны выяснить, почему вот в чем дело. Но здесь почти наверняка так.