Как отменить слияние веток git visual studio

Обновлено: 07.01.2025

Основываясь на некоторых инструкциях, которые я нашел, я попытался запустить

Я не хочу, чтобы моя ветка была впереди по количеству попыток. Как мне вернуться к этой точке?

ОТВЕТЫ

Ответ 1

С помощью git reflog проверьте, какой коммит находится перед слиянием ( git reflog будет лучшим вариантом, чем git log ). Затем вы можете сбросить его, используя:

Есть и другой способ:

Это вернет вам 1 коммит.

Имейте в виду, что любые измененные и незафиксированные/неснятые файлы будут сброшены в их неизмененное состояние. Чтобы сохранить их, скрывайте изменения или смотрите --merge ниже.

Как @Velmont предложил ниже в своем ответе, в этом прямом случае используется:

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

Еще один совет - использовать переключатель --merge вместо --hard поскольку он не сбрасывает файлы без необходимости:

--merge

Сбрасывает индекс и обновляет файлы в рабочем дереве, которые отличаются между <commit> и HEAD, но сохраняет те, которые отличаются между индексом и рабочим деревом (т.е. С изменениями, которые не были добавлены).

Ответ 2

Предполагая, что ваш локальный мастер не опережал начало/мастер, вы должны иметь возможность делать

Затем ваша локальная ветвь master должна выглядеть идентично origin/master .

Ответ 3

Чтобы отменить слияние , которое уже было нажато:

Обязательно верните возврат, если вы снова завершаете ветку, как сказал Линус.

Ответ 4

Ссылка ref ORIG_HEAD будет указывать на первоначальную фиксацию до слияния.

(Параметр --merge не имеет ничего общего с слиянием. Это просто как git reset --hard ORIG_HEAD , но безопаснее, так как он не касается незафиксированных изменений.)

Ответ 5

С более новыми версиями Git, если вы еще не завершили слияние, и у вас есть конфликт слияния, вы можете просто сделать:

От man git merge :

[Это] можно запустить только после того, как слияние привело к конфликтам. git merge --abort прервет процесс слияния и попытается восстановить состояние предварительного слияния.

Ответ 6

Вы должны reset выполнить предыдущую фиксацию. Это должно работать:

Или даже HEAD^^ , чтобы вернуться, чтобы вернуть фиксацию. Вы всегда можете дать полную ссылку на SHA, если не уверены, сколько шагов вы должны предпринять.

Если у вас возникли проблемы, и ваша главная ветвь не имела локальных изменений, вы можете reset до origin/master .

Ответ 7

В последнее время я использовал git reflog , чтобы помочь с этим. Это в основном работает только в том случае, если слияние произошло просто, и оно было на вашем компьютере.

git reflog может возвращать что-то вроде:

Первая строка указывает, что произошло слияние. Вторая строка - это время до моего слияния. Я просто git reset --hard 43b6032 , чтобы заставить эту ветвь отслеживать до слияния и переноса.

Ответ 8

С помощью современных Git вы можете:

Более старый синтаксис:

Но на самом деле стоит заметить, что git merge --abort эквивалентен только git reset --merge , если присутствует MERGE_HEAD . Это можно прочитать в справке Git для команды merge.

После неудачного слияния, когда нет MERGE_HEAD , сбойное слияние может быть отменено с помощью git reset --merge , но необязательно с git merge --abort , , поэтому они не только старый и новый синтаксис для того же вещь.

Лично я нахожу git reset --merge гораздо более мощным и полезным в повседневной работе, так что тот, который я всегда использую.

Ответ 9

Хорошо, ответы, которые дали мне другие люди, были близки, но это не сработало. Вот что я сделал.

. дал мне следующий статус.

Короче говоря, мои команды дошли до этого:

Ответ 10

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

Ответ 11

Если вы находитесь в процессе слияния, вы всегда можете прервать его git merge --abort

Ответ 12

Если вы еще не сделали этого, вы можете использовать

Отменит слияние (и все, что вы сделали).

Ответ 13

Получил этот вопрос, также обратившись к тому, чтобы вернуться к совпадению с началом (т.е. НЕТ берет начало до начала). Изучая далее, нашел там команду reset для этого:

Примечание: @ является сокращением для origin/master . (И, конечно же, вам нужен этот удаленный репозиторий для этого.)

Ответ 14

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

Принятый ответ не работал для меня, но эта команда достигла результатов, которые я искал.

Ответ 15

Я просто прочитал эту страницу, поскольку случайно случайно объединил ветку тестирования вместо моей ветки релиза с мастером для развертывания (веб-сайт, мастер - это то, что является живым). У тестирующей ветки есть две другие ветки, объединенные с ней и насчитывающие около шести коммитов.

Итак, чтобы вернуть всю транзакцию, мне просто понадобился один git reset --hard HEAD^ , и он вернул все слияние. Поскольку слияния не были быстро перенаправлены, слияние было блоком и одним шагом назад является "ветвь не объединена".

Ответ 16

Вы можете использовать только две команды для возврата слияния или перезапуска с помощью определенной фиксации:

git reset --hard commitHash (вы должны использовать фиксацию, которую хотите перезапустить, например, 44a587491e32eafa1638aca7738)
git push origin HEAD --force (Отправка новой локальной ведущей ветки в начало/мастер)

Ответ 17

Самый простой ответ - тот, который дается odinho - Velmont

Сначала сделайте git reset --merge ORIG_HEAD

git push origin HEAD --force

Это будет reset таким образом, что вы не получите объединенные изменения обратно после нажатия.

Ответ 18

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

Например, я случайно объединил ветку разработки в мастер и хотел ее отменить. Используя следующие шаги:

Voila! Мастер находится на той же стадии, что и происхождение, и ваше неправильно объединенное состояние стирается.

Ответ 19

Если вам требуется решение из командной строки, я предлагаю просто пойти с ответом MBO.

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

Отключить gitk (из командной строки или щелкнуть правой кнопкой мыши в браузере файлов, если у вас есть)
Вы можете легко определить фиксацию слияния - первый node сверху с двумя родителями
Следуйте ссылке на первый/левый родитель (тот, который находится в вашей текущей ветке до слияния, обычно красный для меня)
В выбранном коммите щелкните правой кнопкой мыши раздел "Reset", выберите жесткий reset там

Ответ 20

Стратегия: Создайте новую ветку, откуда все было хорошо.

Обоснование: Возвращение слияния сложно. Слишком много решений, в зависимости от многих факторов, таких как то, что вы совершили или нажали ваше слияние, или были новые коммиты с момента вашего слияния. Также вам необходимо иметь относительно глубокое понимание git, чтобы адаптировать эти решения к вашему делу. Если вы слепо следуете некоторым инструкциям, вы можете получить "пустые слияния", где ничто не будет объединено, а дальнейшие попытки слияния сделают git сказать вам "Уже обновлено".

Решение:

Предположим, вы хотите объединить dev в feature-1 .

Найдите версию, которую хотите получить слияние:

Проверьте это (вернитесь назад):

Создайте новую ветку и проверьте ее:

Теперь вы можете перезапустить слияние:

Объединить: git merge dev

Исправьте конфликты слияния.

Commit: git commit

Когда вы удовлетворены результатами, удалите старую ветку: git branch --delete feature-1

Ответ 21

Вы должны изменить свою ГОЛОВУ, Не свою, конечно, но мерзавца ГОЛОВУ.

Поэтому, прежде чем ответить, давайте добавим некоторую предысторию, объясняющую, что это HEAD .

HEAD - это просто ссылка на текущий коммит (последний) в текущей ветке.
В любой момент времени может быть только один HEAD . (исключая git worktree )

Содержимое HEAD хранится внутри .git/HEAD и содержит 40 байтов SHA-1 текущего коммита.

Если вы не используете последний коммит - это означает, что HEAD указывает на предыдущий коммит в истории, он называется detached HEAD .

В командной строке он будет выглядеть как this- SHA-1 вместо имени ветки, поскольку HEAD не указывает на конец текущей ветки

Несколько вариантов восстановления после отсоединения HEAD:

git checkout

Это извлечет новую ветку, указывающую на желаемый коммит.
Эта команда вернется к данному коммиту.
На этом этапе вы можете создать ветку и начать работать с этого момента.

git reflog

Вы также всегда можете использовать reflog .
git reflog отобразит любое изменение, которое обновило HEAD , а проверка нужной записи журнала повторного вызова вернет HEAD к этой фиксации.

Каждый раз, когда заголовок изменяется, в reflog будет добавляться новая запись

Это вернет вас к желаемой фиксации

git reset --hard <commit_id>

"Переместите" ГОЛОВУ назад к желаемому коммиту.

Примечание: (начиная с Git 2.7)
Вы также можете использовать git rebase --no-autostash .

git revert <sha-1>

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

Эта схема иллюстрирует, какая команда что делает.
Как вы можете видеть, reset && checkout модифицирует HEAD .

Ответ 22

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

Ответ 23

Это можно сделать несколькими способами.

1) Прервать слияние

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

2) Сбросить HEAD в удаленную ветку

Если вы работаете с удаленной веткой разработки, вы можете сбросить HEAD до последнего коммита в удаленной ветке, как показано ниже:

3) Удалить текущую ветку и снова оформить заказ из удаленного репозитория

Учитывая, что вы работаете над веткой разработки в локальном репозитории, которая синхронизируется с удаленной веткой/веткой разработки, вы можете сделать следующее:

Ответ 24

Ответ 25

Во-первых, убедитесь, что вы все сделали.

Затем reset ваш репозиторий в предыдущее рабочее состояние:

или используя --hard (, это приведет к удалению всех локальных, не зафиксированных изменений!):

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

Проверьте, какие коммиты вы хотите перехватить в верхней части предыдущей правильной версии:

Примените свои права на верхнюю часть нужной версии вашего репозитория:

Используя вишневый выбор (изменения, внесенные некоторыми существующими коммитами)

Или путем выбора вишней диапазона значений:

Сначала проверьте правильные изменения перед их объединением:

где это диапазон правильных коммитов, которые вы совершили (за исключением ошибочно зафиксированного слияния).

Ответ 26

Если вы совершили слияние:

Ответ 27

Ответ 28

Самый простой из простейших шансов, гораздо проще, чем что-либо, сказанное здесь:

Удалите локальную ветвь (локальную, а не удаленную) и потяните ее снова. Таким образом, вы отмените изменения в своей основной ветке, и на кого-либо повлияет изменение, которое вы не хотите нажимать. Запустите его.

Ответ 29

В этом случае вы захотите сбросить свою ветку с помощью git reset --hard <branch_name> . Если вы хотите сохранить свои изменения перед их реестром, обязательно создайте новую ветку и git checkout <branch_name> .

Вы можете сбросить состояние до определенного коммита с помощью git reset --hard <commit_id> .

Если изменения были git revert <branch_name> вы можете использовать git revert <branch_name> вместо git revert <branch_name> . Обязательно ознакомьтесь с тем, как использовать git revert и git checkout в других сценариях.

git revert <commit_hash> один не будет работать. -m должен быть указан, и я довольно смущен этим.

Кто-нибудь испытывал это раньше?

Ссылка здесь - лучший пример, который иллюстрирует возврат объединенного коммита: christianengvall.se/undo-push-merge-git Это пример того, где дизайн git не соответствует git-flow рабочему процессу -ish, который все используют. Если вы сделали develop это, вы, конечно , хотите вернуть ветку 2-коммитов, в которой появилась ошибка, а не ветка с общим временем разработки. Чувствует себя нелепо, когда его нужно выбрать -m 1 . Еще одно предложение, которое мне никогда не приходило в голову - если один из списков коммитов веток мал, вам может быть удобнее возвращать отдельные коммиты вместо целой ветви коммитов.

-m Параметр определяет родительский номер . Это потому, что коммит слияния имеет более одного родителя, и Git не знает автоматически, какой родитель был основной линией, и какой родитель был ветвью, которую вы хотите удалить.

Когда вы просматриваете коммит слияния в выводе git log , вы увидите его родителей в строке, которая начинается с Merge :

В этой ситуации, git revert 8f937c6 -m 1 вы получите дерево, как оно было 8989ee0 , и git revert -m 2 восстановите дерево, как оно было 7c6b236 .

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

из двух чисел 8989ee0 , 7c6b236 какой из них идти. Как бы я понял? @ArupRakshit, если вы запускаете, git log 8989ee0 и git log 7c6b236 вы должны знать ответ. git log - объединяет для просмотра всех слияний и git log --no-merges для просмотра истории без слияний. Слияние ветки приводит историю слитой ветки к цели и

Вот полный пример в надежде, что это кому-то поможет:

Где <commit-hash> находится хеш коммита слияния, который вы хотели бы вернуть, и, как указано в пояснении к этому ответу , -m 1 указывает, что вы хотите вернуться к дереву первого родителя до слияния.

git revert . Линия по существу совершает изменения в то время как вторая линия делает ваши изменения общественности, вставив их в удаленный филиал.

Я полагал, что git revert команда уже передала созданный объект коммита. Чтобы этого не произошло, вам нужно будет ввести --no-commit флаг Как упомянул @Delfic, коммит уже управляется первой строкой (мне нужно было: wq для его проверки), поэтому вторая строка не нужна. это смущает. там только 2 строки и нет git commit .. может кто-нибудь пожалуйста отредактировать.

Бен рассказал вам, как отменить коммит слияния, но очень важно, чтобы вы понимали, что при этом

«. объявляет, что вы никогда не захотите изменений дерева, внесенных слиянием. В результате, последующие слияния будут вносить только изменения дерева, внесенные коммитами, которые не являются предками ранее отмененного слияния. Это может или не может быть что вы хотите. " (страница справочника git-merge) .

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

Вы можете выполнить эти шаги, чтобы отменить неправильные коммиты или вернуть удаленную ветвь обратно в правильный HEAD / состояние.

скопировать хеш коммита (т.е. идентификатор коммита непосредственно перед неправильным коммитом) из журнала git git log -n5

вывод:

commit 7cd42475d6f95f5896b6f02e902efab0b70e8038 «Слить ветвь« неправильная фиксация »в« развитие »»
commit f9a734f8f44b0b37ccea769b9a2fd774c0f0c012 «это неправильный
коммит»

сбросить ветку на хеш коммита, скопированный на предыдущем шаге
git reset <commit-hash> (i.e. 3779ab50e72908da92d2cfcd72256d7a09f446ba)

Что, если за это время 20 разработчиков вытащили последнее слияние разработчиков? Я бы не стал форсировать ветку разработки, когда в команде используется 20 разработчиков. :) В этом случае разумно просто сделать возврат. Это очень хорошее решение, когда вы работаете самостоятельно или уверены, что другие разработчики не потянули коммиты, которые вы испортили В этом ответе недостаточно деталей. Может быть, поэтому это хорошо.

Чтобы сохранить журнал в чистоте, так как ничего не произошло (с некоторыми недостатками при таком подходе (из-за нажатия -f)):

'commit-hash-before-merge' приходит из журнала (git log) после слияния.

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

Иногда самый эффективный способ отката - сделать шаг назад и заменить.

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

git checkout -b newbranch <HASH>

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

Если он был передан, то удалите старую ветку из всех репозиториев, переместите переделанную ветвь в самую центральную и отведите ее обратно ко всем.

Предупреждение о трансляции должно быть более ясным о том, насколько ужасна эта идея. Это повредит все версии этой ветки и будет действительно полезным, только если вы работаете с удаленным репозиторием (github / bitbucket), к которому только у вас есть доступ. Не так плохо, как отправка измененных файлов конфигурации в поток. Он не будет поврежден, это просто переопределение предыдущей фиксации, так что это обходной способ переместить указатель веток на более раннюю версию. Надеюсь, это

Если вы хотите отменить merge коммит, вот что вам нужно сделать.

Сначала проверьте, git log чтобы найти идентификатор вашего слияния. Вы также найдете несколько родительских идентификаторов, связанных с объединением (см. Изображение ниже).

Запишите идентификатор фиксации слияния, показанный желтым цветом. Родительские идентификаторы - это те, которые записаны в следующей строке как Merge: parent1 parent2 . Сейчас же.

Переключитесь на ветку, на которой было произведено слияние. В моем случае это test ветка, и я пытаюсь удалить feature/analytics-v3 из нее ветку.

git revert это команда, которая отменяет любой коммит Но при отмене merge коммита есть неприятный трюк . Вам нужно ввести -m флаг, иначе он не удастся. С этого момента вам необходимо решить, хотите ли вы вернуть свою ветку и сделать так, чтобы она выглядела именно так, как она была, parent1 или parent2 через нее :

git revert <merge commit id> -m 1 (возвращается к parent2 )

git revert <merge commit id> -m 2 (возвращается к parent1 )

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

Все ответы уже охватывали большинство вещей, но я добавлю свои 5 центов. Короче говоря, отменить коммит слияния довольно просто:

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

Скажем, ветвь кода, которую вы объединили в master, была mycodebranch.

Оформить заказ мастеру.
Создайте полное двоичное обратное исправление между мастером и резервной копией. git diff --binary master..master_bk_01012017 >

Правильно отмеченный ответ сработал для меня, но мне пришлось потратить некоторое время, чтобы определить, что происходит .. Поэтому я решил добавить ответ с простыми простыми шагами для случаев, подобных моему ..

Допустим, у нас есть ветви A и B .. Вы слили ветвь A в ветвь B и подтолкнули ветвь B к себе, так что теперь слияние является частью этого . Но вы хотите вернуться к последнему коммиту перед слиянием .. Что делать вы делаете?

Перейдите в корневую папку вашего git (обычно это папка проекта) и используйте git log

Вы увидите историю последних коммитов - коммиты имеют свойства commit / author / date, а слияния также имеют свойство merge - так что вы видите их так:

commit: <commitHash> Merge: <parentHashA> <parentHashB> Author: <author> Date: <date>

Используйте git log <parentHashA> и git log <parentHashB> - вы увидите истории коммитов этих родительских веток - первые коммиты в списке самые последние

Я также столкнулся с этой проблемой на PR, который был объединен с главной веткой репозитория GitHub.

Так как я только хотел изменить некоторые измененные файлы , но не целые изменения ПР принесло, я должен был с . amend merge commit git commit --am

шаги:

Перейдите в ветку, в которую вы хотите изменить / отменить некоторые измененные файлы.
Сделайте необходимые изменения в соответствии с измененными файлами
запустить git add * или git add <file>
запустить git commit --am и проверить
запустить git push -f

Почему это интересно:

Сохраняет фиксацию автора PR без изменений
Это не ломает мерзкое дерево
Вы будете помечены как коммиттер (автор коммитов слияния останется без изменений)
Git действует так, как будто вы разрешаете конфликты, он удаляет / изменяет код в измененных файлах, как если бы вы вручную указали GitHub не объединять его как есть.

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

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

История сразу после «возврата к слиянию» будет выглядеть так:

где A и B находятся на стороне развития, которая была не очень хорошей, M - это слияние, которое вносит эти преждевременные изменения в основную линию, x - это изменения, не связанные с тем, что боковая ветвь сделала и уже сделала на основной линии, а W - это " возврат слияния М "(разве W не смотрит на М с ног на голову?). IOW, "diff W ^ .. W" похож на "diff -RM ^ .. M".

Такой «возврат» слияния может быть сделан с помощью:

$ git revert -m 1 M После того, как разработчики боковой ветки исправят свои ошибки, история может выглядеть так:

Если вы объедините обновленную боковую ветвь (с D на кончике), ни одно из изменений, сделанных в A или B, не будет в результате, потому что они были отменены W. Это то, что Алан видел.

Линус объясняет ситуацию:

Отмена обычного коммита просто эффективно отменяет то, что сделал этот коммит, и довольно проста. Но возвращение коммита слияния также отменяет данные, которые коммит изменил, но это абсолютно не влияет на историю, которую слияние имело. Таким образом, слияние все еще будет существовать, и оно все равно будет рассматриваться как объединение двух ветвей, и будущие слияния будут видеть, что слияние является последним общим состоянием - и обратный процесс, который отменил введенное слияние, не повлияет на это вообще. Таким образом, «возврат» отменяет изменения данных, но это очень не«отмена» в том смысле, что она не отменяет влияния коммита на историю репозитория. Так что если вы думаете о «возврате» как об «отмене», то вы всегда будете пропускать эту часть возвратов. Да, это отменяет данные, но нет, это не отменяет историю. В такой ситуации вы бы хотели сначала вернуть предыдущий возврат, что бы история выглядела следующим образом:

где Y - это возврат к W. Такой «возврат к возврату» можно сделать с помощью:

$ git revert W Эта история (игнорируя возможные конфликты между изменениями W и W..Y) будет эквивалентна отсутствию W или Y в истории:

и повторное объединение боковой ветви не приведет к конфликту, связанному с более ранним возвратом и восстановлением возврата.

Конечно, изменения, сделанные в C и D, все еще могут конфликтовать с тем, что было сделано любым из x, но это обычный конфликт слияния.

на основе некоторых инструкции я не нашел, я пробовал использовать

Я не хочу, чтобы моя ветка была впереди на любое количество коммитов. Как мне получить вернуться к тому моменту?

С git reflog проверьте, какая фиксация является одной до слияния (git reflog будет лучшим вариантом, чем git log ). Затем вы можете сбросить его, используя:

есть и другой способ

вернет вам 1 фиксацию.

имейте в виду, что любые измененные и незафиксированные/unstashed файлы будут сброшены в их неизмененное состояние. Чтобы сохранить их либо stash изменения прочь или увидеть ниже.

Как @Velmont предложил ниже в своем ответе, в этом прямом случае используя:

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

еще один совет-использовать --merge переключатель вместо --hard поскольку он не сбрасывает ненужные файлы:

--merge

сбрасывает индекс и обновляет файлы в рабочее дерево, которое отличается между и HEAD, но сохраняет те, которые отличаются между индексом и рабочим деревом (т. е. имеют изменения, которые не были добавлены).

предполагая, что ваш местный мастер не опередил origin / master, вы должны быть в состоянии сделать

ваш местный master ветка должна выглядеть идентично origin/master .

отменить слияние это уже было нажато:

обязательно верните возврат, если вы снова фиксируете ветку, как сказал Лайнус.

ref ORIG_HEAD будет указывать на исходную фиксацию до слияния.

(том --merge опция не имеет ничего общего с слиянием. Это так же, как git reset --hard ORIG_HEAD , но безопаснее, так как он не касается незафиксированных изменений.)

С более новыми версиями Git, если вы еще не совершили слияние и у вас есть конфликт слияния, вы можете просто сделать:

С man git merge :

[This] можно запустить только после того, как слияние привело к конфликтам. git merge --abort прервет процесс слияния и попытается восстановить состояние, предшествующее слиянию.

вы должны сбросить предыдущую фиксацию. Это должно сработать:

или даже HEAD^^ для возврата этой фиксации возврата. Вы всегда можете дать полную ссылку SHA, если вы не уверены, сколько шагов назад вы должны предпринять.

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

в последнее время я использую git reflog , чтобы помочь с этим. Это в основном работает, только если слияние просто произошло, и это было на вашем компьютере.

git reflog может вернуть что-то вроде:

первая строка указывает, что произошло слияние. Вторая строка-это время до моего слияния. Я просто git reset --hard 43b6032 чтобы заставить эту ветку отслеживать до слияния и продолжить.

С современным Git, вы можете:

но на самом деле, стоит заметить, что git merge --abort только эквивалентно git reset --merge учитывая, что MERGE_HEAD присутствует. Это можно прочитать в команде git help for merge.

после неудачного слияния, когда нет MERGE_HEAD , неудачное слияние можно отменить с помощью git reset --merge , но не обязательно git merge --abort , так они не только старый и новый синтаксис для одного и того же.

лично мне git reset --merge гораздо более мощный и полезный в повседневной работе, так что это тот, который я всегда использую.

хорошо, ответы, которые дали мне другие люди, были близки, но это не сработало. Вот что я сделал.

. дал мне следующий статус.

короче говоря, мои команды сводились к следующему:

можно использовать git reflog найти предыдущий заказ. Иногда это хорошее состояние, в которое хочется вернуться.

Если вы еще не зафиксировали его, вы можете использовать только

он отменит слияние (и все, что вы сделали).

Я просто прочитал эту страницу, поскольку я случайно объединил ветку тестирования вместо моей ветви выпуска с master для развертывания (веб-сайт, master-это то, что живет). Ветвь тестирования имеет две другие ветви, объединенные с ней и итоговые около шести коммитов.

поэтому, чтобы вернуть всю фиксацию, мне просто нужен был один git reset --hard HEAD^ и он вернул все слияние. Поскольку слияния не были быстро перенаправлены, слияние было блоком, а один шаг назад - "ветвь не объединена".

вы можете использовать только две команды для возврата слияния или перезапуска с помощью определенной фиксации:

git reset --hard commitHash (вы должны использовать фиксацию, которую хотите перезапустить, например. 44a587491e32eafa1638aca7738)
git push origin HEAD --force (отправка новой локальной главной ветви в origin / master)

добрался до этого вопроса, также желая вернуться к совпадению origin (т. е. никаких коммитов впереди origin). Исследуя дальше, обнаружил, что есть reset команда именно для этого:

Примечание: @ сокращенно от origin/master . (И, конечно же, вам нужно, чтобы этот удаленный репозиторий работал.)

самый простой ответ к odinho - Вельмонт

сначала git reset --merge ORIG_HEAD

для тех, кто хочет сбросить после нажатия изменений, сделайте это (Потому что это первый пост, увиденный для любых вопросов слияния сброса git)

git push origin HEAD --force

это будет сброшено таким образом, что вы не получите объединенные изменения снова после вытягивания.

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

например, я случайно объединил ветку разработки в master и хотел отменить это. Используя следующие шаги:

вуаля! Мастер находится на той же стадии, что и origin, и Ваше неправильно объединенное состояние стирается.

Если вы хотите решение командной строки, я предлагаю просто пойти с ответом MBO.

Если вы новичок, вам может понадобиться графический подход:

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

стратегия: создайте новую ветку, из которой все было хорошо.

обоснование: возврат слияния трудно. Существует слишком много решений, в зависимости от многих факторов, таких как ли вы совершили или толкнули слияние или если были новые коммиты с момента слияния. Кроме того, вам все равно нужно иметь относительно глубокое понимание git, чтобы адаптировать эти решения к вашему случаю. Если вы слепо следуете некоторым инструкциям, вы можете получить " пустой слияние", где ничего не будет объединено, и дальнейшие попытки слияния заставят Git сказать вам "уже в курсе".

устранение:

предположим, вы хотите объединить dev на feature-1 .

найдите редакцию, которую вы хотите получить слияние:

зацени (вернуться в прошлое):

создать новую ветку и проверить его out:

теперь вы можете перезапустить слияние:

слияние: git merge dev

исправьте конфликты слияния.

Commit: git commit

когда вы будете удовлетворены результатами, удалите старую ветку: git branch --delete feature-1

я смог решить эту проблему с помощью одной команды, которая не требует поиска идентификатора фиксации.

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

Я думаю, вы можете сделать git rebase -i [hash] [branch_name] здесь [hash] - это идентифицирующий хэш для того, как далеко вы хотите перемотать назад плюс один (или сколько коммитов вы хотите вернуться), а затем удалить строки для коммитов в Редакторе, которые вы больше не хотите. Сохранить файл. Выход. Молиться. И его нужно перемотать. Возможно, вам придется сделать git reset --hard , но это должно быть хорошо на данный момент. Вы также можете использовать это для извлечения определенных коммитов из стека, если вы не хотите хранить их в своей истории, но это может оставить ваш репозиторий в состоянии, которое вы, вероятно, не хотите.

во-первых, убедитесь, что вы совершили все.

затем сбросьте репозиторий в предыдущее рабочее состояние:

или через --hard (это удалит все локальные, не зафиксированные изменения!):

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

проверьте, какие коммиты вы хотели бы повторно совершить поверх предыдущего правильного версия:

примените свои правые коммиты в верхней части правой версии вашего репозитория по:

С помощью cherry-pick (изменения, внесенные некоторыми существующими коммитами)

или cherry-picking диапазон коммитов по:

сначала проверьте правильные изменения перед их объединением:

первая проверка правые изменения перед их объединением:

где это диапазон правильных коммитов, которые вы совершили (исключая ошибочно Совершенное слияние).

если вы заметили, что вам нужно вернуться сразу после слияния, и вы ничего не сделали после попытки слияния, вы можете просто выполнить эту команду: git reset --hard HEAD@ .

по сути, слияние sha будет указывать на HEAD@ Если после слияния ничего не было зафиксировано и так HEAD@ будет предыдущей точкой перед слиянием.

самый простой из самых простых шансов, гораздо проще, чем все, что здесь сказано:

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

Если вы совершили слияние:

в этом случае вы захотите сбросить свою ветку с git reset --hard <branch_name> . Если вы хотите сохранить изменения перед их сбросом, обязательно создайте новую ветку и git checkout <branch_name> .

вы можете сбросить состояние до определенной фиксации с помощью git reset --hard <commit_id> Как хорошо.

если изменения были нажаты, вы можете использовать . Не забудьте проверить, как использовать git revert и git checkout в других случаях, а также.

вы можете использовать команду git-reset.

git-reset-сброс текущей головки на

указанное состояние. git reset [--mixed/

--soft / --hard / --merge] [- q] [] сброс git [- q] []

[--] . git reset --patch

[] [--] [. ]

Мы всегда готовы подчеркивать бесчисленные возможности, которые предлагает Git, и эта статья не станет исключением. Git известен своей потрясающей способностью отменять практически любые действия! Наверняка на память вам уже приходят тысячи печальных случаев, когда вы делали объединение, а потом понимали, что в ваши планы оно не входило. Даже если вам кажется, что ошибочное объединение— это величайшая неудача всей вашей жизни, сделайте глубокий вдох и дочитайте статью до конца.

Од и н из самых распространенных вопросов в сообществе Git звучит так: “Как откатить git add перед коммитом?” Вы можете отменить действия над конкретным файлом или все внесенные изменения.

Решение, которое потребуется для этого, весьма простое. Чтобы откатить один файл, просто вызовите команду git reset :

Для отмены всех изменений запустите следующее:

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

Здесь на помощь приходит еще одна команда класса “отмена”: git revert . Начнем с того, что переключимся на мастер-ветку, используя команду git checkout :

Следующий шаг — запустить команду git log , чтобы получить ID сделанного объединения:

Затем вернитесь к упомянутому коммиту, выполнив следующее:

Используя -m 1 , вы даете Git указание: вернуться к первому родительскому элементу мастер-ветки, куда был совершен коммит объединения. Например, использование -m 2 сказало бы Git вернуться к первому родительскому элементу ветки, откуда пришел запрос на объединение.

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

Предлагаем суперкороткий способ отменить команду git reset:

Следом можно запустить команду git reflog , чтобы просмотреть журнал всех обновлений (т.е. переключение веток, сброс, коммит, объединение).

Существует несколько методов для отмены git commit . Давайте рассмотрим их по очереди.

Команду git reset можно использовать для отмены внесенных изменений:

x введите число. Например, если вы укажете

4 , то команда повлияет на четвертый снизу коммит. Если вы не укажете никакое конкретно число, git reset — soft HEAD применится к последнему коммиту.

Когда вы используете команду git reset — soft HEAD , то просто отменяете последний коммит, при этом внесенные изменения останутся в вашем рабочем дереве и в вашем индексе. Поэтому git commit создаст в будущем коммит с теми же самыми изменениями, которые вы “обнулили” перед этим.

Другой метод — это команда git revert HEAD

x ( git reset — hard commit hash ), которая отменяет изменения, указанные последним коммитом в HEAD , и создает новый с возвращенными изменениями:

Этот метод лучше всего работает в случае с общими публичными репозиториями.

Допустим, вы выполнили команду git rebase в локальной ветке git и отправили ее в удаленную ветку. Следом вы поняли, что это не отвечает вашим ожиданиям, и захотели отменить сделанное.

Самый простой способ — найти главный коммит вашей ветки, запустив команду:

Следом необходимо установить туда текущую ветку, воспользовавшись git reset .

В данном случае старым коммитом был HEAD5 .

Вот и все о том, как вы можете отменить наиболее часто используемые команды в Git. Хоть никакой традиционной команды отмены и нет, другие команды git могут помочь вам откатить то, что вы могли сделать по ошибке.

Читайте также: