Git - конфликты между ветками функций - как избежать, чтобы ветка функций содержала изменения в другой ветке функций

Question

Сценарии следующие.Я буду использовать t1, t2, t3 и т. Д. Для представления разного времени:

У меня есть две ветви, чтобы представить ветвь DEV моей среды, ветвь MASTER.

t1: я создал ветку Feature_001 изMASTER

t2: я добавил коммиты в ветку Feature_001, слил код в DEV и запихнул его.

t3: по какой-то причине мой менеджер сказал мне, чтобы я прекратил разработку ветки Feature_001

t4: прошел один месяц.Моя коллега Клэр создала ветку Feature_002 из MASTER.

t5: Клэр добавила коммиты в ветку Feature_002, попыталась объединить свой код с веткой DEV и протолкнула его.Тем не менее, конфликт появляется, когда она нажимает.

t6: Клэр затем вытягивает и объединяет изменения из ветви DEV в свою ветку Feature_002 ( моя проблема происходит в этот момент ).Она сделала новый коммит для разрешения конфликта в ветке Feature_002.После этого Клер слила свой код в DEV и нажала.

t7: После тестирования менеджер Клер говорит, что теперь все в порядке, чтобы присоединиться к ветке MASTER.Итак, Клэр объединила ветку Feature_002 в ветку MASTER.

t8: Хотя разработанный Feature_002 Clair функционирует в производственном процессе, Feature_001 также непреднамеренно появляется в производственном процессе, поскольку ветвь Feature_002 однажды объединила код из DEV в себя, чтобы разрешить конфликты.Наш менеджер был шокирован и начал задавать вопросы, кто осмелился выпустить Feature_001 на производство !?

t9: встреча и встреча навсегда, чтобы обсудить, что произошло ...

Если вы хорошо следите за сценарием, вы можете найти его из-за конфликтов между ветвями функций, ветка Feature_002 будет включать изменения вветвь Feature_001 после того, как Клер вытащил код из DEV.

Мой вопрос как сохранить две ветви функций независимо, позволяя нам разрешать конфликты между ними ?

Любые отзывы и обсуждения приветствуются.

РЕДАКТИРОВАТЬ 20180925:

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

Answer 1

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

Answer 2

Ветвь Feature_001 не должна была объединяться с DEV до тех пор, пока Feature_001 не будет завершена и не будет утвержден запрос на извлечение.Конфликты должны быть разрешены после слияния Feature_001 с DEV, а не до этого, это позволит избежать проблемы, с которой вы столкнулись, когда ветвь Feature_002 имела некоторый зафиксированный код из Feature_001.В идеале Feature_001 должен быть небольшим или разбит на более мелкие функции, такие как Feature-001-S-xxxxxx-MyStoryDescription, для удобства отслеживания.Кроме того, поскольку ваша ветка Feature-001 может иметь много коммитов, рекомендуется сдавить ваши коммиты перед выполнением запроса на извлечение и перебазировать вашу ветку в случае конфликта слияния.Удачного кодирования!

Answer 3

Я вижу ряд проблем там.Если функция 001 больше не должна разрабатываться ... даже если отброшена, скажем, она должна быть удалена из ветки dev.Учитывая, что этого не произошло, когда вы объединяете dev (через функцию 002) с мастером (еще одна проблема, я предполагаю, что этого не должно происходить), потому что функция 001 не была удалена, она приземлилась в master.

Так .... как этого избежать?Все скажут разные вещи.Мой взять?Когда вы получили уведомление о том, что функция 0001 должна была быть остановлена, она должна была быть удалена из ветви dev (либо путем переписывания истории разработки, чтобы избежать слияния, либо путем возврата изменений 0001).И потом, я думаю, вы не должны сливаться из dev в master ... но это всего лишь предположение, потому что это действительно зависит от вашего рабочего процесса.