Введение и проблематика

В командной разработке недопустимо, чтобы каждый разработчик напрямую пушил код в основную ветку. Это приводит к нестабильному коду, необнаруженным багам и сложностям в отслеживании изменений.

Зачем нужен PR?

• Code Review — проверка кода другими разработчиками
• Автоматические проверки — CI/CD запускает тесты и линтеры
• Документирование изменений — понятно что, зачем и как менялось
• Контроль качества — код попадает в main только после одобрения
• Коллаборация — обсуждение подхода в комментариях

Базовая теория

Жизненный цикл Pull Request

Типы слияния PR

Практические примеры

Полный цикл работы с PR

# Убедиться, что main актуален
git checkout main
git pull origin main
 
# Создать feature-ветку
git checkout -b feature/user-authentication

# Внести изменения
git add .
git commit -m "feat(auth): add login form component"
 
git add .
git commit -m "feat(auth): implement JWT token handling"
 
git add .
git commit -m "test(auth): add unit tests for auth service"

# Push ветки с установкой upstream
git push -u origin feature/user-authentication

# Через GitHub CLI
gh pr create --title "Add user authentication" \
  --body "## Summary
- Add login/logout functionality
- Implement JWT token handling
- Add unit tests
 
## Testing
- [x] Unit tests pass
- [x] Manual testing completed"

# После комментариев ревьюера, внести правки
git add .
git commit -m "fix(auth): address review comments"
git push

git checkout main
git pull origin main
git branch -d feature/user-authentication

Структура хорошего PR

## Summary
Краткое описание что делает этот PR.
 
## Changes
- Добавлен компонент LoginForm
- Реализован сервис AuthService с JWT
- Добавлены unit-тесты
 
## Screenshots (если применимо)
[Скриншот интерфейса]
 
## Testing
- [ ] Unit тесты проходят
- [ ] E2E тесты проходят
- [ ] Ручное тестирование
 
## Related Issues
Closes #123

Code Review

Роли в процессе

Что проверять при Code Review

Типы комментариев

# Блокирующий (требует исправления)
🔴 **Blocking:** Здесь SQL-инъекция, нужно использовать параметризованный запрос
 
# Предложение (желательно исправить)
🟡 **Suggestion:** Можно упростить этот цикл с помощью .map()
 
# Вопрос
❓ **Question:** Почему выбран именно этот подход?
 
# Комплимент
✨ **Nice:** Отличное решение с кешированием!
 
# Нит (мелочь)
📝 **Nit:** Лишний пробел в строке 42

CI/CD в Pull Request

Типичные проверки

# .github/workflows/pr-checks.yml
name: PR Checks
on: [pull_request]
 
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
 
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
 
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

Status Checks

Стратегии слияния

# Результат в истории:
# * Merge pull request #42
# |\
# | * feat: add feature C
# | * fix: fix bug
# | * feat: add feature B
# |/
# * previous commit

Draft Pull Request

# Создать draft PR через CLI
gh pr create --draft --title "WIP: User dashboard"

Когда использовать:

• Работа в процессе, хотите показать направление
• Нужна ранняя обратная связь
• Хотите запустить CI/CD для проверки

Плюсы и минусы

Вопросы интервьюера

Q: Чем PR отличается от MR?

Ничем функционально. PR — термин GitHub, MR — термин GitLab. Обе платформы позволяют настроить обе терминологии.

Q: Что такое squash merge?

Объединение всех коммитов PR в один перед слиянием. Даёт чистую историю main, но теряется детализация изменений.

Q: Как обычно настраиваются branch protection rules?

Требование ревью (1-2 approvals), прохождение CI проверок, запрет force push, запрет прямых коммитов в main.

Q: Что делать, если PR стал конфликтующим с main?

git fetch origin && git rebase origin/main или git merge origin/main, разрешить конфликты и push.

Q: Какой размер PR считается оптимальным?

200-400 строк кода. Большие PR получают поверхностный ревью, маленькие — легче проверять качественно.

Источники

• GitHub Docs: About Pull Requests
• GitLab Docs: Merge Requests
• Google Engineering Practices: Code Review
• Atlassian: Making a Pull Request