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