🧬

Pull requests

Вся работа ведётся вокруг ветки master в краткосрочных feature-ветках, с каждой из которых связан pull request. По завершении работы над задачей ветка передаётся на review другому разработчику.

Создание ветки

  • Для pull request мы создаём ветку в формате %ISSUE_NUMBER%_-%ISSUE_HEADER%.
  • Например, если у issue #25 с заголовком Quest Tweaks Part 1, то ветка будет называться 25-quest-tweaks-part-1.

Коммиты

  • Нужно по возможности избегать «толстых» коммитов. В идеале каждый коммит должен содержать только одно логическое изменение. Чем меньше изменяется код от одного коммита к другому, тем быстрее и проще его проверять и выявлять потенциальные недостатки.
  • Не бойтесь пушить коммиты, которые не компилируются, не собираются и даже не читаются линтером. Вы — хозяин своей ветки на протяжении всего периода работы над задачей. Коммиты нужны для фиксации логических изменений в первую очередь, и только потом для обеспечения сборки проекта.
  • Не смешивайте форматирование кода с функциональными изменениями внутри одного коммита. Если вы хотите изменить и то, и другое, отправьте два разных коммита.
  • Мы не держим долго код у себя в локальной копии. Пушим коммиты в Github репозиторий чем чаще, тем лучше. Дайте тимлиду, команде видеть вашу работу в процессе.

Создание Pull request из ветки

  1. Необходимо создать Pull request заранее (с первого же commit). В этом есть смысл по разным причинам. В частности — обнаружение ранних конфликтов с другими задачами, которые в процессе.
  2. После создания Pull request добавьте в описание задачи в Asana ссылку на него.
  3. В процессе работы над веткой дополнять информацией тело pull request (самый верхний, первый комментарий). Например, в коде возникли нюансы, и вы не знаете, как правильно поступить. Примите решение, но опишите проблему в pull реквесте, чтобы тот, кто будет делать review, обратил внимание на этот нюанс. Или вы принимаете какие-то важные решения, опишите их.
  4. Для быстрого доступа к issue, с которым связан новый pull request, нужно при создании pull request указать в комментарии номер issue в формате Resolves #%ISSUE_NUMBER%. Например: Resolves #55. Это в том числе автоматически закроет Issue при мерже Pull в мастер.
  5. Мы не пишем задачи в pull request. Сами задачи хранятся в Issue (в виде ссылки на Asana).
  6. Пример правильно оформленного pull реквеста:
  7. image

  8. Важно: не берите больше, чем 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 (делает тот, кто сливает).