Что такое pull request?

Pull Request — стандарт совместной разработки

Pull Request (PR) — это механизм в системах контроля версий (Git, GitHub, GitLab), позволяющий разработчику предложить свои изменения для включения в основную кодовую базу. Это не просто отправка кода — это инструмент для code review, обсуждения и контроля качества.

История и терминология

Pull Request vs Merge Request:

• Pull Request — термин GitHub (кто-то просит pull-ить ваши изменения)
• Merge Request — термин GitLab (предложение merge-ить ветку)
• По смыслу это одно и то же

Как работает Pull Request

1. Создание ветки
   git checkout -b feature/user-authentication
   (Отделяетесь от main и работаете независимо)

2. Коммиты
   git commit -m "Add login form"
   git commit -m "Add password validation"
   (Ваша работа в отдельной ветке)

3. Push на удалённый репозиторий
   git push origin feature/user-authentication
   (Загружаете ветку на GitHub/GitLab)

4. Создание Pull Request
   На GitHub нажимаете "New Pull Request"
   Выбираете: базовая ветка (main) ← ваша ветка
   Пишете описание что вы сделали

5. Code Review
   Коллеги читают ваш код, оставляют комментарии
   Они могут запросить изменения

6. Обсуждение и исправления
   Вы исправляете замечания (новые коммиты)
   Обсуждаете архитектурные решения

7. Merge
   Когда все согласны и тесты проходят
   Нажимаете "Merge Pull Request"
   Ваш код включается в main

8. Cleanup
   git branch -d feature/user-authentication
   Удаляете ветку

Структура Pull Request

## Description
Что вы сделали и почему это нужно

## Type of change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change

## How has this been tested?
Как вы тестировали свои изменения

## Checklist
- [ ] Code compiles without errors
- [ ] No new warnings generated
- [ ] Tests added/updated
- [ ] Docs updated
- [ ] Breaking changes documented

Пример PR в Git

# БЫЛО (main branch)
def calculate_price(items):
    return sum(item.price for item in items)

# СТАЛО (feature branch)
def calculate_price(items, tax_rate=0.0):
    """Calculate total price with optional tax."""
    subtotal = sum(item.price for item in items)
    return subtotal * (1 + tax_rate)

def test_calculate_price_with_tax():
    items = [Item(price=100), Item(price=50)]
    assert calculate_price(items, tax_rate=0.1) == 165  # (100+50)*1.1

Что проверяют в PR

1. Код качество

# ✅ Хорошо: понятный код с типами
def validate_email(email: str) -> bool:
    """Validate email format."""
    import re
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    return bool(re.match(pattern, email))

# ❌ Плохо: неясный код без документации
def validate(e):
    import re
    return bool(re.match(r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$', e))

2. Тестирование

# Каждый PR должен иметь тесты
def test_valid_email():
    assert validate_email('user@example.com') == True

def test_invalid_email():
    assert validate_email('invalid.email') == False

def test_edge_cases():
    assert validate_email('') == False
    assert validate_email('@example.com') == False

3. Производительность

# Проверка что PR не замораживает приложение
# BAD: O(n^2) алгоритм
def find_duplicates(items):
    for i in range(len(items)):
        for j in range(i+1, len(items)):
            if items[i] == items[j]:
                return True

# GOOD: O(n) через set
def find_duplicates(items):
    return len(items) != len(set(items))

4. Security (безопасность)

# BAD: SQL injection vulnerability
def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    return db.execute(query)

# GOOD: Parameterized queries
def get_user(user_id):
    query = "SELECT * FROM users WHERE id = %s"
    return db.execute(query, (user_id,))

Комментарии и обсуждения в PR

# Reviewer оставляет комментарий
# "Почему вы используете list comprehension вместо map?"

# ✅ Хороший ответ:
# "List comprehension понятнее читается и быстрее работает
#  В Python это идиоматичный способ"

# ❌ Плохой ответ:
# "Потому что я так хотел"

Правила для хорошего PR

1. Размер

• ✅ Маленькие PR (< 400 строк) — быстрее review
• ❌ Большие PR (> 1000 строк) — сложно review-ить

# Сплитте большую работу на несколько PR
PR 1: Add database schema
PR 2: Add repository layer
PR 3: Add service logic
PR 4: Add API endpoints

2. Описание

# ПЛОХО
Title: "fix stuff"
Description: (пусто)

# ХОРОШО
Title: "Fix N+1 query in user profile endpoint"
Description:
When loading user profile with comments, each comment made
separate database query. Fixed by adding .eager_load()
Reduces queries from N+1 to 1.

3. Коммиты

# ПЛОХО: множество вразброс коммитов
git log
5a3b2c Fix typo
8d4e1f Try this
2c9a7b Revert previous
1f6e3a Actually fix it

# ХОРОШО: логичная история коммитов
git log
9e2f4a Add user authentication
  - Add login form
  - Add password validation
  - Add JWT token generation

CI/CD интеграция с PR

# .github/workflows/ci.yml
name: CI
on: [pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run tests
        run: pytest
      - name: Check coverage
        run: coverage report --fail-under=90
      - name: Lint
        run: pylint src/

Тогда PR не может быть merged если тесты не проходят!

Best Practices

✅ ДА:

• Делайте PR маленькими и сфокусированными
• Пишите понятные PR описания
• Добавляйте тесты для каждого изменения
• Отвечайте на все комментарии
• Работайте над замечаниями без грубости
• Изучайте чужой код через PR

❌ НЕТ:

• Не игнорируйте замечания review-ера
• Не делайте PR из 5000 строк
• Не пушьте без тестов
• Не переписывайте историю (force push)
• Не оставляйте PR открытыми неделями

GitHub Защита branches

# GitHub Settings → Branch Protection Rules

Require pull request reviews before merging
Dismiss stale pull request approvals
Require status checks to pass before merging
Require branches to be up to date before merging
Require code coverage

Команды в PR (GitHub)

@bot /test — перезапустить тесты
@bot /deploy-staging — deploy на staging
@dependabot update — обновить зависимости

Что не должно быть в PR

# ❌ Не коммитим credentials
API_KEY = "sk_live_51234567890abcdef"

# ❌ Не коммитим бинарные файлы большого размера
*.pyc, *.o, node_modules/

# ❌ Не коммитим .env файлы
.env
.env.local

# ✅ Используем .gitignore
echo ".env" >> .gitignore

Итоги

Pull Request — это не просто способ добавить код, это:

1. Инструмент обучения — коллеги видят ваш код
2. Гарант качества — code review ловит баги
3. История проекта — PR описания документируют решения
4. Коммуникация — обсуждение архитектуры
5. Контроль — защита основной ветки

Хороший PR культура — признак здоровой разработки. Если в компании PR игнорируются или заполняются как формальность — это красный флаг для качества кода.