Открытые репозитории 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 всегда приносит свои плоды, будь то новые навыки, знакомства или просто удовольствие от того, что вы делаете мир лучше.