Вдарим по опенсорсу: как без страха прокачать свой аккаунт на Github
Из статьи вы узнаете, как избавиться от страха отправки первого 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 форкнутого репозитория по соответствующим подсказкам.
Ветка и репозиторий слева указывают на соответствующие объекты, c которыми вы хотите смержиться. Репозиторий должен быть основным для проекта, а ветка – та, от которой вы клонировались. Справа – форкнутый репозит и его ветка, с которыми вы недавно работали.
Теперь всё готово, следуйте соглашению команды об именовании запроса. В рассматриваемом примере даётся название коммита и в скобках номер issue.
Обратите внимание, на
последнюю строчку: Fixed dotnet/docs#10675.
Это «волшебная» строка, с помощью которой GitHub связывает коммит с правильным номером issue
(#10675) из репозитория docs.
Как только всё готово, нажимаем Create pull request.
Что дальше?
Поздравляем, вы внесли небольшой вклад в опенсорсный проект.
Ваш код должен пройти автоматические проверки (чаще всего это билд и анализ кода), прежде чем будет рассмотрен. Кроме того, мейнтейнер проекта разберётся в ваших изменениях и примет решение, внести их в исходный репозиторий или нет.
В нашем примере изменения были оперативно рассмотрены и приняты, о чём GitHub сообщил в уведомлении.
Заключение
Библиотека программиста настоятельно рекомендует попробовать внести свой вклад в открытое программное обеспечение. Найдите интересный для вас проект и действуйте. Начните с простого проекта, посмотрите как всё работает, а затем беритесь за что-то объёмное. Разработка open source всегда приносит свои плоды, будь то новые навыки, знакомства или просто удовольствие от того, что вы делаете мир лучше.