Если ты пишешь код в команде — merge request (или pull request на GitHub) это то, без чего не обойтись. Вроде просто: сделал ветку, отправил в репозиторий, попросил смержить. На практике? Это целый процесс, где легко допустить ошибки. Давайте разберём, как это работает на самом деле.
Что такое merge request и зачем он вообще нужен
Merge request — это предложение объединить изменения из одной ветки в другую. Обычно из feature-ветки в main или develop. На GitHub это называется pull request, на GitLab — merge request. Суть одна.
По-хорошему, это не просто механизм слияния кода. Это контрольная точка перед тем, как твои изменения попадут в основную ветку. Здесь происходит:
- Code review от других разработчиков
- Автоматические проверки (тесты, линтинг, статический анализ)
- Обсуждение подхода и реализации
- Возможность внести правки до того, как код попадёт в продакшн
Я помню, на одном проекте в Яндексе один парень запушил огромный MR с 47 файлами, без описания. Ревьюеры просто закрыли его и попросили разбить на части. Потом я понял — это не наказание, а забота. Большие MR никто не проверит честно.
Как создать merge request на GitHub
Начнём с самого практичного.
Шаг 1: создаёшь ветку
git checkout -b feature/add-auth-endpoint
Имя ветки — это не просто так. Лучше делать по паттерну: feature/, fix/, docs/ в начале. Потом в истории понятнее.
Шаг 2: коммитишь изменения
git add .
git commit -m "feat: add authentication endpoint with JWT validation"
Совет: используй conventional commits. Потом в PR это выглядит аккуратнее, и автоматизация работает лучше.
Шаг 3: пушишь ветку в репозиторий
git push origin feature/add-auth-endpoint
Шаг 4: создаёшь PR через веб-интерфейс
GitHub тебе сразу предложит создать PR, если ты пушнул новую ветку. Кликаешь "Compare & pull request". Или идёшь в раздел Pull Requests и жмёшь "New".
Вот здесь начинается важное — заполнение описания PR.
Правильное описание merge request — половина успеха
Большинство разработчиков забивают на описание. "Fixed bug" — и всё. Потом ревьюер тратит 20 минут на то, чтобы понять, что вообще изменилось.
Хорошее описание выглядит так:
## Что изменилось
Добавлена аутентификация через JWT токены. Пользователь может регистрироваться и авторизоваться.
## Почему это нужно
Раньше API был открыт для всех. Теперь защитили эндпоинты, требующие авторизации.
## Как это работает
1. На `/auth/register` пользователь отправляет email и пароль
2. Сервер хеширует пароль bcrypt, сохраняет в БД
3. На `/auth/login` пользователь получает JWT токен на 24 часа
4. Токен отправляется в заголовке Authorization
## Тестирование
- Добавлены unit-тесты для валидации JWT
- Добавлены интеграционные тесты для эндпоинтов
- Вручную проверил на Postman
## Связанные задачи
Closes #142
Видишь? Ревьюер сразу понимает, что смотреть и почему. Экономишь 15-20 минут на объяснениях.
На GitHub можно ещё линковать задачи через Closes #номер. Потом при мерже задача автоматически закроется.
Как работает code review в merge request
Ревьюер открывает твой PR и видит вкладку "Files changed". Здесь все дельта-изменения файл за файлом.
Если что-то не нравится, ревьюер кликает на строку кода и оставляет комментарий. Комментарий может быть:
- Comment — просто замечание
- Approve — "ок, можно мержить"
- Request changes — "нет, надо переделать"
Если ревьюер запросил изменения, PR не сможешь смержить, пока не адресуешь все замечания.
Как отвечать на замечания:
# Делаешь изменения в коде
git add .
git commit -m "fix: add input validation to register endpoint"
git push origin feature/add-auth-endpoint
Новый коммит автоматически появится в PR. Ревьюер видит, что ты исправил. Если всё ок — даёт Approve.
Совет из опыта: если ревьюер оставил много замечаний, не принимай это в грудь. Это значит, что он внимательно смотрел. Я предпочитаю пару жёстких замечаний, чем когда в PR ничего не смотрят.
Merge request в GitLab — что отличается
На GitLab это называется merge request (MR), а не pull request. По сути — то же самое, но интерфейс чуть другой.
Создание MR на GitLab:
git push origin feature/add-auth-endpoint
GitLab предложит создать MR прямо в консоли:
remote: Create merge request for feature/add-auth-endpoint:
remote: https://gitlab.com/project/merge_requests/new?merge_request%5Bsource_branch%5D=feature%2Fadd-auth-endpoint
Или можешь перейти через веб-интерфейс.
В GitLab есть полезная фишка — можешь указать обязательных ревьюеров прямо при создании MR. На GitHub такое есть только в платной версии.
Ещё в GitLab можно настроить автоматический мерж при условиях:
# .gitlab-ci.yml
merge_requests:
rules:
- when: manual
allow_failure: true
Если все тесты прошли и ревью дано — MR смержится автоматически.
Частые ошибки при работе с merge request
Ошибка 1: большой PR с множеством файлов
Я видел PR на 200+ файлов. Никто не проверит честно. Разбей на 3-4 маленьких PR.
Ошибка 2: коммиты без смысла
fix typo
fix typo again
actually fix typo
Перед мержем сквашь коммиты:
git rebase -i HEAD~3
# Помечаешь первый как pick, остальные как squash (s)
Ошибка 3: забыл обновиться с main
git fetch origin
git rebase origin/main
# Если были конфликты, решаешь их
git push origin feature/add-auth-endpoint -f
Ошибка 4: нет описания или оно на полстроки
Ревьюер потратит время на гадание. Напиши нормально.
Ошибка 5: не дожидаешься одобрения, а просто мержишь
Бывает, что у человека есть права на мерж своего же PR. Но это плохая практика. Мерж должен делать либо другой разработчик, либо автоматизация.
Автоматизация проверок в merge request
Когда ты создаёшь MR, запускаются автоматические проверки (CI/CD). Это тесты, линтеры, проверки безопасности.
Пример GitHub Actions:
name: CI
on:
pull_request:
branches: [ main, develop ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.9
- name: Install dependencies
run: |
pip install -r requirements.txt
pip install pytest flake8
- name: Lint with flake8
run: flake8 src/
- name: Run tests
run: pytest tests/
Когда ты пушишь в PR, этот workflow запустится автоматически. Если что-то упало — в PR появится красный крест, и мержить нельзя.
На практике это спасает. Я помню, как один парень чуть не влил баг в продакшн, но тесты его поймали на PR.
Когда и как смержить merge request
После того, как:
- Код одобрен (минимум один Approve)
- Все тесты прошли
- Нет конфликтов с основной веткой
- Все замечания ревьюеров адресованы
Нажимаешь "Merge pull request" (на GitHub) или "Merge" (на GitLab).
GitHub предложит несколько способов мержа:
- Create a merge commit — создаст обычный мерж-коммит. История будет полная, но может быть запутанная.
- Squash and merge — сквашит все коммиты в один. История чистая, но теряется информация о промежуточных шагах.
- Rebase and merge — перебейзит коммиты на top of main. История линейная.
На мой взгляд, для фич-бранчей лучше squash and merge. Для багфиксов — обычный merge или rebase.
После мерджа ветка автоматически удалится (если включена опция). Локально её тоже можно удалить:
git branch -d feature/add-auth-endpoint
Как сделать pull request правильно: чек-лист
Прежде чем отправлять PR на ревью:
- Ветка создана от актуального main/develop
- Коммиты имеют смысл и хорошие сообщения
- Код отформатирован (eslint, black, prettier — в зависимости от языка)
- Тесты написаны и все проходят локально
- Нет console.log, TODO, FIXME в коде (или они задокументированы)
- Описание PR понятное и полное
- Нет конфликтов с основной веткой
- Изменения минимальны и сфокусированы на одной задаче
Вот именно такой PR ревьюеры любят. Быстро проверяют, быстро одобряют.
Инструменты для работы с merge request
Если ты в терминале:
# Если используешь GitHub CLI
gh pr create --title "Add auth" --body "Implements JWT auth"
gh pr view --web # открыть PR в браузере
gh pr review --approve # одобрить PR
# Если используешь GitLab CLI
glab mr create --title "Add auth" --description "Implements JWT auth"
В VS Code есть расширение GitHub Pull Requests, которое позволяет смотреть и ревьювить PR прямо из редактора. Удобно.
Для автоматических проверок кода в PR можно подключить Distiq — это AI-бот, который анализирует каждый merge request и находит баги, уязвимости и нарушения стиля. Настраивается за пару минут через webhook, поддерживает GitHub, GitLab и GitVerse. Работает локально, данные не уходят за границу.
Merge request — это не просто кнопка "слить код". Это культура разработки. Хороший MR — это когда ревьюер быстро понимает, что произошло, почему, и может честно проверить. Плохой MR — это когда он закрывает вкладку и говорит "переделай".
Потрать время на описание, разбей большой PR на части, пиши понятные коммиты. Ревьюеры скажут спасибо.