Pull Request и код-ревью

Главный инструмент совместной работы на GitHub: предлагаем изменения и проходим ревью.

Pull Request (PR) — предложение влить изменения из одной ветки в другую, сопровождаемое обсуждением и проверкой кода.

Зачем нужен Pull Request

В команде нельзя просто запушить код прямо в main — так легко сломать проект для всех. Вместо этого изменения предлагают через Pull Request. Это «заявка»: «вот мои коммиты, прошу влить их в основную ветку». До слияния коллеги читают код, оставляют комментарии, запускаются автотесты. Только после одобрения PR вливается.

Жизненный цикл PR

Создаёте ветку и делаете в ней коммиты.
Пушите ветку на GitHub: git push -u origin feature-login.
На GitHub нажимаете Compare & pull request, пишете заголовок и описание.
Назначаете ревьюеров. Они оставляют комментарии и запрашивают правки.
Вы дорабатываете код, делаете новые коммиты и пушите — PR обновляется автоматически.
После одобрения PR сливается в main кнопкой Merge.

Что писать в описании PR

Хорошее описание экономит время ревьюеру:

Что сделано и зачем (какую задачу решает).
Ссылку на связанный Issue (например, Closes #42 — GitHub автоматически закроет задачу при слиянии).
Как проверить изменения, если это неочевидно.

Код-ревью

Ревьюер изучает вкладку Files changed, где видны все изменения, и может оставить комментарий к конкретной строке. По итогам он выбирает один из вердиктов:

Approve	одобряю, можно вливать
Request changes	нужны правки, пока вливать нельзя
Comment	замечания без явного вердикта

Способы слияния PR

GitHub предлагает три варианта Merge:

Merge commit — сохраняет все коммиты ветки и добавляет merge-коммит.
Squash and merge — схлопывает все коммиты ветки в один. Удобно, чтобы история main была чистой.
Rebase and merge — переносит коммиты поверх main без merge-коммита.

Маленькие PR — хорошие PR

Чем меньше PR, тем легче его ревьюить и тем быстрее он вольётся. Огромный PR на 50 файлов ревьюер будет смотреть неделю и пропустит ошибки. Разбивайте крупную задачу на несколько небольших PR.

Автопроверки перед слиянием

В зрелых проектах к каждому Pull Request автоматически подключаются проверки (CI): запускаются тесты, линтеры, сборка. На странице PR вы видите зелёные галочки или красные крестики. Если проверки красные — PR обычно нельзя слить, пока вы не почините. Это страховка: код, ломающий тесты, не попадёт в main, даже если человек-ревьюер что-то упустил.

Как отвечать на ревью

Код-ревью — это диалог, а не экзамен. На замечания ревьюера реагируйте по-деловому: с чем согласны — правьте и пушьте новый коммит, с чем нет — спокойно объясняйте свою позицию. Не воспринимайте критику кода как критику себя: цель ревью — улучшить продукт совместными усилиями. Когда вопрос решён, помечайте ветку обсуждения как resolved, чтобы ревьюеру было видно прогресс.

Итог

PR — предложение влить ветку с обсуждением и ревью перед слиянием.
Новые коммиты в ветку обновляют открытый PR автоматически.
Делайте маленькие PR с понятным описанием и ссылкой на Issue.