proglib
Сообщение

Почему специалистом по кибербезопасности быть интереснее, чем разработчиком или сисадмином? Приглашаем на вебинар от HackerU

Почему специалистом по кибербезопасности быть интереснее, чем разработчиком или сисадмином? Приглашаем на вебинар от HackerU

eFusion 03 февраля 2020

Вдарим по опенсорсу: как без страха прокачать свой аккаунт на Github

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

Открытые репозитории 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 форкнутого репозитория по соответствующим подсказкам.

Ветка и репозиторий слева указывают на соответствующие объекты, c которыми вы хотите смержиться. Репозиторий должен быть основным для проекта, а ветка – та, от которой вы клонировались. Справа – форкнутый репозит и его ветка, с которыми вы недавно работали.

Теперь всё готово, следуйте соглашению команды об именовании запроса. В рассматриваемом примере даётся название коммита и в скобках номер issue.

Обратите внимание, на последнюю строчку: Fixed dotnet/docs#10675.

Это «волшебная» строка, с помощью которой GitHub связывает коммит с правильным номером issue (#10675) из репозитория docs.

Как только всё готово, нажимаем Create pull request.

Что дальше?

Поздравляем, вы внесли небольшой вклад в опенсорсный проект.

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

В нашем примере изменения были оперативно рассмотрены и приняты, о чём GitHub сообщил в уведомлении.

Заключение

Библиотека программиста настоятельно рекомендует попробовать внести свой вклад в открытое программное обеспечение. Найдите интересный для вас проект и действуйте. Начните с простого проекта, посмотрите как всё работает, а затем беритесь за что-то объёмное. Разработка open source всегда приносит свои плоды, будь то новые навыки, знакомства или просто удовольствие от того, что вы делаете мир лучше.

Источники

РУБРИКИ В СТАТЬЕ

МЕРОПРИЯТИЯ

Комментарии 0

ВАКАНСИИ

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

BUG