Rebase reverted объединенная ветка

Фон: Недавно я объединил довольно большую ветку темы в 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.
Вот сценарий сценария: https://gist.github.com/JensRantil/6352495 Заметьте, что я хотел бы использовать e8df5ec и ee16464 на master (или ветвь на основе master).

Ответ 1

Один из способов достижения этого - интерактивно переустановить ветвь темы и переписать первый коммит после разветвления из мастера (например, git rebase -i HEAD~10, если у вас есть 10 коммитов в ветке). Это будет переписывать все коммиты внутри ветки темы. Поэтому вы можете переустановить обычным способом с помощью git rebase master.

Ответ 2

Документация (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 была разветвлена.

Ответ 3

Вам нужно использовать --onto, чтобы предотвратить форму Git, пытаясь самостоятельно определить соответствующие несанкционированные коммиты.

например. (с ответом на тему):

git rebase --onto master <id-of-branch-point>

Для <id-of-branch-point> вы хотите git merge-base вашей ветки темы и фиксации на главном устройстве до слияния, которое вы вернули.

Edit

Повторное повторное чтение вашей ситуации, возможно, было бы лучше, если вы быстро перешлите ветку темы до точки, в которой вы вернули слияние, затем верните реверсию и исправьте ветвь темы с этой точки. Таким образом, вы не получите повторения всех коммитов в исходной ветке темы, но с новыми идентификаторами в последней истории мастера. Независимо от того, что вы делаете, вы закончите историю с участием "do, undo, redo", но этот способ можно считать более чистой историей.

Ответ 4

Что лучше всего работает, так это проверить новую ветку, а затем повторно установить предыдущую рабочую ветвь, вернув обратно.

Все, что я пробовал, слишком сложно и/или не работает.

Ответ 5

Для git merge (т. git rebase Не для git rebase как было первоначально задано), в соответствии с 7.8 Git Tools - Advanced Merging (см. Раздел "Отменить фиксацию"):

Лучший способ обойти это - отменить первоначальное слияние, так как теперь вы хотите внести изменения, которые были отменены, а затем создать новый коммит слияния:

$ git revert ^M

<...>

$ git merge topic

Рисунок 142. История после повторного слияния отмененного слияния