Система контроля версий Git

В соответствии с предложанной ранее архитектурой и привычным для меня устройством серверов, в работе использую три основные ветки гита для каждого проекта:

1. master копия файловой структуры боевого проекта без ядра
2. preprod ветка с прохождением кодревью, для последующей выгрузки наработок на боевой сайт
3. test копия файловой структуры боевого проекта без ядра, для демонстраци и приёмки наработок

Как работать с гитом

Есть как минимум пара вариантов - это консоль в нативном клиенте git bash с использованием консольных команд, либо полуавтоматическая работа в средах разработки IDE. Лучший вариантом считаю консоль.

Общий порядок действий

Заходим в нужный репозиторий и забираем ссылку для работы по ssh/https, клонирую репозиторий на локальную машину, разворачиваю проект.

1. Создаем новую ветку на основе master
2. Работаем с новой веткой, доработка, добавление контента и т.д.
3. Слияние новой ветки с веткой test и отправка изменений на стенд. На схеме пункт 1
4. Тестирование на тестовом стенде, исправление багов, если они выявлены входе тестирования
5. Слияние с веткой preprod и отправка изменений. На схеме пункт 2
6. Принятие работ заказчиком на preprod стенде
7. Слияние ветки с master и отправка изменений. На схеме пункт 3

Важно соблюдать читаемость всего огромного хозяйства, где можно отыскать в последствии изменения по каждому проекту, в каждой ветке и по каждой из задач. Комментарии оставляю на понятном в компании языке для подавляющего большинства, русский/английский.

Оптимальное название ветки

1. Название ветки дает четкое и ясное представление о том, что делает содержащийся в ветви код
2. Написано в нижнем регистре, за исключением номера задачи. Указываем номер в неизменном виде и краткое описание
3. Состоит только из букв и цифр a-z, 0-9, не содержит специальных символов, при необходимости разделяем дефисами -
4. Название ветки начинается с прификса того, что ветка делает:
   feature разработка нового функционала
   content изменения в контенте сайта, подготовка новых страниц и корректировка существующих
   hotfix используется для быстрого исправления критических багов, которые попали в master

Примеры корректных названий:

// ветка для нового функционала, описанной в тикете CDD-848
feature/CDD-848-add-sidebar
// ветка для изменения в контенте, описанной в тикете CDD-848
content/CDD-848-new-content-sidebar

Оптимальное название коммита

Я всегда разбиваю недекомпозированные задачи на отдельные микрозадачи и описываю каждый коммит кратко и конкретно:

• Что сделано в коммите
• Что делает коммит
• Что меняет коммит

Например у меня есть задание, которое состоит из трех пунктов:

1. Сменить синий цвет кнопки на продающий красный в форме отправки заявки
2. В каталоге поменять заголовок
3. Добавить 10 новых товаров в базу данных и настроить компонент для корректного вывода

В гит точно попадёт первая и вторая задачи, причем они будут разделены коммитами. Соответственно, выполнив первую часть нужно отправить в гит новый коммит примерно с таким комментарием:

CDD-848 - поменял цвет фона кнопки в форме заявки на ImperialRed #ed2939

Пример корректного коммита:

CDD-848 - новые стили для главного меню

Слияние веток для разработчиков

После того, как поработал с задачей, нужно отправить изменения из отдельной ветки созданной ранее в основную ее ветку. Проще всего перейти в интерфейс GitLab, где находим текущий проект и создать запрос на слияние Merge Request.

Переходим в раздел Merge Requests и нажимаем кнопку New merge request. В открывшемся окне выбираем исходную ветку и целевую. После этого нажимаем Compare branches and continue.

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

После того, как все готово, нажимаем Submit merge request. Теперь MR создан и готов к проверке. Уведомления о новом запросе на слияние получат все, кто подписан на уведомления в данном проекте. Проверяющий просмотрит изменения, может оставить комментарии и внести правки.

Если что-то не так, придет сообщение о проблеме, на которую нужно обратить внимание, MR нужно будет отозвать для внесения доработок по задаче. После исправления запрос отправляется повторно, указав что учтены замечания и исправлены.

Если всё в порядке, запрос на слияние будет принят, и изменения будут внедрены в основную ветку которая была указана при именовании новой ветки на этапе создания, но перед этим пройдет все тесты на тестово-демонстрационном сервере.