Наш рабочий процесс GIT

Обзор

dev merge to master запускает CI, предварительная версия

Следующая итеративная функция, то есть функция, которая на этот раз не подключена к сети, и функция расширенной разработки, используют эту функцию, обратите внимание на использование следующей команды для слияния.

git merge --no-ff

Online Bug использует ремонт исправления, комбинируемый обратно в ветку PROD и DEV

Подробности

Исходя из текущей ситуации и привычек нашей команды, согласованные возможные ответвления Git следующие:

1. prod используется для производственного развертывания и должен быть помечен
   
2. master используется для CI, предназначен для обеспечения стабильной тестовой среды,
   
3. dev объединяет разработку функции этой итерации с мастером, и у разработчиков есть разрешение
4. Функция разработки на основе функции следующего итерационного dev, функции одной ветви, слияния в dev, имя формата: функция - $ {Functional Возьмите английское имя}
5. 
   

Следующий подробный рабочий процесс:

1. Предполагая, что функция запуска на этой неделе определена в понедельник, разработчики уточнили свои задачи по разработке.
2. Все разработчики работают в среде разработки, используют фиктивный интерфейс во внешнем интерфейсе и локально тестируют интерфейс в бэкэнде.
3. После того, как обслуживающий персонал разработал все интерфейсы полной функции, слейте код с мастером, нажмите триггер CI и уведомите внешний персонал о том, что реальный интерфейс может быть подключен.
4. Соответствующий внешний персонал отлаживает реальный интерфейс и после завершения объединяется с мастером, нажимает для запуска CI и уведомляет соответствующий внутренний персонал для проверки друг друга.
5. Если все пойдет хорошо и все пойдет по плану, в пятницу соответствующий персонал объединит ветку master с prod и поставит тег для облегчения отката, а затем ее можно будет развернуть в продакшене.
6. Частный случай 1: в среду разработчик получил новое требование, и это требование будет запущено в следующей итерации. Из-за высокой эффективности соответствующих разработчиков функции этой недели были разработаны в это время, поэтому было решено разработать заранее, после чего соответствующие разработчики проверят ветку feature-xxx на основе ветки dev, которая не будет влияет на этот релиз, он будет объединен в следующую итерацию. ветка dev, удалите ветку после слияния
7. Частный случай 2: При разработке новых функций в dev в следующий понедельник обнаруживается, что в версии, вышедшей в прошлую пятницу, есть две ошибки, которые необходимо срочно исправить.После взвешивания одну нужно исправить в этот же день, а другую должен быть в сети на следующий день.Тогда ветка первой ошибки - это исправление-${tag}-1, а вторая - исправление-${tag}-2. Затем соответствующий персонал проверяет две ветки на основе prod и после модификации и проверки объединяет их в ветки dev и prod, а затем позволяет соответствующему персоналу пометить, выпустить производство и удалить ветку после проверки производства.

объяснять

Приведенный выше процесс и изображения относятся к классическим статьям.a-successful-git-branching-model, картина была частично изменена. Большинство статей в Интернете о Git Workflow, идеях и контенте взяты из этой статьи, особенно картинки в ней, которые когда-то назывались богами.

На самом деле в этой статье есть два момента, которые не соответствуют нашим рекомендациям:

1. dev выполняет ночную сборку Мы делали то же самое и раньше, но на этапе совместной отладки интерфейса, как только бэкенд запушит код, CI будет пересобран, в результате чего интерфейс станет недоступен, а все фронтенды будут заблокированы . Во время проверки среды разработки бэкенд или тестер проталкивает код во фронтенд, из-за чего веб-приложение становится недоступным, а все проверки блокируются. Это сильно влияет на опыт разработки/тестирования, вплоть до влияния на настроение, поэтому отмените CI для разработки и выполняйте CI только для мастера.
2. Название релизов может ввести в заблуждение. В этой статье релиз на самом деле является веткой предварительного выпуска, которая используется для проверки перед выходом в онлайн, но наши участники говорили, что это ветка релиза, которая специально использовалась для онлайн-релиза. Чтобы устранить различия, в соответствии с текущим размером команды, было решено использовать master в качестве стабильной версии, в качестве проверочной ветки перед переходом в онлайн, и prod в качестве реальной онлайн-ветки, и пометить ее перед выходом в онлайн.

Этикетка

теги следуют следующим соглашениям

Имя тега: v номер версии(major.minor.patch)

Название: Название проекта - Дата