Лекция
Привет, Вы узнаете о том , что такое контрибьютинг, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое контрибьютинг, open source, contributing, контрибьютер , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
Open Source проекты с каждым днем набирают все большие обороты, появляются новые, активно развиваются популярные.
Такие проекты как Bootstrap, Angular.js, Elasticsearch, Symfony Framework, Swift и многие другие привлекают новых разработчиков, их сообщество растет. Все это дает огромный рост проектам, а самим разработчикам интересно поучаствовать в разработке чего-то, чем пользуется весь мир.
Я, как и многие другие программисты, не устоял и также время от времени участвую в разработке Open Source проектов, в основном на PHP. Но когда я начинал, я столкнулся с проблемой — я не знал, как правильно организовать процесс «
контрибьютинг а», с чего начать, как сделать так, чтобы мой Pull Request рассмотрели и т.д.
График наиболее активных компаний, вносящих вклад в Open Source, с 2012 по 2019 годы. На основе количества коммитов и пользователей, экспортированных из архива GitHub.
Сам процесс участия в Open-Source проекте рассмотрим на примерах различных PHP фреймоворков, возьмем Symfony, Yii2.
Первое, что необходимо сделать — это создать аккаунт на GitHub (если его еще у вас нет). Заполняйте его внимательно, так как ваш GitHub профиль — это фактически ваша визитная карточка в мире Open Source.
Далее следует ознакомиться с правилами участия в разработке для выбранного вами проекта. Данные правила обычно находятся в файле
CONTRIBUTING.md
в корне репозитория. Для Symfony, например, это Symfony Contributing.
Symfony - это проект с открытым исходным кодом, управляемый сообществом.
Если вы хотите внести свой вклад, прочтите следующие документы:
Обычно, есть несколько способов участия в разработке Open Source проекта, основные — это отправка сообщения о какой-то ошибке или желаемом улучшении (Submitting Issue) или непосредственное создание Pull Request с вашим исправлением или улучшением (Code Contributing). Так же вы можете поучаствовать в улучшении документации, ответах на вопросы, возникших у других разработчиков и многое другое.
Это минимальный, наименее трудоемкий и самый важный вид вклада, который вы можете сделать.
Можно сказать, что это не настоящий вклад, но я считаю его очень важным. Фактически, Github считает это вкладом:
4 типа вклада, рассматриваемые Github
Начнем с очевидного наблюдения - без создания проблемы сопровождающие никогда не узнают о проблеме с их программным обеспечением и не смогут ее улучшить.
Если Вы захотели уведомить разработчиков о какой-либо найденной ошибке или улучшении, вам необходимо создать соответствующий GitHub Issue. Об этом говорит сайт https://intellect.icu . Но перед тем, как создавать его, проверьте, не существует ли уже такого же или похожего, созданного кем-либо другим. Перед созданием также не забудьте ознакомиться с правилами отправки отчета об ошибке для данного проекта. К примеру, вот правила для Yii Framework. Обычно описание должно быть максимально четким, понятным, желательно наличие примеров и описания как воспроизвести ошибку. Это сэкономит огромное время и разработчикам, и вам, так как избавит вас от ответа на уточнящие вопросы и т.д.
Если вы нашли GitHub Issue, которое хотели бы исправить или же создали свой собственный, то следующим вашим шагом будет отправка соответствующего Pull Request.
Опять же, для начала не забудьте ознакомиться с правилами участия в разработке для выбранного Вами проекта.
Далее я хотел бы описать наиболее часто встречаемый процесс работы с Git и GitHub при участии в Open Source проектах (Git Workflow).
Этот процесс может отличаться от проекта к проекту, да и в целом он присущ не только Open Source проектам, но и многим закрытым проектам на GitHub и BitBucket.
Естественно, для разработки вам надо подготовить ваше рабочее окружение. Многие Open Source проекты указывают, как именно необходимо его настроить, какие библиотеки, пакеты, инструменты, их версии и тд необходимы.
Для PHP-проектов обычно вам понадобится приблизительно такой минимальный список
Кроме того, часто необходим PHPUnit. Обычно он идет в составе самого проекта и лучше использовать именно его, так как в разных версиях PHPUnit тесты могут попросту не работать и то, что работает у вас с новейшей версии, может не работать на CI сервере проекта, где библиотека более старая.
Заходим на страницу выбранного Вами проекта и нажимаем кнопку «Fork». Данная команда создаст Вашу собственную копию репозитория данного проекта.
Далее вам необходимо склонировать вашу копию репозитория.
git clone https://github.com/<Ваше-GitHub-имя>/<Название-Репозитория>.git
Далее вам необходимо добавить ветку upstream для проекта, которая будет ссылаться на базовый репозиторий (вариант для Yii)
cd <Локальная-Папка-Проекта>
git remote add upstream https://github.com/yiisoft/yii2.git
Далее, необходимо сделать небольшую настройку Вашего Git, для того, чтобы при отправке коммитов, отображалось ваше корректное имя.
Для это достаточно выполнить данные команды:
git config --global user.name "Ваше Имя"
git config --global user.email you@example.com
Если вы хотите настроить данные значения локально для данного проекта, в папке проекта выполните
git config --local user.name "Ваше Имя"
git config --local user.email you@example.com
Далее, в 99% случаев для проекта Вам придется выполнить загрузку библиотек через Composer
cd <Локальная-Папка-Проекта>
composer install
Перед тем, как начать работу, настройте в своей любимой IDE или просто в консоли PHPUnit (реже Behat, PhpSpec и тд) для запуска и работы с тестами.
После настройки запустите тесты для проекта и проверьте что они корректно проходят.
Начиная работать над вашим исправлением, изначально надо создать соответствующую Git ветку, основанную на актуальном коде из базового репозитория.
Выбирайте четко и лаконично имя ветки, которое отражало бы суть изменений.
Считается хорошей практикой включать в названии ветки номер GitHub issue.
git fetch upstream
git checkout -b 1234-helper-class-fix upstream/master
Теперь вы можете смело приступать к работе над кодом.
Работая, помните о следующих правилах:
Пока Вы работали над кодом, в основную ветку проекта могли быть внесены другие изменения. Поэтому перед отправкой ваших изменений Вам необходимо сделать rebase Вашей ветки.
Делается это так:
git checkout <ИМЯ-ВАШЕЙ-ВЕТКИ>
git fetch upstream
git rebase upstream/master
Теперь вы можете отправить Ваши изменения.
git push origin <ИМЯ-ВАШЕЙ-ВЕТКИ>
После этого заходим в ваш репозиторий-клон проекта, в котором вы участвуете и нажимаем кнопку «New Pull Request».
И видим следующую форму:
Слева необходимо выбрать ветку, в которую Вы хотите смержить изменения (обычно это master, ну а вообще это ветка, на которую вы делали rebase).
Справа — ветку с вашими изменениями.
Далее вы увидите сообщение от GitHub о том, возможно ли автоматически смержить изменения или нет.
В большинстве случаев, вы увидите Able to merge.
Если же есть конфликты, вам скорее всего придется пересмотреть ваши изменения.
Далее нажимаем кнопку — Create Pull Request.
При заполнение имени и описания вашего Pull Request считается хорошей практикой указывать номер Issue, для которого создан ваш Pull Request.
Обычно для многих крупных проектов настроен CI сервер, часто Travis-CI.
После создания Pull Request он будет прогонять тесты, возможно какие-то инструменты для метрик и так далее. Результы его работы вы увидите в Вашем Pull Request как показано ниже:
В случае, если тесты не будут пройдены или билд не будет собран, вы увидите красное сообщение об ошибке и по ссылку Details сможете увидите, что же именно не так. В большинстве случае вам необходимо будет исправить ваш Pull Request, чтобы все проверки проходили успешно.
Если с вашим Pull Request все хорошо, то в скором времени он будет смержен кем-то из команды.
Но часто бывает, что разработчики попросят вас внести какие-то изменения.
Для этого просто возвращаемся к шагу 6 и после внесения изменений и коммита выполняем похожие команды:
git checkout <ИМЯ-ВАШЕЙ-ВЕТКИ>
git fetch upstream
git rebase upstream/master
git push origin <ИМЯ-ВАШЕЙ-ВЕТКИ>
Примечание: Лично я люблю отправлять Pull Request лишь с 1 коммитом. Для этого я делаю «squash» ненужных коммитов. Как это сделать можно прочитать здесь: gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
После того, как ваш Pull Request был принят или же отвергнут, Вам необходимо удалить ветку с Вашими изменениями.
Делается это просто
git checkout master
git branch -D <ИМЯ-ВАШЕЙ-ВЕТКИ>
git push origin --delete <ИМЯ-ВАШЕЙ-ВЕТКИ>
Вместо последней команды также можно выполнить
git push origin :<ИМЯ-ВАШЕЙ-ВЕТКИ>
Не ленились и участвовуйте в Open Source проектах. Это огромный и интересный опыт, а также галочка в резюме.
Представленные результаты и исследования подтверждают, что применение искусственного интеллекта в области контрибьютинг имеет потенциал для революции в различных связанных с данной темой сферах. Надеюсь, что теперь ты понял что такое контрибьютинг, open source, contributing, контрибьютер и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем