Как правилно да допринесете за проект с отворен код прости съвети, SavePearlHarbor
Още едно копие на пристанището
Главно меню
Навигация на публикации
Как да допринесете за проект с отворен код: прости съвети
Проектите с отворен код набират скорост всеки ден, появяват се нови, популярните се развиват активно. Проекти като Bootstrap, Angular.js, Elasticsearch, Symfony Framework, Swift и много други привличат нови разработчици и тяхната общност расте. Всичко това дава огромен ръст на проектите, а самите разработчици имат интерес да участват в разработката на нещо, което целият свят използва.
Аз, като много други програмисти, не можах да устоя и също от време на време участвах в разработването на Open Source проекти, предимно в PHP. Но когато започнах, се натъкнах на проблем - не знаех как правилно да организирам процеса на „допринасяне“, откъде да започна, как да накарам моята заявка за изтегляне да бъде разгледана и т.н.
За всички начинаещи "сътрудници", които са срещали подобни проблеми, добре дошли под кат.
Ще разгледаме процеса на участие в проекта с отворен код, като използваме примери за различни PHP рамки, вземете Symfony, Yii2.
След това трябва дапрочетете правилата за участие в разработкатаза проекта, който сте избрали. Тези правила обикновено се намират във файла
в основата на хранилището. За Symfony, например, това е Symfony Contributing.
Обикновено има няколко начина да участвате в разработването на проект с отворен код, основните от които са подаване на доклад за грешка или желано подобрение (Изпращане на проблем) или директно създаване на заявка за изтегляне с вашата корекция или подобрение (Принос на код). Можете също да участвате в подобряването на документацията, да отговаряте на въпроси от други разработчици и много повече.
Изпращане на проблем
Ако искате да уведомите разработчиците за открита грешка или подобрение, трябва да създадете съответния проблем в GitHub. Но преди да го създадете, проверете дали вече има същия или подобен, създаден от някой друг. Преди да създадете, също не забравяйте да прочетете правилата за подаване на доклад за грешка за този проект. Например, ето правилата за Yii Framework Обикновено описанието трябва да е възможно най-ясно и разбираемо, желателно е да има примери и описания как да се възпроизведе грешката. Това ще спести много време както на разработчиците, така и на вас, тъй като ще ви спести да отговаряте на уточняващи въпроси и т.н.
Изпращане на заявка за изтегляне
Ако сте намерили проблем с GitHub, който искате да коригирате, или сте създали свой собствен, тогава следващата ви стъпка е да изпратите съответната заявка за изтегляне. Отново, първо, не забравяйте да прочетете правилата за участие в разработването на проекта, който сте избрали. Например, ето правилата за Yii.
След това бих искал да опиша най-често срещания работен процес с Git и GitHub, когато участвам в проекти с отворен код (Git Workflow). Този процес може да се различава от проект до проект и като цяло е присъщ не само на проекти с отворен код, но и на много затворени проекти в GitHub и BitBucket.
Стъпка 1 — Подготовка на работната среда
Естествено, за развитие трябва да подготвите работната си среда. Много проекти с отворен код посочват как точно да се конфигурира, какви библиотеки, пакети, инструменти, техните версии и т.н. са необходими.
За PHP проекти обикновено ще ви трябва нещо като този минимален списък
Също така PHPUnit често е необходим. Обикновено идва като част от самия проект и е по-добре да се използватова е, тъй като тестовете може просто да не работят в различни версии на PHPUnit и това, което работи за вас от последната версия, може да не работи на CI сървъра на проекта, където библиотеката е по-стара.
Стъпка 2 - Създайте копие (Fork) на хранилището на проекта
Отиваме на страницата на избрания от вас проект и натискаме бутона „Форк“. Тази команда ще създаде ваше собствено копие на хранилището за този проект.
След това трябва да клонирате вашето копие на хранилището.
След това трябва да добавите клон нагоре по веригата за проекта, който ще препраща към основното хранилище (опция за Yii)
Стъпка 3 - Настройте Git
След това трябва да направите малко промяна на вашия Git, така че вашето правилно име да се показва при натискане на ангажименти. За да направите това, достатъчно е да изпълните следните команди:
Ако искате да зададете тези стойности локално за даден проект, в папката на проекта, стартирайте
Стъпка 4 - Композитор
Освен това в 99% от случаите за проекта ще трябва да заредите библиотеки чрез Composer
Стъпка 5 – Тестове
Преди да започнете, конфигурирайте в любимата си IDE или просто в конзолата PHPUnit (по-рядко Behat, PhpSpec и т.н.), за да изпълнявате и работите с тестове. След настройката стартирайте тестовете за проекта и проверете дали преминават правилно.
Стъпка 6 - Работа с кода
Когато започнете да работите по вашата корекция, първо трябва да създадете подходящ клон на Git въз основа на действителния код от основното хранилище.
Изберете ясно и кратко име на клон, което отразява същността на промените. Счита се за добра практика включването на номера на проблема на GitHub в името на клона.
Сега можете спокойно да започнете да работите върху кода. Когато работите, запомнете следните правила:
- последвамстандарти за кодиране (обикновено PSR стандарти);
- Напишете модулни тестове, за да докажете, че грешката е била коригирана или че нова функция действително работи;
- Опитайте се да не нарушавате обратната съвместимост, освен ако не е абсолютно необходимо;
- Използвайте прости и логически последователни ангажименти;
- Пишете ясни, ясни и завършени съобщения за ангажиране.
Стъпка 7 - Изпращане на заявка за изтегляне
Докато сте работили върху кода, може да са направени други промени в основния клон на проекта. Следователно, преди да изпратите вашите промени, трябва да пребазирате своя клон. Прави се така:
Сега можете да изпратите вашите промени.
След това отиваме във вашето хранилище-клонинг на проекта, в който участвате, и натискаме бутона „Нова заявка за изтегляне“. И виждаме следната форма:
Отляво трябва да изберете клона, в който искате да обедините промените (обикновено това е master, но по принцип това е клонът, към който сте направили повторното базиране). Вдясно - клон с вашите промени. След това ще видите съобщение от GitHub относно това дали е възможно автоматично обединяване на промените или не. В повечето случаи ще видите Възможност за обединяване. Ако има конфликти, най-вероятно ще трябва да преразгледате промените си.
След това щракнете върху бутона Създаване на заявка за изтегляне. Когато попълвате името и описанието на вашата заявка за изтегляне, счита се за добра практика да включите номера на проблема, за който е създадена вашата заявка за изтегляне.
Обикновено за много големи проекти се настройва CI сървър, често Travis-CI. След като създаде заявка за изтегляне, тя ще изпълни тестове, може би някои инструменти за показатели и т.н. Ще видите резултатите от неговата работа във вашата заявка за изтегляне, както е показано по-долу:
В случай, че тестовете се провалят или изграждането се провали, виеще видите червено съобщение за грешка и от връзката Подробности можете да видите какво точно не е наред. В повечето случаи ще трябва да коригирате своята заявка за изтегляне, за да преминат всички проверки.
Стъпка 8 - Обработка на заявката за изтегляне
Ако всичко е наред с вашата заявка за изтегляне, скоро тя ще бъде заклана от някой от екипа. Но често се случва разработчиците да ви помолят да направите някои промени.
За да направите това, просто се върнете към стъпка 6 и, след като направите промени и се ангажирате, изпълнете подобни команди:
Забележка:Лично аз обичам да изпращам заявка за изтегляне само с 1 ангажимент. За да направя това, „смачкам“ ненужните ангажименти. Как да направите това може да прочетете тук - gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
Стъпка 9 - Почистваме след себе си
След като вашата заявка за изтегляне бъде приета или отхвърлена, трябва да изтриете клона с вашите промени. Лесно е да се направи
Вместо последната команда можете също да стартирате
Заключение
Може би това е всичко, което се отнася до основните неща за участие в проекти с отворен код. Бих искал да добавя, че не трябва да сте мързеливи и да участвате в проекти с отворен код, това е огромно и интересно изживяване, както и отметка в резюмето 😉