Git как отменить слияние: Отменить Git merge, который еще не был нажат

Содержание

Отменить Git merge, который еще не был нажат

В моей главной ветви я сделал git merge some-other-branch локально, но никогда не продвигал изменения в origin master. Я не хотел сливаться, поэтому я хотел бы отменить это. Когда я делал git status после моего слияния, я получал это сообщение:

# On branch master
# Your branch is ahead of 'origin/master' by 4 commits.

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

git revert HEAD -m 1

но теперь я получаю это сообщение с git status :

# On branch master
# Your branch is ahead of 'origin/master' by 5 commits.

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

git

undo

git-merge

Поделиться

Источник

Matt Huggins

05 марта 2010 в 19:24

25 ответов

Отменить merge, который был нажат
Ладно, я устроил небольшой беспорядок. По-видимому, на моей машине дома ветка разработки не обновлялась. Я взял на себя обязательство и нажал. В результате фактическая ветвь origin/Development была объединена в мою локальную ветвь Development , которая по какой-то причине рассматривалась как…
Как я могу отменить merge, который не производит фиксацию(коммит) merge?
Я создал экспериментальную ветвь от мастера и сделал четыре коммита на экспериментальной ветви. Тем временем мастер все еще остается там, где был в последний раз. Теперь я хочу merge свою экспериментальную ветвь таким образом,чтобы в будущем я мог легко отменить эту merge. Когда я пробовал искать,…

4598

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

git reset --hard commit_sha

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

git reset --hard HEAD~1

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

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

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

git reset --hard ORIG_HEAD

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

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

git reset --merge ORIG_HEAD

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

Поделиться

Marcin Gil

05 марта 2010 в 19:34

1484

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

git reset --hard origin/master

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

Поделиться

randomguy3

17 марта 2011 в 18:06

Поделиться

Yuri Geinish

02 июня 2011 в 16:31

1006

Странно, что не хватало самой простой команды. Большинство ответов работают, но отмена слияния, которое вы только что сделали, — это простой и безопасный способ :

git reset --merge ORIG_HEAD

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

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

Поделиться

odinho — Velmont

29 января 2013 в 15:46

401

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

git merge --abort

От man git merge :

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

Поделиться

Travis Reeder

12 февраля 2013 в 02:13

141

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

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

Поделиться

MBO

05 марта 2010 в 19:31

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

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

fbb0c0f HEAD@{0}: commit (merge): Merge branch 'master' into my-branch
43b6032 HEAD@{1}: checkout: moving from master to my-branch
e3753a7 HEAD@{2}: rebase finished: returning to refs/heads/master
e3753a7 HEAD@{3}: pull --rebase: checkout e3753a71d92b032034dcb299d2df2edc09b5830e
b41ea52 HEAD@{4}: reset: moving to HEAD^
8400a0f HEAD@{5}: rebase: aborting

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

Поделиться

Parris

19 декабря 2014 в 17:51

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

git merge --abort

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

git reset --merge

Старая школа:

git reset --hard

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

git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.

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

Поделиться

Matt Huggins

05 марта 2010 в 19:54

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

Конкретно,

$ git reflog
$ git reset --hard HEAD@{0}

Поделиться

stephjang

17 января 2014 в 22:36

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

Поделиться

llioor

13 декабря 2018 в 14:05

Вы должны изменить свой HEAD, не ваш, конечно, но git HEAD.…

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

HEAD -это просто ссылка на текущий коммит (последний) в текущей ветви.

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

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

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

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

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

git checkout

git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back

Это приведет к проверке новой ветви, указывающей на желаемую фиксацию(коммит).

Эта команда выполнит проверку на заданную фиксацию(коммит).

На этом этапе вы можете создать ветку и начать работать с этого момента.

# Checkout a given commit. 
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>

# create a new branch forked to the given commit
git checkout -b <branch name>

git reflog

Вы также всегда можете использовать reflog .

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

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

git reflog
git checkout HEAD@{...}

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

git reset --hard <commit_id>

«Move» ваш HEAD возвращается к нужной фиксации(коммита).

# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts if you've modified things which were
# changed since the commit you reset to.

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

git revert <sha-1>

«Undo» данной совершению или совершить выбор.

Команда reset будет «undo» любые изменения, внесенные в данную фиксацию(коммит).

Новая фиксация(коммит) с исправлением отмены будет зафиксирована, в то время как исходная фиксация(коммит) также останется в истории.

# add new commit with the undo of the original one. 
# the <sha-1> can be any commit(s) or commit range
git revert <sha-1>

Эта схема иллюстрирует, какая команда что делает.

Как вы можете видеть, там reset && checkout модифицирует HEAD .

Поделиться

CodeWizard

31 июля 2019 в 15:38

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

git reset --hard remotes/origin/HEAD

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

Поделиться

Ralph Ritoch

25 июля 2018 в 09:55

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

$ git checkout -f

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

Поделиться

Idealmind

18 января 2013 в 15:25

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

git reset --hard @{u}

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

Поделиться

leanne

16 февраля 2017 в 21:54

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

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

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

git merge --abort

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

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

git reset --hard origin/develop

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

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

git checkout master 
##to delete one branch, you need to be on another branch, otherwise you will fall with the branch :) 

git branch -D develop
git checkout -b develop origin/develop

Поделиться

Amit Kaneria

25 июля 2019 в 15:06

Самый простой ответ — это тот, который дал одинью- Вельмон

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

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

git push origin HEAD --force

Это приведет к сбросу таким образом, что вы не получите объединенные изменения обратно после вытягивания. , и он вернул все слияние. Поскольку слияния не были быстро переадресованы, слияние было блоком, а один шаг назад-«branch not merged».

Поделиться

Damien Byrne

09 июня 2011 в 00:54

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

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

Удачи и вперед!

Поделиться

Matheus Abreu

12 декабря 2014 в 23:16

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

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

git checkout develop
git branch -D master
git branch -t master origin/master

Вуаля! Мастер находится на той же стадии, что и источник, и Ваше неверно слитое состояние стирается.

Поделиться

Stephan

26 июня 2012 в 11:15

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

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

Kick off gitk (из командной строки или щелкните правой кнопкой мыши в файловом браузере, если у вас есть это)
Вы можете легко обнаружить коммит слияния там — первый узел сверху с двумя родителями
Перейдите по ссылке на первый/левый родитель (тот, который находится в вашей текущей ветви перед слиянием, обычно красный для меня)
На выбранном коммите щелкните правой кнопкой мыши «Reset branch to here», выберите hard reset there

Поделиться

inger

21 марта 2013 в 14:38

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

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

Решение:

Допустим, вы хотите объединить dev в feature-1 .

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

git log --oneline feature-1
a1b2c3d4 Merge branch 'dev' into 'feature-1' <-- the merge you want to undo
e5f6g7h8 Fix NPE in the Zero Point Module <-- the one before the merge, you probably want this one

Проверьте это (вернитесь в прошлое):
```
git checkout e5f6g7h8
```
Создайте новую ветку оттуда и проверьте ее:
```
git checkout -b feature-1
```

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

Слияние: git merge dev
Исправьте конфликты слияний.
Фиксация(коммит): git commit
Когда вы будете удовлетворены результатами, удалите старую ветвь: git branch --delete feature-1

Поделиться

pyb

11 июня 2015 в 15:42

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

Его экономия и проще, чем сброс, описанный во многих ответах выше

Поделиться

gdbdable

15 августа 2019 в 13:41

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

Поделиться

tychoish

08 марта 2010 в 02:55

Во-первых, убедитесь, что вы все сделали правильно.
Затем сбросьте свой репозиторий в предыдущее рабочее состояние:
```
$ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36
```
или с помощью --hard ( это удалит все локальные, не зафиксированные изменения! ):
```
$ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36 --hard
```
Используйте hash, который был там до вашего ошибочно объединенного коммита.
Проверьте, какие коммиты вы хотели бы повторно зафиксировать в верхней части предыдущей правильной версии, выполнив следующие действия::
```
$ git log 4c3e23f529b581c3cbe95350e84e66e3cb05704f

commit 4c3e23f529b581c3cbe95350e84e66e3cb05704f

...

commit 16b373a96b0a353f7454b141f7aa6f548c979d0a

...
```
Примените ваши правые коммиты в верхней части правой версии вашего репозитория с помощью:
- С помощью cherry-pick (изменения, внесенные некоторыми существующими коммитами)
```
    git cherry-pick ec59ab844cf504e462f011c8cc7e5667ebb2e9c7
```
- Или путем подбора вишневого ряда коммитов по:
  - Сначала проверьте правильные изменения перед их объединением:
```
git diff 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704f
```
  - Сначала проверьте правильные изменения перед их объединением:
```
git cherry-pick 5216b24822ea1c48069f648449997879bb49c070. .4c3e23f529b581c3cbe95350e84e66e3cb05704f
```
    где это диапазон правильных коммитов, которые вы совершили (исключая ошибочно Совершенное слияние).

Поделиться

kenorb

29 января 2013 в 15:09

Как отменить коммит слияния, который уже передан в удаленную ветку?

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

Как отменить ошибочное слияние,
Алан ([email protected]) сказал:

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

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

---o---o---o---M---x---x---W
              /
      ---A---B

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

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

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

---o---o---o---M---x---x---W---x
              /
      ---A---B-------------------C---D

где C и D должны исправить то, что было сломано в A и B, и у вас уже могут быть некоторые другие изменения в магистрали после W.

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

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

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

---o---o---o---M---x---x---W---x---Y
              /
      ---A---B-------------------C---D

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

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

---o---o---o---M---x---x-------x----
              /
      ---A---B-------------------C---D

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

---o---o---o---M---x---x-------x-------*
              /                       /
      ---A---B-------------------C---D

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

Как отменить мерж файлов и как разрешать конфликты руками? — Хабр Q&A

Всем привет.

Пытаюсь разобраться с git. Предыстория примерно такая.

Получаю от клиента полный бэкап сайта в виде архива. Разворачиваю данный бэкап на своей площадке, запускаю сайт все ок.

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

Я делаю так в папке с развернутым сайтом на моей площадке:
$ init git
$ git remote add clientrepo https://username:[email protected]/Company/repo.git
$ git fetch
$ git checkout -t clientrepo/vetka
$ git status
$ git add .
$ git commit -m «start»

Потом вношу какие-то изменения в код.

$ git commit -m «finish»

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

$ git pull clientrepo vetka
$ git merge clientrepo/vetka

Вижу в консоли ошибку:
fatal: ‘merge’ is not possible because you have unmerged files.

Ввожу команду:
$ git status

Вижу в консоли секцию с записями new file: и секцию с both added:

В php-файлах проекта из секции both added: появились «комменты» вида, сайт, естественно сыпет ошибками из-за этих «комментов»:

<<<<<<< HEAD
code_one
=======
code_two
>>>>>>> ae235f459f0cc2d9108f051c5832b7d961f23127

Вопрос 1.
Если я захочу отменить слияние и вернуть все файлы проекта к состоянию, в котором они находились в момент создания коммита «finish», то какими командами я должен воспользоваться?

Вопрос 2.
Как разрешить имеющиеся конфликты? Какие действия и в какой последовательности я должен выполнить? Желательно инструкцию типа: заходим во все файлы из секции added both, в каждом файле затираем code_1, оставляем code_2, потом делаем .
git pull

git — Отменить слияние git, которое только что было отправлено, и повторить слияние

У меня было несколько локальных коммитов, и в мастер были внесены изменения. Итак, я сделал:

 git pull // it automatically merged and had a conflict with one file only.
 subl <file> // Made the wrong fix and saved it
 git commit // It opened nano and I Typed "fixed merge" saved it 
 git push master origin

Как мне вернуться к предыдущему запросу и повторить слияние и отправку? Особенно вернемся прямо перед слиянием.

IskandarG

2 Ноя 2016 в 11:39

2 ответа

Лучший ответ

Вы можете отменить это слияние с помощью:

git revert -m 1 (Commit id of the merge commit)

Дополнительную информацию можно найти в Официальное руководство

И вы можете сделать это по-другому, используя git reflog <branch>, чтобы узнать, где была ваша ветка до слияния, и git reset --hard <commit_id>, чтобы восстановить старую ревизию (вы вернетесь к этой фиксации). Тогда просто можешь push его вернуть.

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

Убедитесь, что вы находитесь в правильной ветке

Karol Gasienica
15 Ноя 2016 в 07:22

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

git revert HEAD

Он вернет вашу фиксацию как новую фиксацию

Khuong Dang
2 Ноя 2016 в 09:06

40375520

30. Разрешение конфликтов

Цели

Научиться разрешать конфликты во время слияния

01 Слияние master с веткой style

Теперь вернемся к ветке style и попытаемся объединить ее с новой веткой master.

Выполните:

git checkout style
git merge master

Результат:

$ git checkout style
Switched to branch 'style'
$ git merge master
Auto-merging lib/hello.html
CONFLICT (content): Merge conflict in lib/hello.html
Automatic merge failed; fix conflicts and then commit the result.

Если вы откроете lib/hello.html, вы увидите:

Файл:

lib/hello.html

<!-- Author: Alexander Shvets ([email protected]) -->
<html>
  <head>
<<<<<<< HEAD
    <link type="text/css" rel="stylesheet" media="all" href="style.css" />
=======
    <!-- no style -->
>>>>>>> master
  </head>
  <body>
    <h2>Hello,World! Life is great!</h2>
  </body>
</html>

Первый раздел — версия во главе текущей ветки (style). Второй раздел — версия ветки master.

02 Решение конфликта

Вам необходимо вручную разрешить конфликт. Внесите изменения в lib/hello.html для достижения следующего результата.

Файл:

lib/hello.html

<!-- Author: Alexander Shvets ([email protected]) -->
<html>
  <head>
    <link type="text/css" rel="stylesheet" media="all" href="style.css" />
  </head>
  <body>
    <h2>Hello, World! Life is great!</h2>
  </body>
</html>

03 Сделайте коммит решения конфликта

Выполните:

git add lib/hello.html
git commit -m "Merged master fixed conflict."

Результат:

$ git add lib/hello.html
$ git commit -m "Merged master fixed conflict."
Recorded resolution for 'lib/hello.html'.
[style 645c4e6] Merged master fixed conflict.

04 Расширенные возможности слияния

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

Основы ветвления и слияния | Pro Git

Давайте рассмотрим простой пример ветвления и слияния с таким процессом работы, который вы могли бы использовать в настоящей разработке. Вы будете делать следующее:

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

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

Вернётесь на производственную ветку.
2. Создадите ветку для исправления ошибки.
После его тестирования, сольёте ветку с исправлением и отправите в продакшн.
Переключитесь к прерванной истории и продолжите работу.

Основы ветвления

Для начала представим, что вы работаете над своим проектом и уже имеете пару коммитов (см. Рисунок 3-10).

Рисунок 3-10. Рисунок 3-10.

Вы решили, что вы будете работать над проблемой №53 из системы отслеживания ошибок, используемой вашей компанией. Разумеется, Git не привязан к какой-то определенной системе отслеживания ошибок. Просто из-за того, что проблема №53 является основной задачей, над которой вы хотите работать, вы создадите новую ветку для работы в ней. Чтобы создать ветку и сразу же перейти на неё, вы можете выполнить команду git checkout с ключом -b:

$ git checkout -b iss53 Switched to a new branch "iss53"

Это сокращение для:

$ git branch iss53 $ git checkout iss53

Рисунок 3-11 показывает результат.

Рисунок 3-11. Создание новой ветки / указателя

Во время работы над вашим веб-сайтом, вы делаете несколько коммитов. Эти действия сдвигают ветку iss53 вперёд потому, что вы на неё перешли (то есть ваш HEAD указывает на неё; см. Рисунок 3-12):

$ vim index.html $ git commit -a -m 'added a new footer [issue 53]'

Рисунок 3-12. Ветка iss53 передвинулась вперёд во время работы

Теперь вы получаете звонок о том, что есть проблема с веб-сайтом, которую необходимо немедленно устранить. С Git, вам нет нужды создавать заплатку вместе с теми изменениями, которые вы уже сделали для iss53. А также не надо прикладывать много усилий, чтобы отменить эти изменения перед тем, как вы сможете начать работать над решением срочной проблемы. Всё, что вам нужно сделать, это перейти на ветку master.

Однако, прежде чем сделать это, учтите, что если в вашем рабочем каталоге или индексе имеются незафиксированные изменения, которые конфликтуют с веткой, на которую вы переходите, Git не позволит переключить ветки. Лучше всего при переключении веток иметь чистое рабочее состояния. Существует несколько способов добиться этого (а именно, прятанье (stash) работы и правка (amend) коммита), которые мы рассмотрим позже. А на данный момент представим, что вы зафиксировали все изменения, и можете переключиться обратно на ветку master:

$ git checkout master Switched to branch "master"

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

Итак, вам надо срочно исправить ошибку. Давайте создадим для этого ветку, на которой вы будете работать (см. Рисунок 3-13):

$ git checkout -b 'hotfix' Switched to a new branch "hotfix" $ vim index.html $ git commit -a -m 'fixed the broken email address' [hotfix]: created 3a0874c: "fixed the broken email address" 1 files changed, 0 insertions(+), 1 deletions(-)

Рисунок 3-13. Ветка для решения срочной проблемы базируется на ветке master

Вы можете запустить тесты, убедиться, что решение работает, и слить (merge) изменения назад в ветку master, чтобы включить его в продукт. Это делается с помощью команды git merge:

$ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast forward README | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)

Наверное, вы заметили фразу “Fast forward” в этом слиянии. Так как ветка, которую вы сливали, указывала на коммит, являющийся прямым потомком коммита, на котором вы находитесь, Git передвигает указатель вперёд. Иными словами, когда вы пытаетесь слить один коммит с другим, который может быть достигнут идя по истории первого коммита, Git упрощает вещи, перемещая указатель вперёд, так как нету расходящихся изменений для слияния их воедино. Это называется “fast forward” (перемотка).

Ваши изменения теперь в снимке состояния коммита, на который указывает ветка master, и вы можете включить изменения в продукт (см. Рисунок 3-14).

Рисунок 3-14. После слияния ветка master указывает туда же, куда и ветка hotfix

После того, как очень важная проблема решена, вы готовы вернуться обратно к работе, которую делали, прежде чем были прерваны. Однако, сначала удалите ветку hotfix, так как она больше не нужна — ветка master уже указывает на то же место. Вы можете удалить ветку с помощью опции -d к git branch:

$ git branch -d hotfix Deleted branch hotfix (3a0874c).

Теперь вы можете вернуться обратно к рабочей ветке для проблемы №53 и продолжить работать над ней (см. Рисунок 3-15):

$ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' [iss53]: created ad82d7a: "finished the new footer [issue 53]" 1 files changed, 1 insertions(+), 0 deletions(-)

Рисунок 3-15. Ветка iss53 может двигаться вперёд независимо

Стоит напомнить, что работа, сделанная на ветке hotfix, не включена в файлы на ветке iss53. Если вам это необходимо, вы можете выполнить слияние ветки master в ветку iss53 посредством команды git merge master. Или же вы можете подождать с интеграцией изменений до тех пор, пока не решите включить изменения на iss53 в продуктовую ветку master.

Основы слияния

Представьте себе, что вы разобрались с проблемой №53 и готовы объединить эту ветку и свой master. Чтобы сделать это, вы выполните слияние вашей ветки iss53 в ветку master точно так же, как делали ранее с веткой hotfix. Все что вы должны сделать ― перейти на ту ветку, в которую вы хотите внести свои изменения и выполнить команду git merge:

$ git checkout master $ git merge iss53 Merge made by recursive. README | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)

Сейчас слияние выглядит немного не так, как для ветки hotfix, которое вы делали ранее. В данном случае ваша история разработки разделилась в некоторой точке. Так как коммит на той ветке, на которой вы находитесь, не является прямым предком для ветки, которую вы сливаете, Git-у придётся проделать кое-какую работу. В этом случае Git делает простое трехходовое слияние, используя при этом два снимка состояния репозитория, на которые указывают вершины веток, и общий снимок-прародитель для этих двух веток. На рисунке 3-16 выделены три снимка, которые Git будет использовать для слияния в этом случае.

Рисунок 3-16. Git автоматически определяет наилучшего общего предка для слияния веток

Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый снимок состояния, который является результатом трехходового слияния, и автоматически создает новый коммит, который указывает на этот новый снимок состояния (смотри Рисунок 3-17). Такой коммит называют коммит-слияние, так как он является особенным из-за того, что имеет больше одного предка.

Стоит отметить, что Git определяет наилучшего общего предка для слияния веток; в CVS или Subversion (версии ранее 1.5) этого не происходит. Разработчик должен сам указать основу для слияния. Это делает слияние в Git гораздо более простым занятием, чем в других системах.

Рисунок 3-17. Git автоматически создает новый коммит, содержащий результаты слияния

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

$ git branch -d iss53

Основы конфликтов при слиянии

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

$ git merge iss53 Auto-merging index. html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.

Git не создал новый коммит для слияния. Он приостановил этот процесс до тех пор, пока вы не разрешите конфликт. Если вы хотите посмотреть, какие файлы не прошли слияние (на любом этапе после возникновения конфликта), можете выполнить команду git status:

[master*]$ git status index.html: needs merge # On branch master # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # unmerged: index.html #

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

<<<<<<< HEAD:index. html

=======

>>>>>>> iss53:index.html

В верхней части блока (всё что выше =======) это версия из HEAD (вашей ветки master, так как именно на неё вы перешли перед выполнением команды merge), всё что находится в нижней части ― версия в iss53. Чтобы разрешить конфликт вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению. Например, вы можете разрешить этот конфликт заменой всего блока, показанного выше, следующим блоком:

Это решение содержит понемногу из каждой части, и я полностью удалил строки <<<<<<<, ======= и >>>>>>>. После того, как вы разрешили каждую из таких секций с каждым из конфликтных файлов, выполните git add для каждого конфликтного файла. Индексирование будет означать для Git, что все конфликты в файле теперь разрешены. Если вы хотите использовать графические инструменты для разрешения конфликтов, можете выполнить команду git mergetool, которая запустит соответствующий графический инструмент и покажет конфликтные ситуации:

$ git mergetool merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff Merging the files: index. html

Normal merge conflict for ‘index.html’:
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (opendiff):

Если вы хотите использовать другой инструмент для слияния, нежели выбираемый по умолчанию (Git выбрал opendiff для меня, так как я выполнил команду на Mac). Вы можете увидеть все поддерживаемые инструменты, указанные выше после “merge tool candidates”. Укажите название предпочтительного для вас инструмента. В Главе Настройка Git мы обсудим, как изменить это значение по умолчанию для вашего окружения.

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

Можете выполнить git status ещё раз, чтобы убедиться, что все конфликты были разрешены:

$ git status # On branch master # Changes to be committed: # (use "git reset HEAD . .." to unstage) # # modified: index.html #

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

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

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

Pro Git

«Git undo merge» — Как отменить слияние в git [Учебник]

Зачем отменять слияние

‍

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

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

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

мастер проверки git

‍

Затем найдите хэш фиксации слияния с git log :

git log —oneline

‍

Это сгенерирует список коммитов, который выглядит примерно так:

‍

Хеш фиксации — это строка из семи символов в начале каждой строки.В данном случае `085974e` — это хеш нашего слияния. После этого вы можете передать его команде git revert , чтобы отменить слияние:

git revert -m 1 [хеш фиксации]

‍

А Боб твой дядя! Команда git revert сгенерирует фиксацию, которая восстанавливает состояние вашей ветки до того места, где оно было до ошибочного слияния. Если ваше слияние было удаленным (то есть произошло на GitHub), вы можете отправить этот коммит, как и любой другой, и все будет готово.

‍

Как работает откат слияния?

‍

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

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

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

Однако, поскольку фиксация слияния по своей природе имеет две родительские фиксации (по одной от каждой ветви, которую вы объединяете вместе), вам необходимо указать, какой родитель является «основной веткой» — базовой ветвью, в которую вы слились.

Вот где появляется флаг -m — передача 1 указывает на ветку, которую вы извлекли, когда начали слияние (передача 2 указала бы на ветвь, которая была объединена in, что в нашем случае бесполезно). В документации по `revert` объясняется, как это работает.

‍

Повторное применение отмененного слияния

‍

Обычная потребность рабочего процесса после отмены ошибочного слияния — продолжить работу над веткой и повторно слить ее позже.

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

Линус Торвальдс, создатель Git, объясняет, почему это происходит (выделено мной):

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

Таким образом, слияние по-прежнему будет существовать, и оно по-прежнему будет рассматриваться как объединение двух ветвей вместе, и будущие слияния будут видеть это слияние как последнее совместно используемое состояние — и откат, который отменил введенное слияние, не повлияет на это вообще .

Итак, «возврат» отменяет изменения данных, но это очень _не_ «отмена» в том смысле, что он не отменяет влияние фиксации на историю репозитория.

Итак, если вы думаете о «откате» как об «отмене», то вы всегда пропустите эту часть отката. Да, он отменяет данные, но нет, он не отменяет историю.

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

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

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

‍

Принятие превентивных мер для предотвращения возврата к слиянию

‍

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

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

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

‍

Как отменить слияние в Git

Слияние — это процесс интеграции другой ветки в текущую ветку HEAD.(Если вы хотите узнать больше о слиянии в целом, ознакомьтесь с нашим обзором команд git merge.)

В этой короткой статье мы обсудим, как отменить слияние в Git!

Шпаргалка по Git

Не нужно запоминать все эти команды и параметры: получите нашу популярную «Шпаргалку по Git» — бесплатно!

Использование git reset для отмены слияния

Один из лучших аспектов Git — это то, что вы можете отменить практически все.И, к счастью, слияние не исключение! Вы можете использовать команду git reset , чтобы вернуться к ревизии перед слиянием, тем самым эффективно отменив ее:

  $ git reset --hard

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

  $ git reset --hard HEAD ~ 1

Таким образом, используя «HEAD ~ 1», вы говорите Git вернуться к фиксации перед текущей ревизией HEAD — которая должна быть фиксацией перед слиянием!

Обратите внимание, что в обоих случаях нам нужно использовать параметр «—hard». Это означает, что любые локальные изменения в вашей Рабочей копии будут отменены; если у вас есть ценные незафиксированные изменения, обязательно используйте ранее git stash .

Подсказка

Отмена слияния в Башне

В случае, если вы используете клиент Tower Git, отменить слияние действительно просто: просто нажмите CMD + Z после этого, и Tower отменит слияние за вас!

Как отменить принудительное слияние

Пример выше полезен, если вы еще НЕ отправили слияние в удаленный репозиторий.В таком случае, когда вы уже поделились фиксацией слияния со своими коллегами на удаленном компьютере, вам следует подумать о другом решении.

  $ git revert -m 1

Давайте подробнее рассмотрим, что будет делать эта команда:

git revert обеспечит создание новой фиксации , чтобы отменить последствия этого нежелательного слияния. В этом отличие от git reset , где мы эффективно «удаляем» фиксацию из истории. Это также причина, по которой git revert — лучшее решение в тех случаях, когда вы уже нажали на удаленный компьютер.
Параметр -m 1 сообщает Git, что мы хотим сохранить родительскую сторону для слияния (это ветвь, которую мы объединили с в ).
Наконец, также убедитесь, что предоставили правильный хэш фиксации: для приведенного выше примера git reset мы должны были предоставить фиксацию до слияния; однако при использовании git revert мы должны указать фактический хеш фиксации слияния.

Узнать больше

Git: отменить слияние

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

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

Первым шагом будет использование reflog , чтобы найти фиксацию прямо перед слиянием:

  $ git reflog

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

  $ git reflog
8135d07 [email protected] {0}: commit (merge): объединить ветку local / bug-34 в local / master
03979c8 [адрес электронной почты защищен] {1}: commit: добавлена поддержка параметров запроса
9f7a993 [электронная почта защищена] {2}: commit (initial): начальная фиксация

Как только вы найдете фиксацию, к которой хотите вернуться, используйте команду reset , аналогичную тому, что мы сделали при возврате к предыдущей фиксации, что, по сути, мы и делаем здесь:

  $ git reset --hard

Итак, в приведенном выше примере мы могли бы захотеть вернуться к фиксации с сообщением «Добавлена поддержка параметров запроса», что мы бы сделали так:

  $ git reset --hard 03979c8

Параметр --hard вернет код в дереве, промежуточной и рабочей копиях. Если вы не хотите потерять какие-либо локальные изменения, которые вы внесли, то --merge или --mixed могут быть для вас лучшими вариантами.

Если коммит, к которому вы хотите вернуться, находится только на один за HEAD , то вместо этого вы можете использовать ORIG_HEAD как ярлык в команде reset :

  $ git reset --hard ORIG_HEAD

В некоторых случаях это будет проще, так как вам не нужно будет использовать reflog для поиска хэша фиксации. ORIG_HEAD примерно эквивалентен [защита электронной почты] {1} , поэтому используйте его только в том случае, если вы хотите отменить одну фиксацию.

Примечание : после того, как вы отправили изменения в удаленное репо, не рекомендуется возвращать коммиты таким образом, поскольку вы стираете историю. В этом случае я бы рекомендовал использовать команду git revert , которая отменит нежелательные изменения как отдельную фиксацию.

Как отменить слияние Git

Фрагменты
›
Git
›
Как отменить слияние Git

Как отменить слияние с конфликтами
Как отменить

Как отменить слияние

Отмена принудительной фиксации слияния
Отмена с помощью команды git reset
Отмена с помощью команды git revert
Возврат отмененных изменений
Основное использование Git Merge

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

Как отменить слияние с конфликтами¶

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

Как отменить неотложенное объединение

Один из Полезные способы отмены git merge — запустить команду git reset. Использование этого метода поможет вам сохранить все локальные изменения, которые вы сделали. Он перемещает последнюю сделанную вами фиксацию до того, как произошло слияние.Чтобы запустить эту команду, вы должны действовать следующим образом:

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

  git reset --hard

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

Как отменить принудительную фиксацию слияния¶

Отмена с помощью команды git reset¶

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

  git push origin HEAD --force

Вместо —force вы можете использовать более безопасный метод: —force-with-lease , который не перезапишет работу других разработчиков.

Отмена с помощью команды git revert¶

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

  git revert -m 1

С -m 1 вы приказываете Git вернуться к первому родительскому объекту коммита слияния. Если вы хотите вернуться ко второму родителю, вам следует использовать параметр -m 2 .

Возврат отмененных изменений¶

Это изменит данные, а не историю, которые будут выглядеть до слияния. Так что это не совсем то, что нужно отменить. Если вы еще раз объедините разработку в мастер, изменения, которые были возвращены к нему, не могут быть применены. Если вы хотите вернуть изменения, вам нужно отменить первый возврат. Как видите, есть разные методы для отмены git merge .Прежде чем выбрать один из вышеперечисленных методов, следует учесть все последствия, которые он может принести.

Основное использование Git Merge¶

Git merge в первую очередь направлено на объединение двух ветвей. Вы также можете использовать его для объединения нескольких коммитов в единую историю. Коммиты слияния считаются уникальными из-за наличия двух родительских коммитов. Отдельные истории автоматически объединяются Git каждый раз, когда создается новый коммит слияния. Но это не будет объединение данных, которые были изменены в историях.

Спасибо за отзыв!

Считаете ли вы это полезным? Да Нет

Статьи по теме

Удалить слияние / фиксацию в git

Удалить слияние / фиксацию в git — Super User

Сеть обмена стеков

Сеть Stack Exchange состоит из 176 сообществ вопросов и ответов, включая Stack Overflow, крупнейшее и пользующееся наибольшим доверием онлайн-сообщество, где разработчики могут учиться, делиться своими знаниями и строить свою карьеру.

Посетить Stack Exchange

0
+0
Авторизоваться
Подписаться

Super User — это сайт вопросов и ответов для компьютерных энтузиастов и опытных пользователей. Регистрация займет всего минуту.

Зарегистрируйтесь, чтобы присоединиться к этому сообществу

Кто угодно может задать вопрос

Кто угодно может ответить

Лучшие ответы голосуются и поднимаются наверх

Спросил
7 лет, 5 мес назад

Просмотрено
65k раз

Используя git, я объединил ветку в master, и теперь, спустя несколько недель и много коммитов, я хотел бы удалить эту функцию / ветку.

Это откроет ваш редактор по умолчанию (обычно vi) со списком коммитов, причем тот, который вы хотите удалить первым. Удалите его из списка, сохраните и выйдите. Это не должно перемещать вашу ветку без фиксации, которую вы хотите удалить.

«Более безопасный» подход — оставить историю в неизменном виде, чтобы вы могли показать, что эта функция раньше существовала и была намеренно удалена. Просто используйте git revert . Это создаст дополнительный патч, который отменяет фиксацию, от которой вы хотите избавиться.Основное преимущество заключается в том, что вы можете редактировать сообщение фиксации и объяснять, почему эта функция удаляется.

Создан 29 мар.

Мурейник

3,7861010 золотых знаков2323 серебряных знака2828 бронзовых знаков

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

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

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

Рассказ:

Перейти к ветви, в которой было выполнено объединение. Затем просто выполните команду git revert -m 1 , которая откроет консоль vi для ввода сообщения фиксации.Напишите, сохраните, выйдите, готово!

Длинная история:

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

git revert <идентификатор фиксации слияния> -m 1 (возвращается к parent2 )

git revert <идентификатор фиксации слияния> -m 2 (возвращается к parent1 )

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

Создан 09 июл.

Суперпользователь лучше всего работает с включенным JavaScript

Ваша конфиденциальность

Нажимая «Принять все файлы cookie», вы соглашаетесь с тем, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Принимать все куки

Настроить параметры

Как отменить слияние в Git

Я объединяю ветку, скажем, b1, из другой ветки, скажем, b2.И у b1, и у b2 есть коммиты.

Скажем,

  b1: c1 ---> c2 ---> c3
b2: c1 ---> c4 ---> c5

Теперь, если я объединю b2 с b1 и нет конфликтов, история b1 будет включать коммиты b2 (c4, c5).

Как отменить это слияние в Git?

Вы можете отменить / отменить слияние (успешное, как в вопросе) с помощью

  $ git reset --hard ORIG_HEAD

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

Еще два примера из справочной страницы git reset:

  Отменить слияние или вытягивание

       $ git pull (1)
       Авто-слияние нитфол
       КОНФЛИКТ (содержание): Конфликт слияния в нитфолах
       Ошибка автоматического слияния; исправить конфликты и зафиксировать результат.
       $ git reset --hard (2)
       $ git pull. тема / ветка (3)
       Обновление с 41223 ... до 13134 ...
       Перемотка вперед
       $ git reset --hard ORIG_HEAD (4)

   1.Попытка обновиться из апстрима привела к множеству конфликтов; вы не были готовы тратить много времени на слияние прямо сейчас, поэтому вы решили сделать это позже.
   2. «pull» не произвел слияние фиксации, поэтому «git reset --hard», который является синонимом «git reset --hard HEAD», очищает беспорядок из индексного файла и рабочего дерева.
   3. Слияние тематической ветки с текущей веткой, что привело к быстрой перемотке вперед.
   4. Но вы решили, что тематическая ветка еще не готова для публичного использования.  "pull" или "merge" всегда оставляет исходный конец текущей ветви в ORIG_HEAD, поэтому
   жесткий сброс возвращает ваш индексный файл и рабочее дерево в это состояние и сбрасывает кончик ветки до этой фиксации.Отменить слияние или потянуть внутрь грязного рабочего дерева

       $ git pull (1)
       Авто-слияние нитфол
       Слияние выполнено рекурсивно.
        нитфол | 20 +++++ ----
        ...
       $ git reset --merge ORIG_HEAD (2)

   1. Даже если у вас могут быть локальные изменения в вашем рабочем дереве, вы можете спокойно сказать «git pull», если знаете, что изменения в другой ветке не перекрываются с ними.
   2. Изучив результат слияния, вы можете обнаружить, что изменение в другой ветви неудовлетворительное.Выполнение "git reset --hard ORIG_HEAD" позволит вам вернуться к
   где вы были, но он отменит ваши локальные изменения, которые вам не нужны. "git reset --merge" сохраняет ваши локальные изменения.

Отмена локального слияния Git

Git — фантастический инструмент для управления кодом проекта в командном контексте, но, как и в случае с любым другим инструментом, всегда будут случаи, когда вы столкнетесь с проблемами.

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

Ниже приведены способы, с помощью которых это можно сделать относительно быстро …

Аппаратный сброс

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

  git журнал
git reset --hard COMMIT_SHA_REFERENCE

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

  git журнал
git reset --hard HEAD ~ NUMBER_OF_COMMITS_TO_ROLL_BACK

Не забудьте использовать тильду в описанном выше методе!

Главный недостаток этих подходов? Вы не сохраните никаких локальных изменений, которые вы сделали, поэтому используйте их с осторожностью!

Сброс слияния

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

  git reset --merge ORIG_HEAD

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

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

Итак, у вас есть несколько способов выполнить отмену локальных слияний в Git.

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

Категории

«Вернуться к сообщениям

Октябрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31

Git как отменить слияние: Отменить Git merge, который еще не был нажат

Отменить Git merge, который еще не был нажат

25 ответов

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

Похожие вопросы:

Как отменить коммит слияния, который уже передан в удаленную ветку?

Как отменить мерж файлов и как разрешать конфликты руками? — Хабр Q&A

git — Отменить слияние git, которое только что было отправлено, и повторить слияние

2 ответа

30. Разрешение конфликтов

Цели

Выполните:

Результат:

Файл:

Файл:

Выполните:

Результат:

Основы ветвления и слияния | Pro Git

Основы ветвления

Основы слияния

Основы конфликтов при слиянии

«Git undo merge» — Как отменить слияние в git [Учебник]

Зачем отменять слияние

Как работает откат слияния?

Повторное применение отмененного слияния

Принятие превентивных мер для предотвращения возврата к слиянию

Как отменить слияние в Git

Шпаргалка по Git

Использование git reset для отмены слияния

Подсказка

Отмена слияния в Башне

Как отменить принудительное слияние

Узнать больше

Git: отменить слияние

Как отменить слияние Git

Как отменить слияние с конфликтами¶

Как отменить неотложенное объединение

Как отменить принудительную фиксацию слияния¶

Отмена с помощью команды git reset¶

Отмена с помощью команды git revert¶

Возврат отмененных изменений¶

Основное использование Git Merge¶

Спасибо за отзыв!

Статьи по теме

Удалить слияние / фиксацию в git

Сеть обмена стеков

Как отменить слияние в Git

Отмена локального слияния Git

Аппаратный сброс

Сброс слияния

Категории

Добавить комментарий Отменить ответ