Как я могу отказаться от слияния в Mercurial и позже вернуться к этой ветке? - PullRequest
52 голосов
/ 11 ноября 2010

У меня есть две ветви, по умолчанию и branch1. По ошибке один человек в нашей команде слил branch1 по умолчанию. Содержимое в branch1 еще не готово для объединения со значением по умолчанию (оно содержит основную переработку среды build & deploy).

Мы провели эксперимент с 'hg backout', отказавшись от слияния (не уверен, что это правильный способ сделать это). Затем изменения из branch1 удаляются по умолчанию, что нормально, но мы не можем объединиться с branch1.

Как мы должны решить эту проблему?

Ответы [ 6 ]

90 голосов
/ 11 ноября 2010

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

Никаких дальнейших изменений, объединение не передается (нет нажатий/ тянет)

Программист слился, но больше ничего не сделал, и не поделился изменениями с кем-либо, каким-либо образом

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

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

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

В этом случае я бы сделал одно из четырех:

  1. Попробуйте использовать расширение REBASE, этопереместит наборы изменений из одного места в другое.Если наборы изменений основаны на изменениях кода, которые были введены в результате слияния, для согласования различий необходимо выполнить некоторую ручную работу.
  2. Попробуйте использовать расширение MQ для извлечения наборов изменений, которые должны быть сохранены вОчередь патчей, затем верните их в другое место.Это, однако, будет иметь ту же проблему, что и расширение REBASE, с точки зрения изменений на основе слияния
  3. Попробуйте использовать расширение TRANSPLANT для «копирования» изменений из одного местоположения в другое.Тем не менее, существует та же проблема, что и с первыми двумя.
  4. Выполните работу еще раз, возможно, с помощью инструмента сравнения, чтобы внести изменения, внесенные в наборы изменений, которые я хочу отменить, и повторно сделать их в правильномlocation.

Чтобы избавиться от набора изменений слияния + всех следующих наборов изменений, есть пара опций:

  1. Используйте команду strip в расширении MQ

    hg strip <hash of merge changeset>
    
  2. Клонировать и вытягивать и указывать хэш наборов изменений, ведущих к, но не включая объединение.По сути, создайте новый клон, вытянув поврежденный клон в новый, и избегайте затягивания слияния, которое вам не нужно.

    hg clone damaged -r <hash of first parent> .
    hg pull damaged -r <hash of second parent>
    

Слияние, переданное другим,контроль над клонами

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

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

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

При слиянии нажата, у вас нет контроля над клонами

Программист нажал на mergeset, и вы не знаете, у кого будет набор изменений.Другими словами, если вам удастся уничтожить его из вашего хранилища, случайный толчок кого-то, у кого он еще есть, вернет его.

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

  M         <-- this is the one you want to disregard
 / \
*   *
|   |
*   *
|   |

Просто продолжайте работать в двух ветвях:

|   |
*   *
| M |       <-- this is the one you want to disregard
|/ \|
*   *
|   |
*   *
|   |

Затем вы объединяете два, реальное слияние, которое вы хотите:

  m
 / \
*   *
|   |
*   *
| M |       <-- this is the one you want to disregard
|/ \|
*   *
|   |
*   *
|   |

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

С помощью TortoiseHg я бы обновился до слияния, которое я хочу сохранить (самый верхний, нижний регистр m), затем выбрал и щелкнул правой кнопкой мыши на свисающей головке слияния ниже, а затем установил флажок «Отменить все изменения от цели слияния (другое»). ) редакция ": discard changes from target

4 голосов
/ 18 марта 2015

Мы провели эксперимент с 'hg backout', отказавшись от слияния (не уверен, что это правильный способ сделать это). Затем изменения из branch1 удаляются по умолчанию, что нормально, но мы не можем объединиться с branch1.

Я использую backout для отмены слияния. Вы не можете выполнить повторное объединение, но вы можете выполнить "backout backout merge", то есть когда вы хотите повторно объединить, вы делаете 'hg backout' при фиксации "Backed out merge changeset ..." и затем снова объединяете ветвь.

Пример:

  7     M       remerge
  6   /   \
  5   *   |     hg backout 3 (backout backout)
  4   |   *     fix error 
  3   *   |     hg backout 2
  2   M   |     fail merge
    /     \
  1 *     *
    |     |
1 голос
/ 13 ноября 2010

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

На нашем сервере репозитория мы создали новый репозиторий, затем клонировали старый репозиторий вплоть до ревизии непосредственно перед слиянием. Затем отправил новый клон на сервер и разослал новую ссылку всем. К счастью, мы довольно маленькая команда разработчиков.

Возможно, не самый удобный способ решения проблемы, но это сработало:)

0 голосов
/ 19 апреля 2012

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

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

0 голосов
/ 11 ноября 2010

В этом ответе предполагается, что вы уже нажали

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

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

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

Эрик Рэймонд работает над чем-то , более или менее независимым от DVCS, которое может (надеюсь) помочь в ситуациях, подобных описанным вами, но я неНе думаю, что он получит полную поддержку HG еще неделю или две.Тем не менее, возможно, стоит посмотреть.

Но, полезно только в том случае, если никто не потянул за наконечник "оупси".

0 голосов
/ 11 ноября 2010

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

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