Ответ 1
Вариант 1: Жесткий reset и принудительный толчок
Если вы можете выполнить принудительное обновление без быстрого переадресации на свою ветвь master
в вашем восходящем репозитории, вместо того, чтобы возвращать слияние develop
в master, вы можете просто выполнить жесткий reset 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 OK WITH OTHER DEVELOPERS
git push <remote> master --force
Возможный недостаток для выполнения жесткого reset и принудительного нажатия заключается в том, что если другие
разработчики уже основали работу с фиксацией слияния (т.е. сделали
совершает над ним), тогда им нужно будет переделать ту же самую работу поверх
reset глава master. Это может быть или не быть сложной/дорогостоящей задачей для
их.
Вариант 2: Отменить возврат
Я проверил это с помощью быстрого тестового репо. Я должен подчеркнуть, что он может работа, я не уверен на 100%, что нет никаких случаев, когда я не рассматривать. Поэтому не забудьте проверить его локально с помощью резервного копирования вашего репо первый. Если вы решите использовать это в своем реальном репо, сделайте это самостоятельно риск.
Кроме того, это может быть не простое и простое решение. Его преимущество перед
hard-reset, однако, заключается в том, что он не заставляет разработчиков переделывать
работа над вершиной ветки reset master.
Хорошо, все это в порядке, одна вещь, которую вы могли бы попробовать - это слияние
master в develop, затем верните возврат слияния из develop в
master, затем слейте develop в master, когда вы будете готовы. В командах:
# Coworker accidentally merges develop into master before it 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
Вы можете узнать больше о методе "Восстановить возвращение" на официальном Linux-сервере Документация ядра Git для git revert:
-m parent-number
--mainline parent-numberОбычно вы не можете вернуть слияние, потому что не знаете, с какой стороны Слияние должно рассматриваться как магистраль. Этот параметр указывает родительский номер (начиная с 1) основной линии и позволяет вернуться назад изменить относительно указанного родителя.
Возвращение транзакции слияния объявляет, что вы никогда не захотите, чтобы изменения дерева вызванный слиянием. В результате последующие слияния приведут только к дереву изменения, внесенные коммитами, которые не являются предками ранее повторное слияние. Это может быть или не быть тем, что вы хотите.
Подробнее см. revert-a-faulty-merge How-To.
Ссылка на Как вернуть ошибочное слияние настоятельно рекомендуется, если вы полностью хотят понять, как работает эта техника, это не сложно понять и это на самом деле интересное и увлекательное.