Возврат коммита git merge, затем возвращение возврата

Question

Наша команда использует Github Pull Requests для управления нашим рабочим процессом, очень похоже на , что описано здесь . После проверки принятого запроса на извлечение вручную нам иногда необходимо отменить это объединение, поскольку оно не готово к развертыванию на наших производственных серверах.

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

Поскольку Github не поддерживает эту функцию (т. Е. Не отменяет слияние и не отменяет / не перевыпускает первоначальный запрос на извлечение), в настоящее время я возвращаю отмененное слияние. Это чувствует себя неправильно.

Какие еще способы я мог бы использовать для достижения той же цели в git? (или Github, если это возможно)

Answer 1

Я думаю, что ваша проблема здесь возникает, потому что, когда вы имеете дело с запросами на получение, вы выбираете автоматическое объединение их в GitHub.Из трех предложенных способов обработки запросов на выборку , описанных в документации , вы используете последний («Автослияние»), который был только недавно реализованным .Лично я думаю, что это подходит только для тривиальных запросов, которые, очевидно, верны.Для чего-то более сложного, я хотел бы использовать первый подход, то есть

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

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

---

Интересно, возможно, стоит рассказать подробнее о том, что произойдет, если вы делаете в конечном итоге придется отменить прискорбное слияние, но при этом все равно нужно иметь возможность повторно объединить более позднюю версию этой ветви.Хотя это может показаться неправильным, насколько я понимаю, самый простой способ справиться с этой ситуацией - это действительно вернуть назад.Вы можете найти более подробное обсуждение этой проблемы в этом посте из блога Pro Git и в другом обсуждении этой же проблемы в Linux Torvalds, которое также может быть полезным.

Answer 2

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

дальнейшее чтение: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Пожалуйста, смотрите комментарии также для получения дополнительной информации.Это работает очень хорошо для нас.

Answer 3

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

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

master изначально разветвлен от develop. Как только develop находится в стабильном состоянии, вы объединяете его в master. master является текущей стабильной версией.

Это свободно основано на nvie "Успешная модель ветвления Git" .