Спецификация дизайна ветки Git

Обзор

В этой статье представлена спецификация дизайна ветки Git для справки разработчиков.

Нормы мертвы, люди живы, я надеюсь, что нормы, установленные самим собой, не будут оплеваны.

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

короткое имя	полное имя
DEV	Development environment
FAT	Feature Acceptance Test environment
UAT	User Acceptance Test environment
PRO	Production environment

Среда DEV: используется для отладки разработчиком.
Среда FAT: функциональная среда приемочного тестирования, используемая тестировщиками программного обеспечения в тестовой среде.
Среда UAT: среда приемочного тестирования пользователем, используемая для тестирования тестировщиком программного обеспечения в производственной среде.
Среда PRO: производственная среда.

Например, доменное имя проекта:http://www.abc.com, то доменное имя соответствующей среды можно настроить следующим образом:

Среда DEV: настройте имя виртуального домена локально
FAT-среда:http://fat.abc.com
УАТ-среда:http://uat.abc.com
ПРО среда:http://www.abc.com

Затем спроектируйте ветки для разных сред.

филиал

филиал	название	окрестности	доступный
master	главная ветвь	PRO	да
release	предстартовая ветвь	UAT	да
hotfix	ветвь аварийного исправления	DEV	нет
develop	тестовая ветвь	FAT	да
feature	Филиал разработки требований	DEV	нет

главная ветвь

masterОсновная ветвь используется для развертывания в официальной среде (PRO), как правило,releaseилиhotfixВетки объединены, ни при каких обстоятельствах вам не разрешается изменять код непосредственно в основной ветке.

выпускная ветвь

releaseэто предзапусковая ветвь для развертывания в предзапусковой среде (UAT), всегда сохраняющая одну и ту жеmasterВетви согласуются, как правило, поdevelopилиhotfixСлияние веток, не рекомендуется непосредственно вreleaseИзмените код прямо в ветке.

если вreleaseВозникла проблема с тестом ветвления, и требуется регрессионная проверка.developBranch, чтобы узнать, существует ли эта проблема.

ветвь исправлений

hotfixДля ветвей экстренных исправлений используется соглашение об именахhotfix-начало.

Когда в сети возникает срочная проблема, которую необходимо решить немедленно, она должна основываться наreleaseилиmasterсоздание веткиhotfixВетку, после завершения фикса сливаем вreleaseилиdevelopBranch и удалите его, как только исправление станет доступным.

развивать филиал

developДля тестовой ветки, используемой для развертывания в тестовой среде (FAT), всегда сохраняйте последний завершенный код с исправленными ошибками, который можно определить в соответствии с размером требований.featureФилиал сливают, либо развивают прямо на нем.

Только код, который удовлетворяет тесту, может быть объединен или отправлен на него.

функциональная ветвь

featureРазрабатывайте ветки для требований, правила именованияfeature-Сначала удалите требование, как только оно будет запущено.

Это может быть немного сложно понять, поэтому вот несколько сценариев разработки.

сцена разработки

добавлены новые требования

Существует новое требование к управлению заказами, которое необходимо разработать, сначала создайтеfeature-orderВетвь, вопрос, на какой ветке основана эта ветка?

Если есть непроверенные требования, основанные наmasterСоздайте.

Если нет непроверенных требований, основанных наdevelopСоздайте.

нуждается вfeature-orderКогда ветка разработана и готова к тестированию, ее необходимо определить в первую очередьdevelopНет непроверенных требований, тогда разработчики могут объединить код вdevelop(Тестовая среда) для тестирования тестировщиками.
тестировщикиdevelop(Тестовая среда) После прохождения теста разработчики выпустят код дляrelease(Среда перед запуском) для тестирования тестировщиками.
тестировщикиrelease(Предстартовая среда) После прохождения теста разработчики выпустят код дляmaster(формальная среда) для тестирования тестировщиками.
тестировщикиmaster(Формальная среда) После прохождения теста персоналу НИОКР необходимо удалитьfeature-orderфилиал.

нормальная итерация

Существует итеративное требование для управления заказами, если человеко-час разработки developДля разработки, если работа по разработке > 1d, то вам нужно создать ветку и развиваться на ветке.

Тестирование после разработки и онлайн-процесс соответствуют процессу добавления новых требований.

Исправление ошибок тестовой среды

существуетdevelopВ тесте есть ошибка, если время ремонта developРемонт, если время ремонта > 2 часов, необходимо отремонтировать в филиале.

Исправленный тест и онлайн-процесс аналогичны процессу добавления новых требований.

Изменить ошибки среды перед запуском

существуетreleaseВ тесте есть баг, в первую очередь его надо вернутьdevelopВ филиале такая же проблема.

Если он существует, процесс исправления аналогичен процессу устранения ошибки тестовой среды.

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

Изменить официальные ошибки среды

существуетmasterВ тесте есть баг, в первую очередь его надо вернутьreleaseиdevelopВ филиале такая же проблема.

Если он существует, процесс исправления аналогичен процессу устранения ошибки тестовой среды.

Если его нет, то эта возможность относительно невелика, и большинство из них — это проблемы совместимости данных, проблемы с конфигурацией среды и т. д.

Срочно исправить ошибки официальной среды

Баги не проверялись в процессе тестирования, а баги появились после запуска в течение определенного периода времени, которые нужно срочно исправлять.

Я лично понимаю, что аварийный ремонт означает, что нет времени на проверку тестовой среды, но все же рекомендуется проверить среду перед запуском.

еслиreleaseЕсли в ветке есть непроверенные требования, она основывается наmasterСоздайтеhotfix-xxxфилиал и опубликовать вmasterпроверка, после проверкиmasterкод объединен вreleaseиdevelopразветвить и удалитьhotfix-xxxфилиал.
еслиreleaseВ ветке нет непроверенных требований, ноdevelopЕсли в ветке есть непроверенные требования, она основывается наreleaseСоздайтеhotfix-xxxфилиал и опубликовать вreleaseПроверка, последующий процесс соответствует онлайн-процессу, после проверкиmasterкод объединен вdevelopразветвить и удалитьhotfix-xxxфилиал.
еслиreleaseиdevelopВ ветке нет непроверенного требования, просто прямо вdevelopПосле завершения исправления в ветке опубликуйте наreleaseПроверка, последний процесс такой же, как онлайн-процесс.

Параллельное тестирование

В проекте параллельно разрабатывались два требования, и они параллельно тестировались, но сроки запуска были разные.

Два варианта, о которых я могу думать:

Разверните еще один набор веток для тестирования тестировщиками.
использоватьgit cherry-pick«Выбери и выбери» совершает

У вас есть хорошее решение для параллельного тестирования? Добро пожаловать, чтобы оставить сообщение.

Спецификация журнала фиксации

Информация должна быть заполнена внимательно!

Предлагаемая справочная спецификация:<type>(scope)：<subject>

Например: исправить (модуль домашней страницы): исправить всплывающие ошибки JS.

typeУказывает тип действия, которое можно разделить на:

исправить: исправить ошибку ххх
подвиг: добавить функцию xxx
тест: функция отладки xxx
стиль: изменить формат кода xxx или комментарий
документы: изменить документы xxx
рефакторинг: функция или метод рефакторинга xxx

scopeУказывает область влияния, которую можно разделить на: модули, библиотеки классов, методы и т.д.

subjectУказывает краткое описание, желательно не более 60 слов, при наличии номера Jira соответствующего бага рекомендуется добавить его в описание.

резюме

Это все, что я могу придумать на данный момент Спецификации не статичны для справки.