Pull request-ы
Pull request — это воркфлоу платформы поверх git: запушь feature-ветку, открой PR, получи ревью и CI-проверки, затем слей. PR предлагает три стратегии слияния — merge-коммит, squash-and-merge, rebase-and-merge. Ревью плюс CI — гейт перед попаданием кода в main.
Ты научился пушить ветки, интегрировать изменения и безопасно переписывать историю. Но в реальной команде ты редко пушишь прямо в main — ты открываешь pull request. Вот сюрприз для многих инженеров: команды git pull-request не существует. PR — это вообще не фича git; это воркфлоу, который GitHub, GitLab и Bitbucket построили поверх git, добавив то единственное, чего голому git не хватает, — место для ревью, обсуждения и гейтирования изменений до их попадания в код.
К концу этого урока ты сможешь описать полный жизненный цикл PR, выбирать между тремя стратегиями слияния, которые предлагает PR, и объяснять, почему гейт «ревью плюс CI» — это суть всего этого.
После этого урока ты сможешь объяснить, что pull request — это воркфлоу платформы, наложенный на git, пройти его жизненный цикл от feature-ветки до слияния и осознанно выбирать между стратегиями merge-коммита, squash и rebase.
Pull request предлагает слить одну ветку в другую и живёт на платформе, а не в git. Механика под капотом — обычный git: ты создаёшь ветку, коммитишь и пушишь её. PR — это обёртка платформы вокруг этой ветки: страница, которая говорит «пожалуйста, слейте feature/login в main» и собирает ревью, обсуждение и автоматические проверки:
git switch -c feature/login
# ...коммитишь работу...
git push -u origin feature/login
# затем открываешь PR на платформе с целью mainНичего здесь не является новой командой git. PR — это метаданные, которые отслеживает сервер: исходная ветка, целевая ветка, комментарии, апрувы и результаты проверок.
Жизненный цикл PR: push → открыть → ревью + CI → слить. Как только ветка запушена и PR открыт, два гейта бегут параллельно, прежде чем что-либо попадёт в main:
- Код-ревью — коллеги читают дифф, комментируют, запрашивают изменения и в итоге апрувят.
- CI-проверки — автоматические пайплайны гоняют тесты, линтеры, проверки типов и сборки против ветки, рапортуя pass или fail в PR.
Только когда ревьюеры апрувят и требуемые проверки зелёные, кнопка слияния разблокируется. Этот гейт — вся причина существования PR: он переносит контроль качества на момент до попадания кода, а не после поломки main.
PR предлагает три стратегии слияния, каждая даёт свою историю. Когда ты жмёшь merge, платформа спрашивает, как внести ветку:
- Merge-коммит — добавляет merge-коммит, соединяющий ветку с
main; сохраняет каждый отдельный коммит и истинную топологию ветки. - Squash and merge — схлопывает все коммиты ветки в один чистый коммит на
main; грязная история промежуточной работы исчезает. - Rebase and merge — переигрывает коммиты ветки на
mainодин за другим без merge-коммита, сохраняя их раздельными, но линейными.
Компромисс — то же напряжение merge-против-rebase, что и при локальной интеграции, теперь применённое в момент попадания работы в основную линию.
▸Почему это работает
Почему большинство команд выбирают по умолчанию squash and merge? Потому что настоящая история feature-ветки обычно шум — «wip», «fix typo», «учёл ревью», «теперь точно фикс». Squash превращает десять одноразовых коммитов в один осмысленный блок на main («Добавить троттлинг логина»), так что история main читается как одно чистое изменение на фичу, а откат фичи — это один git revert. Цена: ты теряешь промежуточные шаги. Команды, ценящие тонкий bisect или пишущие дисциплинированные коммиты, предпочитают rebase and merge, чтобы сохранить каждый коммит; merge-коммит хорош, когда важно сохранить буквальную топологию ветки. Универсально правильного ответа нет — это осознанный выбор политики.
Долгоживущий PR отдаляется от main и его нужно держать свежим. Пока твой PR ждёт ревью, main продолжает двигаться. Если он отдалится слишком сильно, CI может пройти против устаревшего кода или слияние конфликтнёт. Ты освежаешь ветку одним из двух способов:
git fetch origin
git merge origin/main # влить main в PR-ветку, ИЛИ
git rebase origin/main # ребейзнуть PR-ветку на main (затем force-with-lease)Вливание проще и безопасно на общей PR-ветке; rebase держит ветку линейной, но переписывает её коммиты, поэтому для push нужен --force-with-lease. Многие платформы выставляют это как кнопку «Update branch», выполняющую слияние за тебя.
Черновики и CLI делают PR частью повседневного цикла. Черновой (draft) PR сигналит «не готов к слиянию» — он гоняет CI и собирает раннюю обратную связь, не приглашая к финальному апруву, что полезно для расшаривания работы в процессе. GitHub CLI открывает PR, не покидая терминал:
gh pr create --base main --head feature/login --draft
gh pr create --fill # заголовок/тело из твоих коммитов
gh pr status # увидеть состояние ревью + CIПометка черновика «готов к ревью» переводит его в обычный поток апрува. CLI держит весь цикл push-открыть-отслеживать внутри твоей оболочки.
Одна фича, от ветки до основной линии.
Ты строишь троттлинг логина на feature/login через восемь грязных коммитов («wip», «fix test», «правки из ревью»). Ты делаешь git push -u origin feature/login и открываешь PR с целью main через gh pr create --fill.
CI гоняет твой набор тестов и линтер на ветке — один тест падает, PR показывает красную проверку, кнопка слияния заблокирована. Ты пушишь фикс; CI перезапускается и зеленеет. Ревьюер комментирует, что magic number нужна константа; ты пушишь ещё коммит, они апрувят.
Тем временем main ушёл на три коммита вперёд. CI теперь предупреждает, что ветка позади, поэтому ты жмёшь «Update branch» (это merge origin/main в твою PR-ветку), и проверки перезапускаются зелёными против актуального кода. Наконец ты жмёшь Squash and merge: твои восемь коммитов схлопываются в один коммит main, «Добавить троттлинг логина (#142)», связанный с PR. main получает одно чистое, отревьюенное, CI-проверенное изменение — а восьмикоммитная мешанина, его породившая, остаётся в записи PR, но никогда не засоряет основную линию.
▸Частая ошибка
Частое заблуждение — считать зелёную проверку CI доказательством корректности кода, отчего ревью становится формальностью. CI доказывает лишь то, что утверждают тесты — он не поймает неправильно понятое требование, пропущенный краевой случай, на который никто не написал тест, или дизайн, который не масштабируется. Ревью и CI — взаимодополняющие гейты: CI ловит то, что проверяемо механически, люди ловят замысел и суждение. Пропуск любого из них — это путь, которым сломанный-но-зелёный код попадает в main.
У твоего PR восемь грязных коммитов ('wip', 'fix typo', ...). Команда хочет, чтобы история main показывала ровно один чистый коммит на фичу. Какая стратегия слияния подходит?
Pull request — это воркфлоу, который платформа накладывает поверх git; команды git pull-request не существует. Его жизненный цикл — запушить feature-ветку → открыть PR → пройти код-ревью и CI-проверки → слить, и этот гейт «ревью плюс CI», блокирующий слияние, пока люди не апрувят и пайплайны не зеленеют, и есть вся суть. В момент слияния ты выбираешь стратегию: merge-коммит сохраняет каждый коммит и топологию ветки, squash and merge схлопывает ветку в один чистый коммит на main, а rebase and merge переигрывает коммиты линейно. Держи долгоживущий PR свежим, вливая или ребейзя main, используй черновые PR и gh pr create, чтобы вплести это в ежедневный цикл, и помни, что CI и ревью ловят разные классы проблем. Это завершает арку про удалёнки и коллаборацию: от одинокого клона до отревьюенного изменения, попадающего в общую основную линию.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.