Вариант 1. Аппаратный сброс и принудительное нажатие
Если возможно выполнить принудительное обновление без перемотки вперед для вашей ветки master в вашем вышестоящем репозитории, то вместо отката слияния develop с master вы можете просто выполнить полный сброс master:
# On master branch, do a hard reset back to the commit before the merge
git reset --hard <commit of master before the merge>
# Force push to upstream ONLY IF IT'S OK WITH OTHER DEVELOPERS
git push <remote> master --force
Возможный недостаток выполнения аппаратного сброса и принудительного нажатия заключается в том, что, если другие разработчики уже основывали работу на фиксации слияния (т.е. сделали коммиты поверх нее), то им нужно будет повторить ту же самую работу поверх. сбросной головки master. Это может быть, а может и не оказаться для них сложной / дорогостоящей задачей.
Вариант 2. Отменить возврат
Я проверил это с помощью быстрого тестового репо. Я должен подчеркнуть, что это может сработать, я не уверен на 100%, что нет случаев, которые я бы не рассматривал. Поэтому не забудьте сначала протестировать его локально с помощью резервного клона вашего репо. Если вы решите использовать это в своем реальном репо, сделайте это на свой страх и риск.
Кроме того, это может быть не самое легкое / простое решение. Однако его преимущество перед опцией полного сброса состоит в том, что он не заставляет разработчиков повторять работу поверх ветки сброса master.
Хорошо, разобравшись со всем этим, вы можете попробовать объединить master в develop, затем отменить возврат слияния с develop в master, а затем слить develop с master, когда будете готовы. В командах:
# Coworker accidentally merges develop into master before it's ready
git merge --no-ff develop
# You revert the merge in the master branch (this creates commit "ABCDEFG"
git revert -m 1 <sha of merge commit>
# You want to merge fixes from master into develop
git checkout develop
git merge --no-ff master
# But now all that work in develop is reverted, so revert the revert "ABCDEFG"
git revert ABCDEFG
# When you're ready to merge develop into master...
git checkout master
git merge --no-ff develop
Вот последовательность команд, которые я использовал, чтобы проверить это в тестовом репозитории:
mkdir practice
cd practice/
git init
touch readme.txt
git add practice.txt
git commit -m "Add practice.txt"
git checkout -b develop
touch feature1.txt
git add feature1.txt
git commit -m "Add feature 1"
touch feature2.txt
git add feature2.txt
git commit -m "Add feature 2"
git checkout master
touch hotfix1.txt
git add hotfix1.txt
git commit -m "Fix issue 1"
git merge --no-ff develop
# Creates commit "ABCDEFG" that reverts the merge
git revert -m 1 head
git checkout develop
git merge --no-ff master
git revert ABCDEFG
git checkout master
git merge --no-ff develop
Вы можете узнать больше о технике «Отмена возврата» на странице официальная документация Git ядра Linux для git revert:
-m parent-number
--mainline parent-number
Обычно вы не можете отменить слияние, потому что не знаете, какую сторону слияния следует считать основной. Эта опция указывает родительский номер (начиная с 1) основной линии и позволяет откатить, чтобы отменить изменение относительно указанного родителя.
Отмена фиксации слияния означает, что вам никогда не понадобятся изменения дерева, внесенные слиянием. В результате более поздние слияния внесут только изменения в дерево, внесенные коммитами, которые не являются предками ранее отмененного слияния. Это может быть то, что вы хотите, а может и не быть.
См. revert-a-faulty -merge How-To для получения более подробной информации.
Ссылка на Как отменить Неправильное слияние настоятельно рекомендуется, если вы полностью хотите понять, как работает этот метод, это несложно для понимания и на самом деле довольно интересно и увлекательно.
person
Community
schedule
25.07.2013
masterв предыдущее состояние (вместо возврата) не возможен? - person schedule 25.07.2013masterв состояние до слияния и принудительно нажмете? Это требует, чтобы все снова синхронизировались, но он сохраняет вашу историю - person CharlesB schedule 25.07.2013