Как был устроен процесс Code Review на прошлом проекте

На прошлом проекте мы использовали GitHub Flow с обязательным код-ревью перед мерджем. Процесс выглядел так:

1. Ветка – создавалась от main для каждой задачи/фичи.
2. Пулл-реквест (PR) – открывался после завершения работы, автоматически запускались тесты и линтеры (через GitHub Actions).
3. Ревью – минимум 1 аппрув от коллеги. Акцент на:
   • Читаемость кода (PEP 8, именование).
   • Отсутствие дублирования.
   • Корректность архитектурных решений.
4. Комментарии – все правки обсуждались прямо в PR, автор вносил изменения через追加ные коммиты.
5. Сквош и мердж – после аппрува коммиты сквошировались в 1, PR мерджился в main.

Пример процесса:

# Ветка: feature/auth-login  
def login(user):  
    # Было: хардкод логина  
    # После ревью: вынесено в конфиг  
    return auth_service.validate(user)  

Важно: ревьюеры избегали микроуправления, фокус — на значимых улучшениях.