Фон: Недавно я объединил довольно большую ветку темы в master. Через пару дней я обнаружил, что в этой ветке темы были ошибки. Поэтому я git revert -m 1 <merge-commit> отредактировал его.
Проблема: Теперь я хочу проверить ветку темы и переустановить ее против текущего master, чтобы я мог 1) исправить ошибки и 2) (снова) объединить исправленные тема ветки с мастером. Создание новой ветки fixedtopic - это легкая часть, но каждый раз, когда я делаю
git checkout fixedtopic
git rebase master
git решает, что он не желает воспроизводить старые коммиты, поскольку они уже объединены в master. Вместо этого он просто выполняет быструю переадресацию.
Вопрос: Как заставить повторить фиксацию на fixedtopic с помощью rebase? Могу я? Я бы предпочел не использовать cherry-pick, так как это немного более громоздко.
Дополнительно:
git reset объединение слиянием не делает его невозможным, так как я подтолкнул мастер вверх по течению.master и возвращать мое возвращение. Причина этого в том, что я хотел бы переписать часть истории ветвей темы, используя интерактивную rebase.master (или ветвь на основе master).Один из способов достижения этого - интерактивно переустановить ветвь темы и переписать первый коммит после разветвления из мастера (например, git rebase -i HEAD~10, если у вас есть 10 коммитов в ветке). Это будет переписывать все коммиты внутри ветки темы. Поэтому вы можете переустановить обычным способом с помощью git rebase master.
Документация (git help rebase) предполагает, что "git rebase -force-rebase" делает именно это, но (git 1.9.1) это не так. В документации также указывается, что "git rebase -i -no-ff" эквивалентен этой команде, но это не так: она работает.
Клонируя ваш текст, команды:
git checkout topic
git rebase -i --no-ff --onto master 7b3af topic
создайте желаемый результат, а новые версии "третьего" и "четвертого" совершают на вершине мастера, а topic указывают на новую версию "четвертый". Во второй команде SHA 7b3af является "второй" фиксацией, точка, в которой topic была разветвлена.
Вам нужно использовать --onto, чтобы предотвратить форму Git, пытаясь самостоятельно определить соответствующие несанкционированные коммиты.
например. (с ответом на тему):
git rebase --onto master <id-of-branch-point>
Для <id-of-branch-point> вы хотите git merge-base вашей ветки темы и фиксации на главном устройстве до слияния, которое вы вернули.
Edit
Повторное повторное чтение вашей ситуации, возможно, было бы лучше, если вы быстро перешлите ветку темы до точки, в которой вы вернули слияние, затем верните реверсию и исправьте ветвь темы с этой точки. Таким образом, вы не получите повторения всех коммитов в исходной ветке темы, но с новыми идентификаторами в последней истории мастера. Независимо от того, что вы делаете, вы закончите историю с участием "do, undo, redo", но этот способ можно считать более чистой историей.
Что лучше всего работает, так это проверить новую ветку, а затем повторно установить предыдущую рабочую ветвь, вернув обратно.
Все, что я пробовал, слишком сложно и/или не работает.
Для git merge (т. git rebase Не для git rebase как было первоначально задано), в соответствии с 7.8 Git Tools - Advanced Merging (см. Раздел "Отменить фиксацию"):
Лучший способ обойти это - отменить первоначальное слияние, так как теперь вы хотите внести изменения, которые были отменены, а затем создать новый коммит слияния:
$ git revert ^M
<...>
$ git merge topic
Рисунок 142. История после повторного слияния отмененного слияния
