1136 слов | 3 минуты

WorkFlow

Работа с ветками

Для каждой задачи создаётся отдельная ветка. Перед созданием своей ветки необходимо переключиться на основную ветку проекта main, получить последние изменения с репозитория, после чего создать свою ветку из main ветки.

git checkout main
git pull origin main

Если этого не сделать, то есть вероятность, что будем работать с устаревшим кодом и вносить в него правки. А когда зальем изменения в GitLab и создадите Merge Reauest, то с удивлением обнаружим множество конфликтов, которые же и придется разрешать.

feature/xxxx ветки создаются для работы над поставленными задачами, где xxxx - номер задачи.

# находясь на ветке main
git checkout -b feature/244000

hotfix/xxxx-x ветки создаются для исправления ошибок, обнаруженных самим разработчиком, без постановки задачи.

# находясь на ветке main
git checkout -b hotfix/244000-1
git checkout -b hotfix/244000-2
# ...

Может возникнуть ситуация, когда будет поставлено несколько задач, которые будут связаны друг с другом. Например, по редактированию одного и того же файла, допустим шаблона для страницы новостей:

• 244001 Разработать новый шаблон для компонента вывода новостей
• 244002 Выводить на странице детальной новости рекламный блок
• 244003 Выводить на странице списка новостей рекомендации статей из блога

То есть, для того, чтобы приступить к выполнению задачи 244002 (вывести рекламный блок на странице детальной новости) сначала нужно

• завершить работу над задачей 244001 (разработать новый шаблон страницы новостей)
• слить ветку задачи 244001 с главной веткой

И только после этого можно будет создать новую ветку из главной для выполнения задачи 244002

Оформление коммитов

В начале коммита указывается номер задачи, над которой идет работа. Зачем, если ветка уже содержит номер? Иногда возникают ситуации, когда нужно найти все коммиты, которые были сделаны при решении той или иной задачи. Номер решает проблемы если:

• feature ветки могла быть удалена из репозитория. Например, при слиянии с main веткой (если установлена галочка "Delete source branch when merge request is accepted")
• ветка может быть удалена самим разработчиком, или же администратором репозитория
• когда происходит слияние feature ветки с main, все коммиты из feature ветки "копируются" в ветку main, как будто вся работа производилась именно там. И если в начале каждого коммита будет указан номер задачи, то это значительно облегчает поиск

Заголовок коммита должен отвечать на вопрос "Что делает этот коммит и где?", а не "какие изменения я сделал" или "что было изменено"

Плохие примеры:

• 244001 исправлен баг
• 244002 правки
• 244003 еще правки
• 244003 поработал над компонентом

Хорошие примеры:

• 244001 изменяет время кэширования компонентов на странице новостей
• 244002 исправляет ошибку сортировки товаров в каталоге
• 244003 добавляет логирование ошибок в компоненте stmd:order.ajax

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

Заголовок коммита, он будет показан в общем логе
[пустая строка]
Здесь можно по пунктам перечислить всё, что было сделано в удобном для чтения формате

В общем логе тело коммита будет скрыто, но его можно посмотреть если кликнуть на три точки возле коммита в GitLab

В заголовке коммита используются только строчные буквы. После номера задачи не указываются тире, двоеточия, и другие пунктуационные знаки. Это сильно упрощает читаемость дерева

244001 исправляет ошибку в обработчике на оформление заказа

Это касается только заголовков коммита, тело коммита можно писать в свободной форме

Если коммит делается без поставленной задачи (например hotfix), то номер задачи не указывается, а сразу же пишется заголовок

исправляет ошибку с кэшированием в компоненте stmd:gallery.video

Bitrix

Если для работы необходимо скопировать шаблон компонента или сам компонент то, прежде чем вносить в копию изменения - необходимо оформить коммит

Внимание - вопрос: как проверяющему на code review определить, какие места в коде были затронуты разработчиком, какие файлы новые, а какие просто скопированы с другого шаблона? Проверяющий будет видеть все файлы как новые, как-будто они были созданы и написаны самим разработчиком

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

244001 копирует шаблон .default у bitrix:catalog.section в новый шаблон squared
244001 изменяет разметку и стили шаблона squared у bitrix:catalog.section

Не забываем переодически отправлять свои коммиты в центральный репозиторий GitLab git push origin feature/xxxx. Иногда может потребоваться продолжить работу из другого места, например на другом компьютере из дома

Merge Requests

Каждый разработчик пишет код в отдельной feature ветке. Чтобы код из feature ветки попал в главную main и оказался на боевом сайте их нужно объединить или, по другому, слить (merge)

main ветка является защищенной, в нее не получится просто так взять и через git push отправить изменения. Поэтому, для слияния веток используются специальные запросы - Merge Request-ы

Если задача объемная (например, новый дизайн), то Merge Request оформляется в ветку develop

Бывает, что задача имеет несколько Merge Request-ов. Например, первый MR содержит сам код решения задачи, а второй - исправляет ошибки в нём. Чтобы иметь возможность найти все MR-ы по определенной задаче, в начале заголовка необходимо указывать её номер.

Допустим, мы решаем задачу "244001 Оптимизировать скорость загрузки сайта". Во время её выполнения мы сделали множество коммитов:

• 244001 удаляет неиспользуемые скрипты из header-a
• 244001 оптимизирует подключение скриптов через Assets
• ...
• 244001 оптимизирует подключение шрифтов

Все технические детали решения задачи мы уже описали в коммитах. Теперь, когда мы создаем Merge Request, нам нужно написать для него обобщенный заголовок, который в нескольких словах опишет, что мы делали. Заголовок может быть написан в свободной форме, к нему нет определенных правил. Идеальным вариантом здесь будет "244001 Оптимизация скорости загрузки сайта", как и название самой задачи

Предположим Merge Request был залит на боевой сайт, но выяснилось, что разработчик случайно удалил несколько нужных скриптов, и теперь функционал сайта не работает, нужно это срочно исправлять. Разработчик внес соответствующие правки, зафиксировал их коммитами и снова создал Merge Request. В этом случае заголовок может быть уже таким: "244001 Исправление ошибок после оптимизации скорости загрузки сайта".

В качестве проверяющего (Assignee) выбирается Release Manager

• На сайте GitLab появляется большая синяя кнопка Create merge request. Кликаем по ней.

• Затем рассказываем о своем запросе (поясняем, для чего он делается).
• Указываем автора запроса в поле Assignee.
• Указываем человека, который будет проверять запрос в поле Reviewer.
• Потом указываем Milestone (если используем их).
• Ставим теги.
• И нажимаем на Create merge request.
• Если с запросом все ок, то проверяющий нажмет на кнопку Merge, и весь код перекочует в основную ветку проекта (ну или ту, которую указал автор запроса).

Ответственный за релиз - это переходящая должность, сегодня его роль может исполнять один разработчик, а завтра другой

Если Merge Request оформлен, но задача еще находится в разработке (не доделана), то Merge Request необходимо отметить статусом WIP. Для этого, в самое начало заголовка MR-a необходимо дописать WIP: или кликнуть на ссылку "Start the title with WIP:"

Если работа над задачей закончена, то необходимо снять статус WIP с Merge Request, заполнить отчет в planfix и перевести задачу на статус Code Review

После того как разработчик закончил работу над задачей, проверил её и создал Merge Request, необходимо убедиться, что у MR-a не стоит статус WIP, иначе ответственный за релиз не сможет выполнить слияние веток.

Так же, в карточке задачи в planfix необходимо заполнить поле "Отчет" и перевести задачу в статус Code Review, чтобы уведомить проектного менеджера и TeamLead-а о её готовности к релизу.