2016-10-18 2 views
0

У нас есть проблема, когда разработчик случайно испортил слияние и нажал пустую транзакцию слиянием. Смотрите схему ниже:Пустой Git merge удален commits

develop ----A----------------------------------F------------------I 
       \        /    /
    feature1 B----------------C----------------------G---------H 
           \   /
feature2 ------------------------D---------E----------------------- 

сказать, что филиал feature1 был создан в точке A на develop ветви. В точке C, feature1 было слито с feature2. Однако это слияние было сделано некорректно, а commit D - фиксация слияния - была пустой фиксацией, которая фактически отклонила все изменения с feature1 (т. Е. Изменения B и C были случайно отклонены).

В точке E, feature2 было объединено с develop. Наконец, в точке H, feature1 был объединен с develop для внесения изменений G и H.

Тем не менее, как ожидается, в точке I что develop будут иметь изменения B и C, а также G и H. Однако, я считаю, что они были отклонены при слиянии C -> D, это не так.

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

+0

У вас есть два коммитов помеченные 'G' на вашей диаграмме, но они кажутся разными. Предполагается, что это 'F'? – torek

+0

@torek Да, вы правы. Исправлена. – Dunnie

+0

Я думаю, что ваш план - это очень правильный путь.Обратите внимание, что 'git rebase' имеет' -f'/'--no-ff', чтобы помочь вам скопировать фиксации, которые' git merge' будет считать * новым * (обязательным слиянием), но если они достаточно далеко в прошлом, вы столкнетесь с какой-то доработкой (будь то при заливке или слиянии). – torek

ответ

0

Я не думаю, что для исправления этого примера есть что-то быстрое и/или безопасное.

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

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

Удачи.

0

Я думаю, если вы повторно запустить слияние D правильно, как D', а затем применить к I разницы между D и D' это должно исправить проблему.

(Обратите внимание, что неправильное D слияние вернулось не только B и C, но и develop историю от последнего коммита известного feature2 к A)

шагов должны быть что-то вроде:

git checkout -b tmp_fix D~1 
git merge C 
# now, you have correct D', but you should make it child of D to pick it 
git reset --soft D 
git commit -m "Fix incorrect merge D" 
git checkout develop 
git cherry-pick tmp_fix