🧬

Pull requests

Вся работа ведётся вокруг ветки 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 из ветки

  1. Необходимо создать Pull request заранее (с первого же commit). В этом есть смысл по разным причинам. В частности — обнаружение ранних конфликтов с другими задачами, которые в процессе
  2. После создания Pull request добавьте в описание задачи в Asana ссылку на него
  3. В процессе работы над веткой дополнять информацией тело pull request. Например, в коде возникли нюансы, и вы не знаете, как правильно поступить. Примите решение, но опишите проблему в pull реквесте, чтобы тот, кто будет делать review, обратил внимание на этот нюанс. Или вы принимаете какие-то важные решения, опишите их
  4. Пример правильно оформленного pull реквеста: (будет позже)
  5. Важно: не берите больше, чем 3 pull requests в работу (по сути, 3 задачи в Asana). Если вдруг у вас 3 pull requests на review, сфокусируйтесь на том, чтобы заканчивать эти pull requests, а не начинать новые (трясите того, кто не сделал ревью, делайте что угодно)

Как смержить pull request в мастер (как закрыть задачу)

Когда вы закончили работать над веткой, убедитесь, что:

  1. Проект собирается, и нет никаких ошибок.
  2. В сделанной работе нет никаких багов. Убедитесь визуально и функционально. Ответственность за баги лежит на вас, не нужно ожидать, что кто-то пройдётся и проверит за вас, всё ли работает. Это ваша работа, не тестировщика, не того, кто делает review.
  3. У ветки нет конфликтов с мастером, её можно слить в мастер одним нажатием.
  4. Поставьте на review одного из разработчиков. В момент передачи вашей ветки на review вы становитесь ответственным за качество кода в этой ветке.
  5. Дождитесь одобрения от разработчика, проверяющего вашу ветку.
  6. Если pull request одобрен, тот, кто делал review, должен слить ветку в master.
  7. После слияния ветку нужно удалить из Github (делает тот, кто сливает).