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

Відкриті репозиторії GitHub можна використовувати для отримання досвіду, відточування навичок, для резюме або просто внесення вкладу в улюблене відкрите програмне забезпечення, під Linux , MacOS або Windows. Сьогодні в якості опенсорсного піддослідного ми розглянемо живий приклад роботи з проектом Microsoft .NET. Будь-який робочий процес, інструменти та ситуації специфічні для проекту і команди, яка його підтримує, але загальні концепції однакові для багатьох проектів, з якими вам доведеться зіткнутися.

Вибираємо перший issue

Щоб взятися за роботу, потрібно визначитися з інтересами і областю знань, потім шукати проекти. На GitHub неоране поле задачок різного рівня складності.

Як тільки виберете репозиторій, шукаємо спосіб почати роботу. У вас може бути впевнене розуміння того, що потрібно змінити в проекті або ви можете навмисно шукати проблемні місця. Якщо ви вносите будь-який внесок, крім виправлення помилки або проблеми компіляції, перш ніж витрачати час на виправлення, потрібно створити issue в репозиторії. Це гарантує, що робота не буде виконана даремно і власник сховища зможе прокоментувати її реалізацію.

Якщо ви не знаєте, над чим хочете працювати, перейдіть в репозиторії у вкладку Issues і перегляньте доступні теги. Ви можете вибрати ті проблеми, які в даний час відкриті. Для цього в пошуковому фільтрі, де за замовчуванням відображаються is:issue, is:open, додаємо мітки label:good-first-issue або label:up-for-grabs (англ. Доступний кожному бажаючому). Або просто натискаємо на такі мітки, якщо помітили їх одразу перед issue.

Команда Microsoft ретельно перевіряє і коментує все, що знаходиться в їхньому беклозі - це полегшить пошук актуальної проблеми.

Зрозумійте проблему

Всякий раз, коли ви беретеся за завдання, потрібно уважно прочитати опис і кожен коментар в його історії, чітко зрозуміти проблему. В даному випадку команда .NET активно брала участь в обговоренні проблеми. У коментарях issue можна було виділити кілька корисних коментарів.

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

Форкаємо і клонуємо

Репозиторій можна клонувати локально, але ви не зможете зробити pull request без форка. На щастя, цей процес елементарний - натисніть на кнопку Fork і виконуйте подальші вказівки GitHub.

У прикладі в якості git-клієнта використовувався GitKraken. Аналогічно іншим інструментам було проведення клонування по URL. Ви можете використовувати командний рядок або інший улюблений інструмент.

Розуміємо робочий процес команди

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

На щастя, такі нюанси в більшості репозиторіїв описані в contributing.md або readme.md. Зазвичай там розказано, як почати роботу з репозиторієм, описана структура гілок та інша інформація про процес розробки.

Якщо такої документації немає, будьте обережні, команда може не любити «чужаків».

У нашому випадку команда .NET надала дуже корисне керівництво. Можливо, вам доведеться робити висновки, переглядаючи минулі комміти або навіть зв'язатися з власником сховища.

Перш ніж приступити до роботи в редакторі, рекомендуємо створити гілку на основі головної. Обов'язково перевірте сусідні гілки і contributing.md та / або README.md на предмет угод про іменування. Імена гілок не найважливіше, так як пізніше pull request відправляється в інший репозиторій, але це допомагає дотримуватися порядку.

Розуміємо структуру коду

Отже, тепер, коли у вас є локальний код, потрібно відкрити проект в будь-якому редакторі. У розглянутому прикладі в якості редактора використовувався Visual Studio Code.

Наступний крок - знайти підхід до структури проекту. Файл contributing.md допоможе розібратися в деяких директоріях. Але не менш корисно вивчити структуру наживо: повідкривати папки і підпапки, поки не зрозумієте шаблони організації каталогів і файлів.

Як тільки увійдете в курс справи, шукайте файли, пов'язані з кодом, які збираєтеся змінювати. В даному випадку це було легко, так як шлях був відзначений в issue:

Створюємо і тестуємо зміни

Як тільки ви зрозумієте, що перебуваєте в потрібному місці, починайте робити необхідне виправлення, тестуйте і обов'язково відправляйте  коміт. Перевірка коду - важлива частина роботи програміста.

На щастя, більшість великих проектів мають автоматизовані перевірки, вбудовані в процес pull request, що дозволить переконатися правильності роботи.

Після комітів переконайтеся, що ви запушили його в форкнуту версію сховища. Цей крок необхідний для створення pull request.

Створюємо pull request

Робимо pull request форкнутого сховища за відповідними підказкам.

Гілка і репозиторій зліва вказують на відповідні об'єкти, з якими ви хочете змержитись. Репозиторій повинен бути основним для проекту, а гілка - та, від якої ви клонували. Праворуч - форкнутий репозиторій і його гілка, з якими ви недавно працювали.

Тепер все готово, дотримуйтесь угоди команди про іменування запиту. У розглянутому прикладі дається назва комітів і в дужках номер issue.

Зверніть увагу, на останній рядок: Fixed dotnet/docs#10675.

Це «чарівний» рядок, за допомогою якого GitHub пов'язує коміт з правильним номером issue ( #10675) зі сховищ docs. Як тільки все готово, натискаємо Create pull request.

Що далі?

Вітаємо, ви внесли невеликий внесок в опенсорсний проект.

Ваш код повинен пройти автоматичні перевірки (найчастіше це білд і аналіз коду), перш ніж буде розглянутий. Крім того, мейнтейнер проекту розбереться в ваших змінах і прийме рішення, внести їх у вихідний репозиторій чи ні.

У нашому прикладі зміни були оперативно розглянуті та прийняті, про що GitHub повідомив.

Висновок

Рекомендуємо спробувати внести свій внесок у відкрите програмне забезпечення. Знайдіть цікавий для вас проект і дійте. Почніть з простого проекту, подивіться як все працює, а потім беріться за щось об'ємне. Розробка open source завжди приносить свої плоди, будь то нові навички, знайомства або просто задоволення від того, що ви робите світ кращим.

Джерело перекладу