Все ответы на данный момент не относятся к конечной проблеме:
Есть ли эффективный метод при сотнях ревизий?
после удаляемого?
Далее следуют шаги, но для справки, давайте предположим следующую историю:
[master] -> [hundreds-of-commits-including-merges] -> [C] -> [R] -> [B]
C :
коммит, следующий за коммитом, который будет удален (чистый)
R :
Коммит, который будет удален
B :
коммит, предшествующий коммиту, который будет удален (базовый)
Из-за ограничения «сотни ревизий» я предполагаю следующие предварительные условия:
- есть какой-то смущающий коммит, которого вы бы никогда не хотели
- есть ZERO последующих коммитов, которые на самом деле зависят от этого смущающего коммита (ноль конфликтов при возврате)
- вас не волнует, что вы будете внесены в список «коммиттеров» из сотен промежуточных коммитов («Автор» будет сохранен)
- вы никогда не делили хранилище
- или вы действительно имеете достаточно влияния на всех людей, которые когда-либо клонировали историю с этим обязательством, чтобы убедить их использовать вашу новую историю
- а вам не волнует о переписывает историю
Это довольно ограниченный набор ограничений, но есть интересный ответ, который действительно работает в этом угловом случае.
Вот шаги:
git branch base B
git branch remove-me R
git branch save
git rebase --preserve-merges --onto base remove-me
Если действительно нет конфликтов, то это должно продолжаться без дальнейших перерывов. Если есть конфликты, вы можете разрешить их и rebase --continue
или решить просто жить с смущением и rebase --abort
.
Теперь вы должны быть на master
, в котором больше нет коммита R . Ветвь save
указывает на то место, где вы были раньше, если вы хотите примирить.
Как вы хотите организовать передачу всех остальных в вашу новую историю, зависит от вас. Вам нужно будет ознакомиться с stash
, reset --hard
и cherry-pick
. И вы можете удалить ветви base
, remove-me
и save