Вся работа ведётся вокруг ветки 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 из ветки
- Необходимо создать Pull request заранее (с первого же commit). В этом есть смысл по разным причинам. В частности — обнаружение ранних конфликтов с другими задачами, которые в процессе.
- После создания Pull request добавьте в описание задачи в Asana ссылку на него.
- В процессе работы над веткой дополнять информацией тело pull request (самый верхний, первый комментарий). Например, в коде возникли нюансы, и вы не знаете, как правильно поступить. Примите решение, но опишите проблему в pull реквесте, чтобы тот, кто будет делать review, обратил внимание на этот нюанс. Или вы принимаете какие-то важные решения, опишите их.
- Для быстрого доступа к issue, с которым связан новый pull request, нужно при создании pull request указать в комментарии номер issue в формате
Resolves #%ISSUE_NUMBER%. Например:Resolves #55. Это в том числе автоматически закроет Issue при мерже Pull в мастер. - Мы не пишем задачи в pull request. Сами задачи хранятся в Issue (в виде ссылки на Asana).
- Пример правильно оформленного pull реквеста:
- Важно: не берите больше, чем 3 pull requests в работу (по сути, 3 задачи в Asana). Если вдруг у вас 3 pull requests на review, сфокусируйтесь на том, чтобы заканчивать эти pull requests, а не начинать новые (трясите того, кто не сделал ревью, делайте что угодно).
Как смержить pull request в мастер (как закрыть задачу)
Когда вы закончили работать над веткой, убедитесь, что:
- Проект собирается, и нет никаких ошибок.
- В сделанной работе нет никаких багов. Убедитесь визуально и функционально. Ответственность за баги лежит на вас, не нужно ожидать, что кто-то пройдётся и проверит за вас, всё ли работает. Это ваша работа, не тестировщика, не того, кто делает review.
- У ветки нет конфликтов с мастером, её можно слить в мастер одним нажатием.
- Поставьте на review одного из разработчиков. В момент передачи вашей ветки на review вы становитесь ответственным за качество кода в этой ветке.
- Дождитесь одобрения от разработчика, проверяющего вашу ветку.
- Если pull request одобрен, тот, кто делал review, должен слить ветку в master.
- После слияния ветку нужно удалить из Github (делает тот, кто сливает).