GITFLOW.md

Как решаем задачу (Исполнитель)

• Увидели тикет задачи на agile доске (этот trello)
• Обсудили что непонятно
• Если постановка задачи ясна, вопросов пока не возникло, перетащили тикет в In progress
• Создали новую ветку из master (или другой исходной ветки) c говорящим названием (short_task_name) или номером тикета (если такие введены). Если задача - это новая функциональность, то называет ветку с префиксом feature/ (еще может быть release, patch, fix etc), в итоге ветка будет feature/short_task_name
• После того как сделали все нужные изменения в ветке
• На новый функционал нужно добавить тест, в тесте должен быть assert
• Следует убедиться, что нет дублирования кода, соблюдается code style
• Обсуждаем с коллегами, особенно с тем кто создал задачу, что добавленный функционал решает поставленную задачу.
• Если всё - ок
• Cоздаем в github в репозитории проекта Pull request (PR) обратно в ту ветку откуда создавали исходную (обычно это master). Если ветка была создана не из master (просто какая-то target_branch), то мерджим в нее же, иначе новые изменения из прошлой ветки будут на PR как добавленные функции в этой ветке. Проверяем что мы правильно хотим замерджить current_branch -> target_branch
• Отвечаем на комментарии к PR, делаем изменения в ветке, аргументируем если ревьювер не прав. Важный момент - комментарии закрывает ревьювер! Т.е. делает resole conversation.
• После того как все комментарии в статусе resolved. Ревьювер должен заапрувить PR.
• После того как получили аппрувы на PR
• Мержим ветку, разрешаем конфликты если есть, закрываем PR
• Пишем кратко, что было сделано в комментах к тикету
• Перетаскиваем тикет в статус Done
• Задача решена

Как проводим ревью, проверяем PR (Ревьювер)

• Во-первых, смотрим что постановка задачи действительно совпадает с реализацией. Чтобы не было что ветка называется feature/add_user_api, а в коде change database connection
• Проверяем что ветка действительно мерджится куда нужно
• Смотрим код, сначала проверяем высокоуровневые логические/архитектурные ошибки, потом детали реализации
• Оставляем комментарии по делу, спорные моменты выносим на обсуждение. В github каждый комментарий открывает отдельный тред - обсуждение этой части кода (conversation)
• Если что-то непонятно можно спросить об этом в комменте к запутанной части кода, это нормально
• Смотрим тесты, в тесте должно обязательно что-то проверяться (быть assert). Обычно это выходные значения, желательно один тест - один assert. Тесты не должны влиять друг на друга.
• Проверяем что нет дублирование функциональности, соблюдается codestyle
• После того как оставлены все комментарии
• Нажимаем Submit review, чтобы ревью открылось и Исполнитель увидел эти замечения.
• Далее Исполнитель должен посмотреть комментарии и ответить на них, если нужно добавить изменения в код. github добавит их в текущий PR.
• Когда получены ответы на комментарии, запрашиваемые изменения от Исполнителя, Ревьювер закрываем их (resolve conversation).
• Далее Ревьювер нажимает Approve PR. Его задача завершена.
• Затем уже Исполнитель мерджит изменения в целевую ветку.