Що таке Pull Request і як його створити?

Під час розробки програмного забезпечення майже завжди залучають системи контролю версій. Одна з найпоширеніших серед них — Git. Такі системи покликані спростити роботу над проєктом за індивідуального підходу й особливо під час розробки в командах. Але часто, починаючи працювати з новими інструментами, ми застосовуємо не весь доступний функціонал.

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

За допомогою системи контролю версій важливо не лише комітити зміни на певних етапах у процесі розробки, а й ефективно інтегрувати їх у спільний код. Серед найпопулярніших і найзручніших способів зробити це — Pull Request (PR). Він дає змогу запросити рев’ю та погодити оновлення з іншими учасниками команди в зручній формі, водночас візуалізувавши всі реалізовані зміни одним або певною кількістю комітів у зрозумілому інтерфейсі. Відтворюється все у форматі «як було і як стало». Це може бути корисним не тільки для перегляду кимось із команди, хто контролює зміни на проєкті, але й для самоконтролю.  

Pull Request (PR) має інші назви на різних платформах. Наприклад, в GitLab це називають Merge Request (MR), а от Bitbucket також використовує термін Pull Request.

Що таке Pull Request?

Pull Request — це запит на злиття вашої гілки зі змінами у спільну гілку проєкту, найчастіше — main (раніше master). Проте здебільшого зміни ніколи не потрапляють одразу до головної гілки, а проходять через певні гілки, які дозволяють мінімізувати відмову проєкту через помилки в коді. 

Завдяки PR розробники мають змогу:

• переглянути код перед його інтеграцією;
• виявити помилки або недоліки;
• провести дискусію щодо реалізації та доцільності впровадження змін;
• виявити загрозу для працездатності проєкту на етапі внесення змін.

Як створити Pull Request?

Для прикладу розглянемо створення PR на одній із найпопулярніших платформ — GitHub.

1. Створіть гілку для внесення змін до проєкту

Перед тим як почати роботу, потрібно створити нову гілку. Це треба для того, щоб наші зміни вносилися до проєкту паралельно, а в гілці main зберігався актуальний та працездатний код.
Найчастіше гілку створюють двома способами:

• через графічний інтерфейс GitHub — для цього потрібно на головній сторінці проєкту перейти на сторінку гілок і натиснути кнопку New branch (або «Нова гілка», залежно від того, яку мову використовуєте), створення гілки, ввести назву та підтвердити операцію.

• через термінал у вашому локальному репозиторії — для цього потрібно виконати команду:

git checkout -b feature/my-new-feature
де feature/my-new-feature — це назва гілки

2. Зробіть потрібні зміни та зафіксуйте їх:

Це також можна виконати різними способами. Найпоширеніші — це, звісно, використання вашого локального репозиторію і, відповідно, IDE або текстового редактора.

Після збереження змін у файлі локального репозиторію зміни фіксуються комітом, який можна зробити, виконавши команди в терміналі:

git add
git commit -m "Add new feature"
де "Add new feature" — це коментар

Зміни також можна зафіксувати (закомітити) через графічний інтерфейс вашої IDE або текстового редактора з плагінами. Як це зробити детально, можна дізнатися в документації інструменту, який ви застосовуєте для редагування коду.

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

3. Відправте гілку на GitHub:

Після цього потрібно відправити зміни на віддалений репозиторій, якщо ви зробили їх не в інтерфейсі сторінки GitHub. Це можна здійснити, виконавши також команду в терміналі з вашого локального репозиторію:

git push origin feature/my-new-feature
де origin — назва вашого віддаленого репозиторію, а feature/my-new-feature — назва гілки

Так само, як і коміт, відправити зміни можна з графічного інтерфейсу вашої IDE чи текстового редактора.

4. Створіть Pull Request

Отже, ми зробили якісь зміни й тепер переходимо безпосередньо до створення PR. 

Це також можна здійснити через графічний інтерфейс або термінал.

Для того, щоб створити PR через графічний інтерфейс, перейдіть у свій репозиторій на GitHub. Після пушу нової гілки в інтерфейсі на головній сторінці проєкту й сторінці з переліком всіх гілок (вкладка Branches) з’явиться банер із пропозицією створити Pull Request і кнопкою Compare & pull request.

Натисніть цю кнопку, щоб відкрити форму створення PR.

Або можна натиснути New pull request, водночас обравши гілки, з якої в яку ви хочете перелити зміни.

5. Заповніть форму

Заповніть форму:

• Вкажіть заголовок/назву PR.
• Опишіть суть змін, особливості реалізації, можливі ризики.
• Оберіть базову гілку — ту, до якої потрібно внести зміни, що ви зробили.
• Вкажіть, кому саме адресований PR, якщо плануєте, щоб рев’ю зробив саме вказаний користувач.
• Переконайтеся, що все готово до рев’ю і всі потрібні зміни додано.

6. Відправте PR на рев’ю

Підтвердьте створення PR і після цього:

• ті учасники, яких ви вказали, або ті, хто підписаний у проєкті на такі події, отримають сповіщення;
• GitHub автоматично запустить CI-перевірки та скрипти, які можна підв’язати до статусу PR, якщо вони налаштовані.

На сторінці видно:

• які коміти увійшли у PR;
• всі зміни у файлах;
• коментарі тих, хто робив рев’ю;
• статуси PR (цей PR відхилили, тому він має статус Closed).

Потенційні труднощі, які можуть виникнути

Звичайно, що під час роботи над складним проєктом можуть з’являтися певні виклики. Найчастіше це відбувається в командній взаємодії, коли паралельно працюють над різними фічами або фіксами. Тому зважайте на такі особливості під час створення PR: 

• Конфлікти за злиття: коли паралельно змінилася основна гілка, а у вашій — ці оновлення відсутні. Стежте, щоб ваша гілка була синхронізована з тією, у яку плануєте залити зміни. Це спростить процес злиття (Merge) гілок у майбутньому. Для цього постійно оновлюйте свою гілку змінами головної.
• Великі PR: важко рев’ювати, краще робити невеликі запити з чітко зрозумілими змінами та їхніми цілями. Краще декомпозувати великі складні завдання, як і процес злиття. Робіть запити на злиття (ваші PR) обмеженими за обсягом, щоб було зручно переглядати код і чітко було зрозуміло, яка мета ваших змін, які фрагменти зміняться, який функціонал вони несуть і як вплинуть на проєкт.
• Затримки: якщо немає культури швидкого рев’ю — зміни зависають. Це краще погоджувати з командою, щоб такого не траплялося. Зазвичай у командах є певна політика стосовно того, як здійснюють затвердження змін у коді проєкту. Є правила, які покликані пришвидшити й зробити ефективнішим процес рев’ю та внесення змін. У команді приділіть час тому, щоб проаналізувати, що і як впливає на швидке проведення рев’ю і як його оптимізувати, а відповідно, до цього вже формуйте свої PR.

Отже, Pull Request — частина колективної розробки та гарний інструмент для розробки в соло. Це функціонал для покращення якості коду, залучення команди до дискусії та контролю версій проєкту.

Неважливо, чи це GitHub, GitLab чи Bitbucket — принципи однакові. Створювати, описувати й рев’ювати PR вам точно знадобиться. Використовуйте регулярно такий підхід — і він точно стане у пригоді та спростить життя.