Когда вы в начале пути программиста, почти всё обучение происходит в вакууме. Вы пишете пет-проекты, смотрите бесконечные курсы и решаете задачи, результат которых увидите только вы сами. Но реальная разработка, это часто про командную игру.

Open Source — отличный способ выйти за пределы учебной песочницы. Это возможность заглянуть под капот известных инструментов, поработать плечом к плечу с опытными разработчиками и внести вклад в продукты, которыми пользуются тысячи людей.

Постепенно, у вас появляется публичный опыт, это реальные pull requests, которые может посмотреть любой. Даже вклад в небольшой проект показывает что вы умеете работать с чужим кодом, и понимаете Git-workflow. Если вы участвовали в известном проекте, это можно использовать в резюме.

1. С чего начинается любой Open Source проект ?

Перед тем как писать код, важно понять, как устроен проект и по каким правилам он живёт.

1. README.md — это фундаментальный документ любого проекта с открытым исходным кодом, выполняющий сразу три ключевые роли: техническую инструкцию, маркетинг вашего проекта и приглашение к сотрудничеству.

2. CONTRIBUTING.md — это правила входа. Автор проекта обычно прописывает здесь, как оформлять коммиты, как запускать тесты и в какие ветки писать код. Обязательно прочитайте его.

3. Лицензия — определяет юридические правила использования кода: можно ли его копировать, изменять и использовать в коммерческих проектах. Например, MIT License разрешает почти всё, а GPL требует, чтобы производные проекты тоже оставались открытыми.

2. Где найти свою первую задачу?

GitHub огромен, и новичку легко утонуть в тысячах заброшенных репозиториев. Чтобы не тратить часы на ручной поиск «живых» проектов, и находить актуальные задачи, удобно использовать специализированный инструмент.

OpenSourceHub.tech — это платформа, где собраны проекты, открытые для контрибьюта, и дружелюбные issues, подходит для новичков и опытных разработчиков.

Существует множество различных фильтров. Включите чекбокс «Лёгкий вход», он покажет именно те задачи с которых удобно начать в новом проекте. Используйте фильтры по Labels, можно сразу найти задачи по созданию фичи (feature), исправлению багов (bug), написанию тестов (tests), и написание документации (docs).

У тебя есть Open Source проект?

Даже если он небольшой и у него мало звёзд, не держите его взаперти! На OpenSourceHub.tech можно добавить свой проект или issues на платформу, дай ему шанс получить: звёзды, обсуждение, интерес со стороны других разработчиков и первые контрибьюты в дружелюбной среде.

Вступай в наше Telegram-сообщество «Опенсорсеры». Тут помогают сделать первый вклад, и не чувствовать себя потерянным в начале пути, можно получить совет и найти проекты, в которые действительно хочется внести вклад. Есть отдельная рубрика, мы разбираем Open Source проекты участников. Цель таких разборов помочь авторам взглянуть на свой репозиторий глазами пользователя и потенциального контрибьютора.

3. Берем Issue в работу

Вы нашли подходящую задачу. Что дальше?

На платформе только актуальные задачи, но всё равно посмотрите на правую колонку в GitHub и проверьте Assignees. Если там уже висит чья-то аватарка то значит задача занята.

Пример: «Hi @author_name! I want to take on this task. Is it still relevant?»

4. После того как вас назначили на задачу, можно начинать работу.

1. Создайте Fork. Нажмите кнопку Fork в верхнем углу страницы репозитория на GitHub. Копия проекта появится в вашем аккаунте.

2. Клонируйте форк локально:

   git clone https://github.com/ваш_ник/название_проекта.git
   

3. Создайте новую ветку. Никогда не делайте правки в ветке main. Используйте префиксы для разных типов веток. Префиксы помогают быстро идентифицировать тип ветки и характер изменений.

   Общепринятые префиксы: feature/ — для новых функций (например, feature/new-post-form), bugfix/ или fix/ — для исправление ошибок, hotfix/ — срочные исправления прямо в рабочей ветке, release/ — для подготовки релизов (например, release/0.2.0), refactor/ — структурные изменения кода, не влияющие на функциональность, docs/ — обновления документации.

   Например: test/42-cli-runner, где 42 номер вашего Issue.

   git checkout -b test/42-cli-runner
   

   Эта команда создаёт новую ветку и сразу переключает вас на неё.

5. Код и коммиты

После того как вы внесли изменения, нужно сделать commit с описанием проделанной работы. Хорошим тоном считается использование Conventional Commits, это простая система заголовков.

 git commit -m "test: cli runner (#42)"

Затем отправьте вашу ветку с локального компьютера на GitHub (в ваш форк):

git push origin test/42-cli-runner

6. Pull Request (PR)

После этого отправляем изменённую ветку, нажмите на GitHub кнопку "Open pull request"

В заголовке PR кратко расскажите, что вы сделали. И в описании опишите подробности. В конце добавьте: fixes #42, чтобы когда автор примет ваш PR, GitHub автоматически закроет задачу.

После создания PR начинается code review. Мейнтейнер может принять изменения сразу, оставить комментарии или попросить внести правки. Это нормальная часть процесса. Если вас просят что-то исправить, просто внесите изменения и отправьте их в ту же ветку. Pull Request обновится автоматически.

Когда всё будет готово, мейнтейнер нажмёт кнопку Merge и ваш вклад станет частью проекта. Это и есть тот самый момент, когда вы становитесь контрибьютором!

Заключение

Сегодня добавите тест. Завтра добавите фичу. Через неделю будете уверенно отправлять pull request в чужие проекты. А через пару месяцев уже возможно откроете свой.

Если вы хотите получить обратную связь и поддержку, найти пользователей и контрибьютеров для своего проекта присоединяйтесь в наше сообщество: t.me/OpenSource_Chat