Удалить некорректные слияния из хранилища
Я не доволен названием, но думаю, что слишком усложнил свое объяснение, и оно так же просто, как и выше, в конце.
Мы используем модель ветвления с центральным репозиторием происхождения, ветвью "разработки", с функциональными ветвями вне этой ветки.
Я разработал локальный набор изменений из ветки разработки, что-то вроде:
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, удаленный и повторно клонированный, и серию коммитов М, готовых для сбора мусора в репо-источнике.
Спасибо!
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)