Как сделать pull request в репозиторий GitHub?

2023-08-28T10:44:22.224Z

Мечта №1658 создать open-source проект, где бдует столько же pull request'ов

В мире open source многое программное обеспечение создается сообществом - т.е людьми, которые заинтересованы в развитие того или иного проекта. Это могут быть гигантские проекты типа Linux или небольшие библиотеки для вашего любимого DJango.

Разумеется в написанном коде, особенно в Open Source от условного Васяна, встречаются ошибки. Хорошая новость состоим в том, что каждый может внести свой вклад в общее дело и самостоятельно пофиксить баги, отправив pull request чтобы исправления вошли в главную ветку.

Как же отправить pull request?

Шаг 1: делаем форк репозитория

Для этого заходим в нужный репозиторий и нажимаем кнопку "Fork"

Шаг 2: клонируем репозиторий и создаем новую ветку

Клонировать нужно наш форк основного репозитория, с нашего аккуанта. Для этого выполняем команду git clone <адрес репозитория>.

Затем:

git checkout -b <branch-name>

Шаг 3: создаем коммит и пушим изменения

После внесения изменений в код коммитим все изменения и пушим их.

Шаг 4: отправляем pull request

Для этого в основном репозитории переходим на вкладку Pull requests и жмем New pull request, где выбираем наш коммит, который был создан в прошлом шаге.

После отправки pull request'а, владелец репозитория должен будет проверить код и произвести слияние веток чтобы изменения попали в главную ветку.

Вот такими простыми действиями можно не только быть полезным сообществу, но и научиться читать чужой код, что является важным навыком при работе в команде.

Поиск и чтение документации — главные навыки программиста

2023-08-28T09:04:30.749Z

Вездесущий Goooogle как бы...

Решил тут внести свой вклад в общественное дело и завел аккаунт на Toster.ru. Если кто не в курсе - это рускоязычный аналог Stackoverflow от комнады Хабра.

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

Читая в очередной раз банальный вопрос, я удивился тому, что не все люди умеют гуглить и читать документацию. Казало бы, это настолько банальный навык - уметь гуглить свои вопросы и читать документацию к либам и фреймворкам. Ничего сложного. Но оказывается не каждый умеет это делать.

Вопрос, который как бы гуглиться за считанные секунды

Работая разработчиком или только изучая программирование, просто жизненно необходимо научиться гуглить и работать с документацией. Без этого в нашей сфере - никак.

Как это сделать? Не знаю. Потому, что я научился делать это исключительно в процессе обучения, самостоятельно. Я ничего не знал про Stackoverflow, не про существование документаций. И максимально глупо искал ответы на свои вопросы в Яндексе, копировал коды и сообщения об ошибках.

Немного подумав, я собрал несколько рекомендаций которые могут пригодиться для тех, кто только учиться:

1. Нужно отказать от русского языка.

Совсем? Да. Совсем.

Как показывает суровая реальность, большинство фреймворков и библиотек создаются не в ~~НИИ им. Ленина~~. Даже если разработчик является носителем русского языка, документация будет все равно написана на английском. Потому что английский - это международный язык. И ничего с этим не поделать.

Гуглинг на английском разумеется делает вас труЪ-программистом (нет)

Конечно есть переводы документации для популярных фреймворовков и даже библиотек на русский. Но, как правило, их актуальность уже просрочена на пару-тройку версий. Что может быть весьма критичным.

Это, кстати, одна из основных причин по которой IT специалистам жизнено необходимо знать английский.

2. Приступая к работе с новой библиотекой или фреймворком, всегда читаем раздел "Quick start" (быстрый старт).

Как правило любая документация обладает таким разделом, где коротко, понятно и с примерами объясняется как подключать и использовать библиотеку или фреймворк. Также, зачастую, предоставляется разбор различных кейсов.

Пример документации фреймворка DJango

На старте может показаться, что чтение документации отнимает кучу времени. И это действительно может быть так. Однако - это экономит время в процессе разработки, т.к снижает потребность гуглить банальные вопросы.

3. Если бибилиотека или фреймворк выдает ошибку, пробуем найти пути её решения в Issues на Github.

Как правило любые адекватные библиотеки и фреймворки разрабатываются сообществом. А вся разаработка ведется через Git. В 2023 году Git - это не просто система контроля версий, а целый инструмент для ведения разработки и выкатывания версий.

В каждом репозитории на Github или Gitlab, есть раздел с проблемами - Issue, где пользователи могут публиковать всевозможные проблемы, баги и прочее.

Пример раздела Issues к рандомному проекту на GitHub

К счастью, с высокой долей вероятности, ваша ошибка не является уникальной, а решение или хотя бы дополинительная информация уже есть в Issue на Github. Поэтому смело учимся пользоваться данным разделом.

4. Не стесняемся спрашивать, но только после того, как поиск не дал результатов.

Спрашивать у других - можно и нужно. Но ради своего же блага, нужно уметь искать информацию самостоятельность в документации, Issue и поиске.

Если же результаты мучительно поиска и чтения документация ~~до красноты глаз (обязательно!)~~ не дают результатов, то смело идем на профильные ресурсы, типа Stackoverflow и Toster, и задаем вопрос. Программисты (в большинстве своем) люди простые и всегда готовые помочь.

Сколько же ~~прекрасных~~ часов проведено за чтением сие ресурса...

Также не стесняемся открывать свои Issue на Github, тем самым помогая разработчикам и сообществу в решение общих проблем.

Dmitry Buryakov