Что такое Pull Request

В мире современной разработки программного обеспечения одним из наиболее важных и мощных инструментов стал пул-реквест (pull request). Этот механизм изменил способ, которым команды разработчиков сотрудничают, вносят изменения в код и обеспечивают качество проектов.

В данной статье мы рассмотрим пул-реквесты и их ключевые преимущества, а также расскажем, как они сделали разработку ПО более эффективной и прозрачной.

Общие сведения

GitHub представляет собой платформу, на которой проекты могут совместно разрабатываться и хоститься. Этот сервис позволяет неограниченному числу программистов из разных уголков мира совместно работать над кодом проекта. Одной из ключевых особенностей GitHub является интеграция с системой контроля версий Git. Она позволяет отслеживать и управлять всеми изменениями в коде, а также возвращаться к предыдущим версиям кода.

По сути, GitHub можно рассматривать как своеобразную социальную сеть для разработчиков, где можно находить проекты с открытым исходным кодом, созданные другими разработчиками. Это также место, где можно учиться, практиковаться в написании кода и хранить свое портфолио проектов.

В повседневной работе с этой площадкой часто используется несколько команд и действий, одной из них как раз и является Pull Request. Он представляет собой один из ключевых терминов, активно используемых на платформе GitHub и при работе с системой контроля версий Git.

Pull request является важным инструментом для совместной разработки и контроля качества кода, так как он позволяет участникам проекта тщательно анализировать и обсуждать нововведения в коде перед их интеграцией в основной кодовой базе.

Проще говоря, отправив pull request, вы практически предлагаете автору и другим заинтересованным людям в оригинальном репозитории следующее: «Посмотрите, какие изменения я внес, не желаете ли вы включить их в проект?» Это способ сделать свои нововведения в коде доступными для обсуждения и возможной интеграции в основной проект.

Виды моделей совместной разработки

На GitHub существуют две распространенные модели для совместной разработки, которые часто используются.

Модель общего репозитория

Модель «общего репозитория» (The Shared Repository Model) часто используется в небольших командах и организациях, которые занимаются разработкой закрытых проектов.

В этой модели каждый член команды имеет права на редактирование одного общего репозитория, а чтобы изолировать их изменения, применяются отдельные ветви, ориентированные на конкретные задачи (тематические ветви).

Модель «Fork + Pull»

Модель «Fork + Pull» позволяет любому человеку создать свою собственную копию (форк) существующего репозитория и вносить нововведения в код в эту копию без необходимости иметь доступ к исходному репозиторию. После этого внесенные изменения могут быть интегрированы в исходный репозиторий его владельцем.

Этот метод сокращает количество действий для новых участников и пользуется популярностью в проектах с открытым исходным кодом, так как позволяет людям работать независимо, без необходимости согласования с другими.

Роль Pull Request в моделях общей разработки

Pull request является особенно полезным в модели «Fork + Pull», так как он предоставляют средство для уведомления владельцев проекта (то есть, владельцев оригинального репозитория) о ваших нововведениях в код в вашей собственной копии репозитория.

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

Принципы работы с площадкой GitHub

Для лучшего понимания сути и цели запроса на слияние (pull request), важно ознакомиться с другими широко используемыми терминами и предшествующими этапами в работе с GitHub.

Проекты

На GitHub проекты хранятся в репозиториях, которые представляют собой хранилища для всех изменений и создаваемого кода. Если вы работаете над проектом в одиночку, вам нужно создать новый репозиторий.

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

Коммиты

Коммит (commit) представляет собой основной элемент разработки, в котором хранятся все нововведения кода, сделанные за определенный период времени. В простых словах, это запись, содержащая список всех актуальных изменений и ссылку на предыдущую версию коммита.

Каждый коммит имеет свои характеристики, такие как название, дата создания, автор и комментарии к текущей версии (например, «Создана страница courses.html» в случае разработки веб-сайта с видеокурсами).

Ветки

Ветка (branch) — это ссылка на определенный коммит, который содержит определенные изменения в коде проекта. Например, представьте, что два разработчика начали с одного и того же коммита, но каждый из них внес свои уникальные нововведения в коде, создав новый коммит (например, «Создал страницу courses.html с личным кабинетом» и «Создал страницу courses.html с открытым доступом к курсам»).

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

Обычно основной веткой проекта считается ветка с названием «main» или «master», и разработчики создают новые ветки, исходя из этой основной. Кроме того, можно создавать сколько угодно дополнительных веток, чтобы вносить новые изменения, не затрагивая основную линию проекта.

Слияние веток

Зачастую разработчики вносят параллельные изменения в код. Например, один из них может работать над дизайном веб-сайта, в то время как другой занимается размещением контента на нем. По завершении работы в их отдельных ветках, можно объединить эти изменения в одну ветку и создать коммит, включающий все внесенные ими правки или новшества.

Для этого в Git используется функция pull request (PR). Pull request представляет собой запрос на объединение кода из различных веток. При выполнении слияния, Git создает коммит и отображает все изменения в коде: добавленные строки до ветвления будут подсвечены зеленым цветом, а удаленные — красным.

Таким образом, каждый разработчик и участник проекта может видеть, какие изменения произошли в коде после их совместной работы над коммитом. Перед окончательным объединением (merge) всех нововведений в коде, все разработчики должны провести рецензию кода (code review) и принять изменения.

Код-ревью

Code review (ревью кода) — это процесс обсуждения изменений в коде после того, как коммит был создан совместно, но перед окончательным объединением или, как его еще называют, слиянием. В процессе ревью разработчики оставляют комментарии к строкам кода, которые были изменены, и предлагают решения для улучшения кода, если обнаружат ошибки или упущенные моменты.

После завершения ревью, разработчики должны закрыть комментарии и подтвердить (approve) предлагаемые нововведения. Затем Git выполнит объединение веток с помощью функции merge и внесет созданный коммит в основную ветку (main). В истории коммитов будет отмечено, что произошло объединение веток.

Преимущества использования Pull Request

В следующем разделе мы рассмотрим неоспоримые преимущества пул-реквестов, одного из ключевых инструментов современной разработки программного обеспечения.

Коммуникация

Фактически, пул-реквесты значительно упрощают процесс совместной работы с другими людьми. Они делают коммуникацию между авторами изменений и проверяющими более прозрачной, предоставляя детальные различия (diffs), коммиты (commits) и комментарии, которые поясняют внесенные изменения.

Раньше, до появления пул-реквестов, подтверждение изменений происходило через электронную почту или в IRC-чатах. Там нужно было указывать название ветки или список коммитов.

Для слияния изменений мейнтейнеру или разработчику приходилось сравнивать их с текущей версией кода на своем компьютере, предоставлять обратную связь и ждать ответа с возможными поправками. После согласования изменений они могли быть слиты в основную кодовую базу. Введение пул-реквестов сильно упростило весь этот процесс.

Это особенно важно для больших проектов, где работают множество участников. Поэтому многие такие проекты используют пул-реквесты и следуют рабочему процессу, известному как «GitHub flow». Этот подход включает создание форков целых проектов и создание пул-реквестов в этих форках.

Еще одним преимуществом процедуры пул-реквестов является то, что всем сотрудникам видна вся коммуникация по изменениям. Вы можете легко искать внесенные изменения и использовать теги для организации.

Все это упрощает отслеживание происходящего. Контекст и предыдущие решения не пропадают среди потока электронных писем или сообщений в чатах. Любой разработчик, работающий над проектом, может легко найти и просмотреть необходимую информацию.

Автоматизация

С появлением пул-реквестов, которые получили огромную популярность среди разработчиков, платформы, включая GitHub, разработали обширный набор веб-хуков (webhooks), ориентированных на GitHub flow. Эти веб-хуки позволяют автоматизировать процессы.

В настоящее время распространена практика выполнения задач непрерывной интеграции каждый раз при коммите, что делает их частью пул-реквеста. Это одно из наиболее подходящих мест для внедрения автоматизации. Это не только запуск автоматических тестов — изменения в пул-реквесте могут использоваться для развертывания целых сред, чтобы проверить, прошли ли изменения без сбоев.

Ранее подобные инструменты для автоматизации были дорогими. Командам приходилось либо поддерживать собственную инфраструктуру для автоматизации, либо платить за услуги.

В последнее время доступность инструментов для автоматизации значительно увеличилась, что упрощает настройку автоматических задач. Например, сейчас можно воспользоваться бесплатными предложениями компаний, таких как Netlify и Travis.

GitHub даже шагнул дальше и представил GitHub Actions. Actions позволяют создавать автоматизированные рабочие процессы из набора отдельных маленьких задач, которые можно легко комбинировать.

Проверки статуса

Еще одно важное преимущество пул-реквестов — это концепция проверок статуса (status checks). Проверки статуса представляют собой набор задач, выполняемых для каждого коммита в пул-реквесте, и выдающих результат «успешно» или «неуспешно». Это по сути чек-листы для проверки готовности изменений к внесению в кодовую базу.

В этих проверках можно учитывать разные аспекты. В большинстве команд проверки статуса включают в себя автоматизированные тесты, затем проверку соответствия стилю кода, и, возможно, проверку на наличие одобрения от одного или двух рецензентов. Изменения не могут быть объединены, пока все эти проверки не завершатся успешно.

Заключение

В заключении стоит подчеркнуть, что пул-реквесты представляют собой неотъемлемую часть современной разработки программного обеспечения, обогащая ее эффективностью и качеством.

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

Внедрение пул-реквестов в разработческий процесс способствует улучшению совместной работы команды, ускоряет реакцию на изменения и поднимает уровень уверенности в стабильности и надежности проектов.