Удалить некорректные слияния из хранилища

Question

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

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

Я разработал локальный набор изменений из ветки разработки, что-то вроде:

develop (A)- (D1) - (D2)
         \ - (F1) - (F2) - (F3) - (F4)

В этот момент я проскользнул в свой git gui и вместо того, чтобы выдвигать свою ветвь функций как удаленную ветвь в начало, я каким-то образом вернул ее в начало / разработку. Итак, теперь у нас было:

develop (A)- (D1) - (D2) -      -      (M1)
         \ - (F1) - (F2) - (F3) - (F4) /

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

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

Что я забыл, так это то, что наша система непрерывной интеграции выполняла регулярные операции и ей удалось получить копию слитых голов. Неделю спустя я заметил некоторые коммиты по круиз-контролю на хосте-источнике и почувствовал себя плохо. Конечно же, это было слияние головы разработки origin в ее локальное репозиторий "Feature ветка слился".

Итак, мы сейчас находимся в такой ситуации:

Круиз-контроль репо:

      (from origin/develop)            (C1) - (C2) - (C3)
develop (A)- (D1) - (D2) -      -      (M1) \ (M2) \ (M3)
         \ - (F1) - (F2) - (F3) - (F4) /

Происхождение репо:

develop (A)- (D1) - (D2) - (C1) - (C2) - (C3) 
         \ - (F1) - (F2) - (F3) - (F4)

Где C1 и C2 - коммиты, сделанные в исходное репо нами, разработчиками, у которых есть "исправленное" репо (т.е. после моих манипуляций с головой, чтобы отменить мою первоначальную ошибку), а M2 и M3 - коммиты слияния, которые теперь должен был сделать репо cruisecontrol.,

Теперь я сделал что-то действительно глупое. Я "git push" в исходном репозитории cruisecontrol. Таким образом, в нашем репо "происхождение" теперь есть слияние M1 и промежуточные слияния M2 и M3.

Я снова заставил своих коллег некоторое время не тянуть. Тем не менее, мой git-foo не достаточно силен, чтобы распутать коммиты Mx и Cx друг от друга в исходном репо и вернуть вещи обратно к тому, как они должны быть.

Я думаю, что мне нужно сделать что-то умное с HEAD^(x) и HEAD~(y), но это сложная ситуация, чтобы объяснить кратко и, следовательно, довольно сложно для Google.

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

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

Спасибо!

Answer 1

Все коммиты в git с одним и тем же хешем идентичны (как и история), поэтому вы должны иметь возможность использовать одни и те же команды как в вашем источнике, так и в вашем CI-репозитории (учитывая, что develop проверено:

# on the current branch:
git reset --hard C3
# on your feature branch:
git branch -f feature F4

git push не должен принудительно толкать по умолчанию, и вы не указали, что в вашем вопросе, где CI -> origin произошел толчок, поэтому я предполагаю, что это был перемотка вперед (по умолчанию)

на будущее я рекомендую ваш репозиторий CI, чтобы сделать git fetch + git reset --hard origin/develp, если вы не хотите, чтобы ваши ветви объединялись (возможно, с коммитами, существующими только в репозитории CI)