GitHub Pull Requests и Issues: полный гайд для команды разработчиков

Если ты работаешь в команде, то знаешь: GitHub Pull Requests и Issues — это не просто фичи платформы. Это основа всего процесса. Через них проходит код, идеи, б

Если ты работаешь в команде, то знаешь: GitHub Pull Requests и Issues — это не просто фичи платформы. Это основа всего процесса. Через них проходит код, идеи, баги, обсуждения. Но большинство команд используют их на 30% от возможностей.

Я встречал проекты, где PRs висят по две недели без ревью. Где Issues создаются, но никто не знает, что в них происходит. Где нет никакой связи между code review и релизом. Сейчас расскажу, как это всё наладить правильно.

Что такое Pull Requests на самом деле (и зачем они вообще)

Pull Request — это не просто "посмотрите мой код". Это контролируемый способ внести изменения в проект. Ты создаёшь ветку, пишешь код, отправляешь PR — и дальше начинается процесс: ревью, обсуждение, доработка, слияние.

Без PR работать в команде из 2+ человек — это как кодить вслепую. Потому что:

Никто не проверяет код перед слиянием в main
Нет истории решений ("почему тут именно так?")
Когда сломается — не найти виноватого, да и не нужно
Новички не видят, как в проекте принято писать

На одном проекте в Яндексе мы наоборот: обязательный ревью от двух человек, автоматические тесты, линтеры, потом слияние. Занимало больше времени, но зато багов в продакшене было в 3 раза меньше.

Итак, начнём с самого начала.

Шаг 1: Создаёшь ветку и пушишь код

Сначала убедись, что ты на свежей версии main:

git checkout main
git pull origin main

Теперь создаёшь ветку. Имя — важно. Используй префиксы, чтобы сразу было понятно:

# Для фичи
git checkout -b feature/user-authentication

# Для бага
git checkout -b bugfix/cart-calculation-error

# Для рефакторинга
git checkout -b refactor/api-response-handler

Пишешь код. Коммитишь с нормальными сообщениями (не "fix", не "123", а реально что ты сделал):

git add .
git commit -m "Add JWT token validation in auth middleware

- Validate token signature and expiration
- Return 401 for invalid tokens
- Log failed attempts for security audit"

Пушишь в удалённый репозиторий:

git push origin feature/user-authentication

GitHub заметит новую ветку и предложит создать PR. Нажимаешь "Compare & pull request".

Шаг 2: Оформляешь Pull Request правильно

Здесь большинство ошибаются. PR с пустым описанием — это зло.

Заголовок PR должен быть ясным:

✅ "Add email verification during signup"
❌ "Updates"
❌ "Fix stuff"

В описании пишешь:

Что ты сделал и зачем
Какие файлы изменил (GitHub покажет сам, но в описании можно подчеркнуть важное)
Как тестировать
Связь с Issues (если есть)

Вот шаблон, который работает:

## Описание
Добавляю валидацию email при регистрации. Пользователь получает письмо с ссылкой подтверждения, аккаунт активируется только после клика по ссылке.

## Тип изменения
- [x] Новая фича
- [ ] Баг фикс
- [ ] Рефакторинг
- [ ] Изменение документации

## Как тестировать
1. Перейди на страницу регистрации
2. Введи email и пароль
3. Проверь, что письмо пришло (используй MailHog на localhost:1025)
4. Нажми на ссылку в письме
5. Аккаунт должен активироваться

## Связанные Issues
Fixes #142
Related to #138

## Скриншоты (если UI изменения)
[добавь скриншоты]

## Чеклист
- [x] Код прошёл локальные тесты
- [x] Добавил unit-тесты
- [x] Обновил документацию
- [x] Нет console.log и todo комментариев

Когда создаёшь PR, GitHub покажет diff. Вверху можно выбрать reviewers (те, кто будет смотреть код) и labels (метки типа "urgent", "backend", "needs-testing").

Шаг 3: Ревью кода — как реагировать на комментарии

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

Правило простое: код — это не ты. Замечание к коду — это не личное. Даже если написано грубо (чего быть не должно, но бывает).

Когда тебе пишут "Это неэффективно, O(n²)", ты не "исправляешь ради галочки". Ты понимаешь, почему это проблема, и договариваешься:

Согласен, спасибо за замечание. Переписал на O(n log n) с сортировкой.
Проверь коммит abc123.

Или если не согласен:

Понимаю, но здесь данных максимум 10 элементов, поэтому O(n²) не критично.
Думаешь, всё равно переделать? Готов, если важно для стиля проекта.

Когда ты исправляешь замечания, не нужно создавать новый PR. Просто пушишь коммиты в ту же ветку:

# Исправил замечание
git add .
git commit -m "Optimize query performance with indexing"
git push origin feature/user-authentication

GitHub автоматически обновит PR. Старые комментарии останутся, но будет видно, что ты что-то изменил.

Если замечаний много или они серьёзные — можно запросить повторное ревью кнопкой "Request changes" в интерфейсе.

Шаг 4: Работаешь с Issues параллельно

Issues — это не просто баги. Это задачи, фичи, вопросы, всё что угодно.

Создаёшь Issue так:

Заголовок: "Users can't reset password via email link"

Описание:
### Что случилось
Пользователь нажимает на ссылку сброса пароля из письма, 
но видит ошибку 404.

### Как воспроизвести
1. Забыли пароль
2. Вводим email
3. Нажимаем на ссылку в письме
4. Ошибка

### Ожидаемое поведение
Должна открыться форма ввода нового пароля

### Окружение
- OS: macOS Ventura
- Browser: Chrome 120
- Версия приложения: 2.3.1

Важно: в описании Issue ссылаешься на код, если релевантно. Например:

Проблема в файле `auth/password-reset.py`, строка 42.
Там используется `request.args` вместо `request.form`.

После создания Issue — назначаешь себя или коллеге, добавляешь метку (label), приоритет.

Когда ты создаёшь PR, который закрывает Issue, пишешь в описании PR:

Fixes #142

или

Closes #142
Resolves #142

GitHub автоматически закроет Issue, когда PR смёржится в main.

Шаг 5: Автоматизация с GitHub Actions

Вот здесь PR становятся действительно мощным инструментом. GitHub Actions — это CI/CD прямо в GitHub. Каждый PR автоматически запускает тесты, линтеры, проверки.

Создаёшь файл .github/workflows/tests.yml:

name: Tests and Linting

on:
  pull_request:
    branches: [ main, develop ]
  push:
    branches: [ main, develop ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    strategy:
      matrix:
        python-version: ['3.10', '3.11', '3.12']

    steps:
    - uses: actions/checkout@v3
    
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}
    
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
        pip install pytest pytest-cov flake8
    
    - name: Lint with flake8
      run: |
        # Проверяем синтаксис
        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        # Проверяем стиль
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
    
    - name: Run tests
      run: |
        pytest --cov=src tests/
    
    - name: Upload coverage
      uses: codecov/codecov-action@v3
      with:
        file: ./coverage.xml

Теперь каждый PR автоматически:

Запустит тесты на трёх версиях Python
Проверит код на соответствие стилю (flake8)
Загрузит отчёт о покрытии

Если что-то не прошло — в PR будет красный крестик. Не смержишь PR без зелёной галочки (если настроить branch protection).

Для JavaScript/TypeScript похоже, но с npm/yarn:

name: Node.js CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Use Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
        cache: 'npm'
    
    - run: npm ci
    - run: npm run lint
    - run: npm test -- --coverage
    - run: npm run build

Шаг 6: Интеграция AI code review

Честно? Большинство ревью — это автоматизируемые вещи. "Где закрывается соединение с БД?", "Тут утечка памяти", "Это уязвимость".

Вот тут помогает инструмент типа Distiq. Это AI-бот, который автоматически проверяет каждый PR и оставляет комментарии прямо в коде.

Подключаешь его в GitHub (через Marketplace или вручную через webhook), и он:

Находит потенциальные баги
Ловит уязвимости (SQL injection, XSS и т.д.)
Проверяет производительность
Напоминает о best practices

Бот оставляет инлайн-комментарии:

🔍 Potential issue: SQL injection vulnerability
Line 42: query = f"SELECT * FROM users WHERE id = {user_id}"

Use parameterized queries instead:
query = "SELECT * FROM users WHERE id = %s"
cursor.execute(query, (user_id,))

Экономит время ревьюера на поиск очевидных ошибок.

Практические советы, которые работают

1. Code review должен быть быстрым. Если PR висит 2+ дня без ревью — это проблема процесса. Договорись в команде: максимум 24 часа на первый ревью.

2. Маленькие PR смерживаются быстрее. Если твой PR на 500 строк кода — ревьюер потратит час. Если на 50 строк — 10 минут. Разбивай большие фичи на несколько PR.

3. Используй draft PR для WIP. Если ты ещё работаешь над PR, отметь его как Draft. Это сигнал: "не ревьюьте пока".

# Создашь draft PR через интерфейс, или через CLI:
gh pr create --draft

4. Автоматизируй всё, что можно. Форматирование кода, линтинг, тесты — всё должно запускаться автоматически. Ревьюер должен смотреть на логику, а не на то, правильно ли расставлены пробелы.

5. Labels и Projects помогают организовать хаос. Если у тебя 50 открытых Issues, используй метки:

bug — настоящие ошибки
feature — новые фичи
documentation — доки
good first issue — для новичков
help wanted — нужна помощь сообщества

И GitHub Projects — это как доска задач прямо в репозитории. Перетягиваешь Issues туда-сюда, видишь, что в работе, что в очереди.

6. Ветви лучше удалять после слияния. После слияния PR в main, удали ветку. Чистота репозитория.

Типичные ошибки и как их избежать

Ошибка 1: Прямые коммиты в main. Это зло. Всегда через PR, всегда через ревью. Даже если ты опытный разработчик. Особенно если ты опытный — ты должен подавать пример.

Ошибка 2: Конфликты слияния в конце. Если твоя ветка отстала от main на неделю, будут конфликты. Решение: регулярно мержи main в свою ветку:

git fetch origin
git merge origin/main
# или rebase (опаснее, но чище):
git rebase origin/main

Ошибка 3: "Только пассивный ревью". Если ты только смотришь