Что такое pull request — и почему это не про «скачать»

Слово сбивает с толку: pull request — будто что-то надо «тянуть» или «скачать». На деле всё наоборот. Pull request (PR, «пулреквест») — это когда ты говоришь: «вот мои изменения, посмотрите их, прежде чем впускать в основной код». Это не загрузка. Это предложение с проверкой.

Что такое pull request простыми словами

Представь общую тетрадь, которую ведёт команда. Ты не лезешь черкать прямо в неё. Ты пишешь свой кусок на отдельном листочке и кладёшь сверху с запиской: «предлагаю вставить вот это вот сюда». Кто-то читает, говорит «ок» или «поправь тут» — и только потом листок вшивают в тетрадь.

Pull request — этот самый листочек с запиской. Основной код (обычно ветка main) остаётся нетронутым, пока твоё предложение не одобрят.

Как это работает по шагам

Механика почти всегда одна и та же:

• Ты создаёшь ветку — отдельную копию кода, где можно ломать что угодно, не трогая основной (про ветки и коммиты — в гайде как пользоваться Git новичку).
• Делаешь изменения, фиксируешь их коммитами.
• Открываешь pull request: «прошу влить мою ветку в main». GitHub (или другой сервис) показывает diff — что именно изменилось, строка за строкой: зелёным добавленное, красным удалённое.
• Кто-то ревьюит: читает diff, оставляет комментарии, просит поправить. Часто тут же гоняются автотесты.
• Когда всё ок — PR мержат (сливают). Твои изменения теперь в основном коде. Ветку можно удалить.

Ключевое: пока PR открыт, ты докидываешь правки в ту же ветку — они автоматически попадают в тот же PR. Это не «выстрелил и забыл», а живой разговор вокруг конкретного куска работы.

Почему это важно — даже если ты один

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

Зачем тебе это:

• Точка проверки. Прочитать diff перед мержем — лучший момент поймать дичь, которую модель написала уверенно, но неправильно. Код от ИИ бывает с багами именно потому, что выглядит убедительно. PR заставляет посмотреть глазами.
• Откат бесплатный. Что-то сломалось после мержа — видно, какой именно PR виноват, и его легко откатить целиком.
• История с объяснением. PR хранит не только что изменилось, но и зачем — в описании и комментариях. Через месяц это спасает.

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

Где ты с этим столкнёшься

Как только заведёшь проект на GitHub, GitLab или похожем сервисе. Любой современный инструмент вокруг них крутится: автотесты на каждый PR, кнопка «слить», запрет лить в main напрямую. Многие ИИ-агенты по умолчанию работают именно так — ветка → PR → мерж, — потому что это безопасно: основной код всегда в рабочем состоянии, а всё рискованное живёт в отдельных предложениях, пока их не проверят.

Вопрос: pull request и merge request — это разное?

Нет, это одно и то же, просто названия от разных сервисов. GitHub зовёт это pull request, GitLab — merge request. Суть одинаковая: предложение влить одну ветку в другую.

Вопрос: чем PR отличается от обычного коммита?

Коммит — это одна зафиксированная порция изменений внутри ветки. Pull request — это просьба перенести набор коммитов из одной ветки в другую, с обсуждением и проверкой. Коммит — «я записал», PR — «предлагаю принять».

Вопрос: обязательно ли кому-то ревьюить мой PR?

Технически нет — соло можно смержить самому. Но даже тогда полезно открыть PR, посмотреть diff целиком и дать автотестам прогнаться. Это пять минут, которые ловят ошибки до того, как они попадут в рабочий код.