Повторное выполнение отмененного слияния в Git

Вы должны «отменить возврат». В зависимости от того, как был восстановлен исходный файл, это может быть не так просто, как кажется. См. официальный документ по этому поводу тема.

---o---o---o---M---x---x---W---x---Y
              /
      ---A---B-------------------C---D

позволять:

---o---o---o---M---x---x-------x-------*
              /                       /
      ---A---B-------------------C---D

Но все ли работает? Конечно, есть. Вы можете отменить слияние, и с чисто технической точки зрения git сделал это очень естественно и не имел никаких реальных проблем.
Он просто считал это изменением с «состояния до слияния» на «состояние после слияния», и на этом все .
Ничего сложного, ничего странного, ничего особо опасного. Git сделает это, даже не задумываясь.

Итак, с технической точки зрения нет ничего плохого в отмене слияния, но с точки зрения рабочего процесса этого обычно следует избегать.

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

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

Да, это более сложно, и нет, это не всегда будет работать (иногда ответ: «ой, мне действительно не следовало объединять его, потому что он еще не был готов, и мне действительно нужно отменить все из слияния "). Итак, вам действительно следует отменить слияние, но когда вы хотите повторно выполнить слияние, вам теперь нужно сделать это, отменив откат.

Предположим, у вас есть такая история

---o---o---o---M---W---x-------x-------*
              /                      
      ---A---B

Где A, B завершились неудачно, а W - это возврат M

Поэтому, прежде чем я начну исправлять найденные проблемы, я выбираю W-коммит в свою ветку.

git cherry-pick -x W

Затем я возвращаю фиксацию W в своей ветке

git revert W 

После я могу продолжить исправление.

Окончательная история может выглядеть так:

---o---o---o---M---W---x-------x-------*
              /                       /     
      ---A---B---W---W`----------C---D

Когда я отправлю PR, он ясно покажет, что PR отменен, и добавлены новые коммиты.

Чтобы отменить возврат, не сильно нарушая рабочий процесс:

• Создайте локальную копию файла develop
• Отменить возвратную фиксацию на локальной копии разработки
• Слейте эту копию в свою ветку функций и отправьте ветку функций на свой сервер git.

Теперь ваша функциональная ветка может быть объединена как обычно, когда вы будете к этому готовы. Единственным недостатком здесь является то, что у вас будет несколько дополнительных коммитов слияния / возврата в вашей истории.

Чтобы отменить возврат в GIT:

git revert <commit-hash-of-previous-revert>

Вместо использования git-revert вы могли бы использовать эту команду в ветке devel, чтобы выбросить (отменить) неправильную фиксацию слияния (вместо того, чтобы просто отменить ее).

git checkout devel
git reset --hard COMMIT_BEFORE_WRONG_MERGE

Это также соответствующим образом изменит содержимое рабочего каталога. Будьте осторожны:

• Сохраните изменения в ветке разработки (из-за неправильного слияния), потому что они тоже будут стерты git-reset. Все коммиты после того, который вы укажете в качестве аргумента git reset, исчезнут!
• Кроме того, не делайте этого, если ваши изменения уже были извлечены из других репозиториев, потому что сброс перезапишет историю.

Я рекомендую внимательно изучить git-reset справочную страницу, прежде чем пытаться это сделать.

Теперь, после сброса, вы можете повторно применить изменения в devel, а затем выполнить

git checkout devel
git merge 28s

Это будет настоящее слияние 28s с devel, как и исходное (которое теперь удалено из истории git).

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

git checkout develop #go to develop branch
git pull             #get the latest from remote/develop branch
git branch users/yourname/revertOfSHA1 #having HEAD referring to develop
git checkout users/yourname/revertOfSHA1 #checkout the newly created branch
git log --oneline --graph --decorate #find the SHA of the revert in the history, say SHA1
git revert SHA1
git push --set-upstream origin users/yourname/revertOfSHA1 #push the changes to remote

Теперь создайте PR для ветки users/yourname/revertOfSHA1

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

Вместо этого я проверил фиксацию, к которой я хотел, чтобы ветка вернулась, например. git checkout 123466t7632723. Потом преобразовал в ветку git checkout my-new-branch. Затем я удалил ветку, которая мне больше не нужна. Конечно, это сработает, только если вы сможете выбросить испорченную ветку.

1. создать новую ветку при фиксации до первоначального слияния - назовите ее «разработка-база»
2. выполнить интерактивную перебазировку «develop» поверх «develop-base» (даже если она уже находится наверху). Во время интерактивной перебазировки у вас будет возможность удалить как фиксацию слияния, так и фиксацию, которая отменила слияние, то есть удалить оба события из истории git.

На этом этапе у вас будет чистая ветка «разработка», с которой вы сможете объединить свою функциональную ветвь, как вы это делаете обычно.