Спецификация управления ветками Git

Git

img

Процесс подачи заявки на репозиторий Git
  1. Директор по разработке отправляет заявку на репозиторий Git администратору Git [Почта: отправить администратору Git, копию — менеджеру проекта, форму заявки можно получить у администратора Git]
  2. Администратор Git утверждает заявку руководителя разработки и утверждает следующую конкретную информацию:
    1. Отправляется ли электронное письмо с утверждением копии руководителю проекта
    2. Соответствует ли применяемое имя репозитория Git соглашению об именовании.
  3. В случае одобрения администратор Git выполняет следующие задачи:
    1. Создайте репозиторий Git
    2. Установите руководителя разработки в качестве главной роли репозитория Git (администратор с разрешениями на управление репозиторием Git).
    3. Сообщите руководителю разработки адрес репозитория Git [электронная почта: отправить руководителю разработки, копию — менеджеру проекта]
  4. Если одобрение не будет одобрено, заявка будет отклонена [Почта: отправить руководителю разработки, копию — менеджеру проекта]

Инициализировать репозиторий Git

Шаг 1. Клонируйте удаленный репозиторий

Супервайзер разработки клонирует удаленный репозиторий из Gitlab

Пример команды:

git clone <仓库地址>

Шаг второй: зафиксируйте и отправьте исходную версию

Руководитель разработки отправляет первоначальную версию кода в основную ветку и отправляет ее в систему Gitlab.

image-20190919092114058

Руководитель разработки устанавливает главную ветвь как защищенную ветку в системе Gitlab (защищенная ветвь). Защищенная ветвь не позволяет разработчику отправлять код, но мастер может отправлять код

Пример команды:

# 提交本地修改:
git add .
git commit –m “提交日志”
# 推送 master 分支:
git push origin master

Шаг 3: Создайте ветку разработки

Супервайзер разработки создает ветку разработки (ветку разработки) на главной ветке и отправляет ее в мастер системы Gitlab.

image-20190919092305100

Ветка master, как и ветка development, имеет один и только один

Пример команды:

# 从 master 分支上创建 develop 分支: 
git checkout –b develop master
# 推送 develop 分支:
git push origin develop

Разрабатывайте новые функции

Разработчики реализуют новые функции в ветке разработки, в том числе: новые функции и исправления ошибок.

image-20190919092443274

Пример команды:

# 切换到 develop 分支: 
git checkout develop
# 提交本地修改:
git add .
git commit –m “提交日志”
# 推送 develop 分支:
git push origin develop

Если есть несколько новых функций, которые можно разрабатывать параллельно, руководитель разработки может создать одну или несколько ветвей функций (ветвей функций), соглашения об именах:feature-分支创建日期-新特性关键字,Например:feature-20190919-i18n

image-20190919092649635

Когда новая функция разработана, руководитель разработки должен объединить ветвь функции с ветвью разработки и, наконец, удалить ветвь функции.

Пример команды:

# 从 develop 分支上创建 feature 分支:
git checkout –b feature-20190919-i18n develop
# 合并 feature 分支到 develop 分支: git checkout develop
git merge --no-ff feature
# 删除本地 feature 分支:
git branch –d feature-20190919-i18n
# 删除远程 feature 分支:
git push origin :feature-20190919-i18n
Когда я должен рассмотреть возможность использования функции филиала?
  1. Разработайте новую функцию изолированно (когда закончите, объединитесь с веткой разработки)
  2. Технические исследования и попытки (в случае неудачи ветку функций можно удалить в любой момент)
  3. Реализовать функции, которые необходимо разработать в следующей версии заранее (могут не быть выпущены в этой итерации)

Рекомендуется ветвь функций, но жизненный цикл ветви функций не может охватывать одну итерацию.

Готов выпустить новую версию

Руководитель разработки должен выполнить следующие задачи:

  1. Функция на подтверждение Разработка ветвей, завершена ли разработка

  2. Если разработка завершена, создайте релизную ветку (релизную ветку), правила именования:release-分支创建日期-待发布版本号,пример

    Например: релиз-20190919-v1.0.0

  3. Сначала обновите номер версии Maven в ветке релиза, например: 1.0.0-SNAPSHOT, а затем измените файл version.ini (для удобства в

    Проверьте номер текущей версии при развертывании) и, наконец, сделайте коммит в ветке релиза.

  4. Уведомить тестовый руководителей, что ветвь выпуска может быть протестирована [Email: Отправить в Test Manager, CC к менеджеру проектов и членов команды]

image-20190919092952002

Пример команды:

# 从 develop 分支上创建 release 分支:
git checkout –b release-20190919-v1.0.0 develop

Исправление ошибок в ожидающем релизе

Разработчики исправляют ошибки, присланные себе тестировщиками в ветке релиза.

image-20190919093036529

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

Пример команды:

# 切换到 release 分支:
git checkout release-20190919-v1.0.0
# 提交本地修改:
git add .
git commit –m “提交日志”
# 推送 release 分支:
git push origin release-20190919-v1.0.0

выпустить новую версию

Шаг 1: Интеграционное тестирование

Руководитель тестирования должен выполнить следующие задачи:

  1. Изучите весь код из ветки релиза и настройте среду интеграционного тестирования.
  2. Организуйте тестировщиков для запуска интеграционных тестов в ветке релиза.
  3. Уведомить руководителя разработки о завершении интеграционного теста текущей версии [электронное письмо: отправить руководителю разработки, копию отправить менеджеру проекта]

Шаг 2: Дымовой тест

Руководитель разработки должен выполнить следующие задачи:

  1. Ветка релиза слилась с веткой master и одновременно с веткой разработки.
  2. Напишите руководителю тестирования, чтобы выполнить дымовое тестирование в основной ветке.

Шаг 3. Опубликуйте новую версию

Руководитель разработки должен выполнить следующие задачи:

  1. Измените версию моментального снимка Maven в основной ветке на версию выпуска (удалите суффикс SNAPSHOT)
  2. Добавить журнал выпуска (RELEASE.md)
  3. Создайте тег на главной ветке, правила именования: тег-дата-версия, например: тег-20190919-v1.0.0
  4. удалить ветку релиза
  5. Упакуйте и загрузите частный сервер Maven
  6. Уведомить руководителя тестирования о выпуске новой версии [Электронная почта: отправить руководителю тестирования, копию — менеджеру проекта и администратору Git, формат электронной почты Пожалуйста, попросите администратора Git получить его]

image-20190919094238429

Пример команды:

# 合并 release 分支到 master 分支:
git checkout master
git merge --no-ff release-20190919-v1.0.0
# 合并 release 分支到 develop 分支:
git checkout develop
git merge --no-ff release-20190919-v1.0.0
# 在 master 分支上创建标签:
git tag tag-20190919-v1.0.0
# 删除本地 release 分支:
git branch –d release-20190919-v1.0.0
# 删除远程 release 分支:
git push origin :release-20190919-v1.0.0

Исправление онлайн-ошибок

Шаг 1. Создание ветки исправлений Руководитель разработки должен выполнить следующие задачи:
  1. Создать ветку хотфикса (ветку хотфикса) из тега основной ветки, правила именования: хотфикс-ветка дата создания-будет Номер версии выпуска, например: hotfix-20190919-v1.0.1
  2. Сначала обновите номер версии Maven в ветке исправлений (например: 1.0.1-SNAPSHOT), затем измените файл version.ini и, наконец, в сделать коммит на ветке исправлений
  3. Руководство разработчиков через исправления ошибок
  4. Уведомить руководителя тестирования о необходимости тестирования ветки исправлений [электронное письмо: отправить руководителю тестирования, отправить копию руководителю проекта]

image-20190919094344492

Пример команды:

# 从某个标签上创建 hotfix 分支:
git branch hotfix-20190919-v1.0.1 tag-20190919-v1.0.0
Шаг 2: Убедитесь, что ошибка была исправлена, тестовый руководитель завершает следующие задачи:
  1. Убедитесь, что ошибки исправлены
  2. Уведомить руководителя разработки об устранении ошибки [электронное письмо: отправить руководителю разработки, копию менеджеру проекта]
Шаг 3: Создайте тег и опубликуйте новую версию

Руководитель разработки должен выполнить следующие задачи:

  1. Объедините ветку исправления с основной и разрабатываемой ветками.
  2. Испытание дымом руководителем испытаний
Шаг 4: Отпустите новую версию

Руководитель разработки должен выполнить следующие задачи:

  1. Измените версию моментального снимка Maven в основной ветке на версию выпуска (удалите суффикс SNAPSHOT)
  2. Добавить журнал выпуска (RELEASE.md)
  3. Создайте тег на главной ветке
  4. Удалить филиал для исправления
  5. Упакуйте и загрузите частный сервер Maven
  6. Уведомить руководителя тестирования о выпуске новой версии [Электронная почта: отправить руководителю тестирования, копию — менеджеру проекта и администратору Git, формат электронной почты

Пожалуйста, попросите администратора Git получить его]

image-20190919094509499

Пример команды:

# 合并 hotfix 分支到 master 分支:
git checkout master
git merge --no-ff hotfix-20190919-v1.0.1
# 合并 hotfix 分支到 develop 分支:
git checkout develop
git merge --no-ff hotfix-20190919-v1.0.1
# 在 master 分支上创建标签:
git checkout master
git tag tag-20190919-v1.0.1
# 删除本地 hotfix 分支:
git branch –d hotfix-20190919-v1.0.1
# 删除远程 hotfix 分支:
git push origin :hotfix-20190919-v1.0.1
Что мне делать, если я не могу объединить ветку исправления с основной веткой и веткой разработки?

Например: сейчас на ветке master вышла версия 2.0.0 (структура кода претерпела большие изменения), но в сети обнаружен баг версии 1.0.0, при модификации бага его нельзя слить в master и девелопмент. Для филиалов руководителю разработки необходимо выполнить следующие задачи:

  1. Создайте ярлыки непосредственно на филиал для исправления
  2. Удалить ветку хотфикса (ветка удаляется, пока тег есть, версию можно найти обратно)
  3. Вручную изменить код в ветке разработки (для объединения с веткой master для последующих выпусков).

Индивидуальный проект

Когда вам нужно настроить проект, вы можете разветвить новый репозиторий Git из репозитория Git исходного проекта:

image-20190925212426543

После форка любые изменения, внесенные в repo1, не повлияют на repo2. Исправлены ошибки в repo2, которые можно отправить в repo1 через мерж-реквест. Коммиты в repo1 могут быть извлечены в любое время в repo2, но repo1 не может получить коммиты в repo2.

приложение

Номер версии Maven Спецификация именования

Формат: Major.minor.micro.

Версия инструкция
Основная версия Корректировка архитектуры
Второстепенная версия новые возможности
Micro версия Исправления ошибок и оптимизации

Тип ветки Git

филиал использовать
главная ветвь (главная ветвь) стабильная версия
Разработать филиал (филиал развития) Последняя версия
ветка релиза (ветка релиза) выпустить новую версию
ветка исправлений (ветка исправлений) Исправление онлайн-ошибок
функциональная ветвь (функциональная ветвь) Внедряйте новые функции

image-20190919095107028

Соответствие между ролями Gitlab и ролями проекта

Роли Gitlab Роль проекта
Владелец Git-администратор
Мастер (администратор) супервайзер по развитию
Разработчик Разработчик
Репортер (репортер) Тестеры
Гость (наблюдатель) другой персонал

Git обязанности администратора и директора по развитию

Git-администратор супервайзер по развитию
Создайте репозиторий Git Управление ветками проекта
Проверьте спецификацию ветки Git Управление участниками
Обслуживание системы Gitlab Управление тегами

Источник: спецификация управления ветками Git.

Категории