Вся работа ведётся вокруг ветки master в краткосрочных feature-ветках, с каждой из которых связан pull request. По завершении работы над задачей ветка передаётся на review другому разработчику.
- В описании пул реквеста должна быть ссылка на задачу Asana
- Источник правды по задачам: описание и комментарии в Asana
- Описание пула содержит концентрированую информацию по задаче Asana
- Название пула совпадает с названием карточки Asana
Создание ветки
- Для pull request мы создаём ветку в формате
%YYYY-MM-DD%-%PULL_HEADER%
. - В качестве разделителей в названии используется тире
- Например, задачу с заголовком
Фиксы релиза 328
, то ветка можно назвать2023-01-31-fixes-release-328
Коммиты
- Нужно по возможности избегать «толстых» коммитов. В идеале каждый коммит должен содержать только одно логическое изменение. Чем меньше изменяется код от одного коммита к другому, тем быстрее и проще его проверять и выявлять потенциальные недостатки
- Не бойтесь пушить коммиты, которые не компилируются, не собираются и даже не читаются линтером. Вы — хозяин своей ветки на протяжении всего периода работы над задачей. Коммиты нужны для фиксации логических изменений в первую очередь, и только потом для обеспечения сборки проекта
- Не смешивайте форматирование кода с функциональными изменениями внутри одного коммита. Если вы хотите изменить и то, и другое, отправьте два разных коммита
- Желательно что-бы коммит соответствовал правилу единой ответственности
- Мы не держим долго код у себя в локальной копии. Пушим коммиты в Github репозиторий чем чаще, тем лучше. Дайте тимлиду, команде видеть вашу работу в процессе
- Для единого подхода в проекте, желательно для описания коммитов использовать русский язык, допуская англоязычные термины
Создание Pull request из ветки
- Необходимо создать Pull request заранее (с первого же commit). В этом есть смысл по разным причинам. В частности — обнаружение ранних конфликтов с другими задачами, которые в процессе
- После создания Pull request добавьте в описание задачи в Asana ссылку на него
- В процессе работы над веткой дополнять информацией тело pull request. Например, в коде возникли нюансы, и вы не знаете, как правильно поступить. Примите решение, но опишите проблему в pull реквесте, чтобы тот, кто будет делать review, обратил внимание на этот нюанс. Или вы принимаете какие-то важные решения, опишите их
- Пример правильно оформленного pull реквеста: (будет позже)
- Важно: не берите больше, чем 3 pull requests в работу (по сути, 3 задачи в Asana). Если вдруг у вас 3 pull requests на review, сфокусируйтесь на том, чтобы заканчивать эти pull requests, а не начинать новые (трясите того, кто не сделал ревью, делайте что угодно)
Как смержить pull request в мастер (как закрыть задачу)
Когда вы закончили работать над веткой, убедитесь, что:
- Проект собирается, и нет никаких ошибок.
- В сделанной работе нет никаких багов. Убедитесь визуально и функционально. Ответственность за баги лежит на вас, не нужно ожидать, что кто-то пройдётся и проверит за вас, всё ли работает. Это ваша работа, не тестировщика, не того, кто делает review.
- У ветки нет конфликтов с мастером, её можно слить в мастер одним нажатием.
- Поставьте на review одного из разработчиков. В момент передачи вашей ветки на review вы становитесь ответственным за качество кода в этой ветке.
- Дождитесь одобрения от разработчика, проверяющего вашу ветку.
- Если pull request одобрен, тот, кто делал review, должен слить ветку в master.
- После слияния ветку нужно удалить из Github (делает тот, кто сливает).