git ветвление слияния для исправлений - PullRequest
Новая
       102

git ветвление слияния для исправлений

1 голос
/ 29 января 2020

У нас есть 3 филиала (master, acpt, devl) и соответствующие среды: production, acpt и devl. В нашей команде несколько разработчиков. Попытка выяснить, как лучше всего использовать модель разработки для решения следующего сценария

, devl имеет следующие коммиты: A, B, C
acpt has: A
master имеет: A

У меня есть фиксация исправлений, которую нужно передать мастеру. Я создал новую ветку под названием hotfix с использованием master, внес изменения с помощью commit D.

Должен ли я объединить ветку hotfix с master, acpt и devl? Я предполагаю, что слияние с Acpt и Master будет работать нормально. Но поскольку devl уже продвинулся до C, будет ли у devl A, D, B, C или A, B, C, D? Попытка выяснить лучшую практику.

1 Ответ

1 голос
/ 29 января 2020

Примечание: Рэймонда Чена "Прекратить сбор вишни, начинайте слияние" описывает это лучше, чем я могу в пространстве, которое у меня есть.

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

Вы описали три группы, которые имеют доступ к общему репозиторию, как имеющие доступ к трем коммитам , Это не очень реалистичный сценарий c: типичный Git репозиторий к этому моменту будет иметь сотни или тысячи коммитов. Достаточно нарисовать проблему, но я думаю, что лучше нарисовать, скажем, шесть или более коммитов. Для начала я нарисовал восьмерку ниже.

(я также не буду использовать названия ваших веток; на самом деле, я просто начну с одного).

Давайте нарисуем что у нас может быть: 

                   I--J--K   <-- develop
                  /
...--D--E--F--G--H   <-- tag:v1.0

Тег v1.0 - это конкретный коммит, выпущенный как версия 1.0. Тем временем разработчики продолжили разработку и сделали три новых коммита.

Теперь заказчик звонит в службу поддержки и говорит, что в какой-то конкретной команде или функции есть какая-то конкретная ошибка. Эта ошибка теперь зарегистрирована как ошибка # 1234. Служба поддержки и / или разработчики анализируют ошибку и обнаруживают, что ошибка была введена в коммите F. Вот что они должны делать: 

                  I--J--K   <-- develop
                 /
             G--H   <-- tag:v1.0
            /
...--D--E--F   <-- fixes/bug-1234

То есть теперь у нас есть новое имя ветви в пространстве имен fixes/ с идентификатором ошибки в нем. Теперь мы придумали исправление для ошибки и зафиксировали его, сделав новый коммит с новым уникальным идентификатором ha sh. Тем временем группа разработчиков уже добавила новый коммит L: 

                  I--J--K--L   <-- develop
                 /
             G--H   <-- tag:v1.0
            /
...--D--E--F--F1   <-- fixes/bug-1234

Мы тестируем исправление, возможно, объединяя его в коммит H в новой ветке кандидата на выпуск (rc/1.1), и Передача полученного коммита слияния группе тестирования: 

                    I--J--K--L   <-- develop
                   /
               G--H   <-- tag:v1.0
              /    \
             /   _--M   <-- rc/1.1
            /   /
...--D--E--F--F1   <-- fixes/bug-1234

Если все идет хорошо, кандидат на выпуск 1.1 становится релизом с тегом 1.1 (возможно, после добавления дополнительных исправлений, но здесь они не прорисованы): 

                 I--J--K--L   <-- develop
                /
               G--H   <-- tag:v1.0
              /    \
             /   _--M   <-- rc/1.1, tag:v1.1
            /   /
...--D--E--F--F1   <-- fixes/bug-1234

(На данный момент имя ветки-кандидата релиза можно удалить - оно больше не приносит никакой пользы. Оно просто для проверки M и, возможно, других слияний.)

Это теперь пришло время объединить фиксацию F1, исправление ошибки, с основной разработкой. Это трудно нарисовать! Вот попытка: 

                 I--J--K--L------__
                /                  \
               G--H   <-- tag:v1.0  \
              /    \                 \
             /   _--M   <-- tag:v1.1  \
            /   /_____-----------------N   <-- develop
...--D--E--F--F1   <-- fixes/bug-1234

Если обнаружена ошибка в коммите D или E или G, мы можем пометить этот коммит с помощью fixes/bug-1235, исправить его и объединить исправление в кандидату на выпуск и / или в ветку develop. Чертеж получит очень беспорядочно, но Git сделает лучшее из возможного слияния, автоматически, в каждом случае.

Также относительно легко автоматически определить, какие теги и / или ветви содержат исправление, в которое они включены. Фиксация F1 в настоящее время происходит от develop, поэтому она объединена там. Это равно в теге происхождения v1.1 и не в происхождении тега v1.0, поэтому клиенты с v1.0, имеющие ошибку # 1234, должны перейти на v1.1 .

...