Перефразировано с конфликтами слияния: как отменить?

Question

Я работал над веткой функций B, которую я разветвлял от мастера месяц назад.По мере появления других новых функций ветка master постоянно обновлялась.

Вот так выглядит основная ветвь прямо сейчас:

1 -> 2 -> 3 -> 4 -> 5 -> 6 ->7 

Когда я впервые разветвился, это выглядело так:

1 -> 2 -> 3

Вот как мойветвь функции (B) выглядит прямо сейчас:

x -> y -> z

Теперь, когда я готов перевести мою новую функцию в мастер, мне посоветовали сначала выполнить ребазинг от мастера, а затем создать PR.

При выполнении git rebase моя ветка столкнулась с конфликтом слияния с парой файлов.Я думал, что просто сохраню входящие изменения, и ребаз будет проходить нормально.Однако я, разрешив конфликты, превратил весь шаг «REBASE MASTER» в своего рода «MERGE MASTER».АКА: Он применил коммиты, которые уже были объединены с мастером, в мою ветвь функций, а не то, что я изначально намеревался сделать с git rebase.

Вот так сейчас выглядит моя ветвь функций:

x -> 4 -> 5 -> 6 -> y -> 7 -> z

Вот чего я хотел добиться (но не достиг):

1 -> 2 -> 3 -> 4 -> 5 -> 6 ->7 -> x -> y -> z

Как мне вернуться?Это уже было перенесено в удаленную ветку, поэтому я не могу просто удалить свою локальную ветку и снова извлечь из источника.

Один из способов, который я могу придумать, состоит в том, чтобы снова разветвляться от мастера и создавать ветвь функции C. Затем вишневый пик фиксирует коммит из B в C. Как только я уверен, что C является полной копией B (и содержит только коммиты, которые я хочу), я могу удалить B. Я что-то упустил?Или есть лучший / более быстрый способ?

Answer 1

(Прежде всего, на всякий случай, прервите любую перебазировку, все еще продолжающуюся с git rebase --abort)

---

Вы единственный, кто работает над этой веткой функций? (Наверное, я приму это к следующему)

PR уже принят / объединен в мастера?

Если не , то это очень неприятная ситуация. (Это может быть то, что Люкс намекал в комментариях)

Сначала найдите хеш коммита, который нужно восстановить (z в вашем примере). Для этого вы можете проверить reflog вашей ветки (или, возможно, просто выбрать его из последних выводимых команд, если таковые имеются).

Затем восстановите вашу локальную ветвь B до старой ссылки (до перебазирования) и снова отправьте ее на удаленный (с помощью --force, поскольку git будет жаловаться, что это не линейная история).

git branch -f B <commit_hash_of_z>
git push -f origin B

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

Answer 2

Существует возможность отменить регистрацию, которая выполняется как отдельная регистрация.

Но я бы посоветовал действовать осторожно и прочитать.

https://www.atlassian.com/git/tutorials/undoing-changes/git-revert

Также я надеюсь, что вы понимаете разницу между «перебазированием A на B» и «слиянием A с B»

Я бы посоветовал, если вы делаете rebase, пожалуйста, обновите источник master на локальном компьютере (это мой способ держать все под контролем, я не знаю, является ли он стандартным)