Мне нужно временно отменить слияние, чтобы я мог сделать еще один позже

Question

Я слил боковую ветвь (функция / b) в разработку, У меня возникли конфликты слиянием, и я принял неправильное решение о том, как их разрешать Затем я сделал ручной коммит, чтобы исправить некоторые другие проблемы. В коммит / b пришло больше коммитов, и я тоже их слил Затем я осознал свою ошибку и отменил последнее слияние.

Все было перенесено на пульт, и команда его вытащила.

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

Какой мой лучший способ решить эту проблему?

• отменить все три шага? Если я правильно понимаю, это не Получите мне второй шанс исправить первоначальные конфликты?
• сбросить голову? эффективно уничтожать историю? это влияет на историю на другие ветви?
• сдаться и создать, например, развиваю ветку до того как я пошел неправильно?

Спасибо

Я прочитал этот тесно связанный ответ, но мне нужны дополнительные указания: Как отменить коммит слияния, уже отправленный в удаленную ветвь?

Answer 1

Этот ответ предполагает, что ваша текущая ветка feature/b выглядит примерно так:

feature/b:  .. M -- A -- B -- C

Здесь M - это фиксация слияния, которую вы не хотели, и затем поступают коммиты от A до C от других разработчиков, которые вытянули ветку и затем нажали. Мы можем попробовать использовать git revert с диапазоном:

git revert -m 1 HEAD~3^..HEAD

Синтаксис HEAD~3^..HEAD означает отмена коммитов, включая три, до HEAD до коммита HEAD. Опция -m 1 указывает Git следовать первому родителю ветви, которая обычно будет удаленной веткой (источником слияния будет -m 2).

Обратите внимание, что необходимо git revert здесь, потому что вы уже опубликовали эту ветку. Такие вещи, как аппаратный сброс и другие изменения истории, не будут здесь идеальными.

Answer 2

Что бы вы ни делали, не переустанавливайте и не нажимайте принудительно develop, потому что он используется совместно с другим разработчиком, и он станет более беспорядочным.

Вы можете вернуться, но, как вы видели, помните, что ранее объединенные коммиты будут игнорироваться в будущем слиянии (так как история не изменилась). Я бы воссоздал новую ветку, как если бы она была новой.

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

Допустим, мы в такой ситуации

 /B-C\(feature/1)
A-----D-E(develop)

, где A - это develop до слияния и происхождения ветви, C - feature/1 ветвь в момент слияния, D коммит слияния, E попытка исправить это.

Сначала верните D и E, так как D является коммитом слияния, вам нужно указать, к какому из родителей следует вернуться, используя -m, это должен быть 1, но отметьте (git revert D -m 1). Затем перебазировать ветку feature/1 on при коммите A (источник ветки)

git checkout feature/1
git rebase --no-ff A (no-ff to force rebase)

Тогда вы закончите так:

 /B-C\
A-----D-E-F(develop)
 \B'-C'(feature/1)

где F - коммит для возвратов, а B 'и C' - только что созданные коммиты.

И вы можете объединить feature/1, как будто это новая ветвь.

Answer 3

Звучит, как на самом деле грязная ситуация.

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

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