Стратегия слияния Git для рабочего процесса Agile Branching

Question

Мы принимаем новую ветвящуюся политику для работы с Agile и позволяем нам выпускать функциональные возможности по функциям, в результате чего у нас есть ветвь master и ветвь как вечные ветви. Ночные сборки будут основаны на QA, а выпуски будут получены от master. Разработчики создадут ветку функций для каждой истории. Все ветви функций должны быть разветвлены master, а затем объединены в QA для тестирования, а затем слияние ветки функций в master для последующего выпуска. Это нормально, до следующего сценария:

• Разработчик A («Род») не создал feature/RodsFeature, провели определенную работу и объединены в QA (но не master)
• Разработчик Б («Джейн») создал feature/JanesFeature, провели определенную работу и сейчас пытается объединить в QA
• слияние конфликтов происходит сейчас Джейн, вызванные изменениями, внесенными в QA путем слияния Прута из feature/RodsFeature

Если Джейн должна была обойти QA и объединить feature/JanesFeature в master, конфликтов не было бы feature/RodsFeature еще не было в master. Однако, по очевидным причинам, Джейн должна объединиться в QA. Чтобы разрешить конфликт, она могла потянуть и интегрировать изменения Рода в свою ветку признаков, разрешить конфликты, а затем выполнить слияние - с нежелательным последствием того, что как только она объединит свою функциональную ветвь в master, она также представит изменения Рода, которые все еще находятся на рассмотрении тестирования QA.

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

Что будет считаться «лучшей практикой» в этой ситуации?

Answer 1

Проверьте Git Flow. Это ближе всего к тому, что вы пытаетесь выполнить.

Разработчики разделили бы свою ветвь с веткой qa (так называемый develop в Git Flow). заполнить их функциональность (регулярно поднимая последнее состояние QA) и объединить обратно до develop, когда это возможно (функция завершена или находится в стабильном состоянии или она отключена).

Что вы используете как ветку qa, вероятно, будет веткой release в Gitflow.

Любое изменение на мастер немедленно сливается с develop.

Смотрите также:

• https://www.atlassian.com/git/tutorials/comparing-workflows/

Answer 2

tl; dr: добавить ветку dev, чтобы выполнить запросы на запросы отдельных ветвей «задачи» с изменениями для отзывов о кодах.

В некоторых командных проектах, в которых я был, был также филиал dev, чтобы выполнять «тянуть запросы» в Github или в каком-либо менеджере хранилища, где старший разработчик просматривает то, что изменилось, и видит, хорошо ли написано это конкретное изменение и т. д.

В интерактивных средах репозитория, таких как Github, у них есть явный ui, демонстрирующий изменения в обратном направлении с оригинальной веткой и т. д. После просмотра ветви старший разработчик затем перемещает ее в ветку Dev, чтобы в конечном итоге быть размещен в среде qa, которая должна быть просмотрена к концу спринта.