Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

2 Адаптированный перевод статьи<a>The beginner's guide to contributing to a GitHub project</a>. Здесь приведены только общие рекомендации по работе с Open Source из визуального интерфейса GitHub. Обязательно ознакомьтесь с README выбранного вами проекта для уточнения деталей.

3 <h2>Содержание</h2>

4 <ul><li><a>Шаг 0: Выберите проект</a></li>

5 <li><a>Шаг 1: Создайте рабочую копию на своем компьютере</a></li>

6 </ul><h2>Шаг 0: Выберите проект</h2>

7 На эту тему очень много статей. Мы будем считать, что вы уже выбрали проект и решились на свой первый шаг. Для примера используется работа над реальным PR в проект<a>Хекслет Sicp</a>.

8 <h2>Шаг 1: Создайте рабочую копию на своем компьютере</h2>

9 Прежде всего, вам нужен локальный форк проекта, поэтому нажмите кнопку "Fork" в GitHub.

10 Это создаст копию репозитория в вашем аккаунте на GitHub. При переходе в вашу копию проекта вы увидите, откуда он был форкнут:

11 Теперь вам нужна локальная копия, найдите "SSH clone URL" - справа, вверху.

12 Используйте эту ссылку для клонирования проекта на ваш компьютер с помощью терминала. Если вы не знаете, как им пользоваться - на Хекслете есть<a>большой курс по базовым командам в командной строке</a>.

13 Результат будет выглядеть примерно так:

14 Перейдите в директорию нового проекта:

15 Теперь необходимо установить связь локальной копии с оригинальным проектом, чтобы вы могли получать изменения основного проекта и вносить их в свою локальную копию. Сначала перейдите по ссылке в оригинальный репозиторий - она помечена как "forked from" в верхней части страницы GitHub. Это вернет вас на главную страницу проекта на GitHub, где вы сможете найти "SSH clone URL" и использовать его для создания новой связи, которую мы назовемupstream.

16 Теперь ваша локальная копия проекта связана с двумя репозиториями на GitHub:

17 <ol><li>origin, который указывает на ваш форк проекта на GitHub. Вы можете читать его, и писать в этот репозиторий.</li>

18 <li>upstream, который указывает на GitHub-репозиторий основного проекта. Этот репозиторий можно только читать.</li>

19 </ol><h3>Шаг 2: Заставьте его работать на вашей машине</h3>

20 Теперь, когда у вас есть исходный код, запустите его на своем компьютере. Надеюсь, в файле README или INSTALL этих проектов будет документация, как это сделать.

21 Если у вас все работает, но документация неясна, то улучшение этого раздела должно стать вашим первым PR в проекте. Это одновременно и самый простой и полезный способ войти в проект!

22 <h3>Шаг 3: Сделайте что-нибудь полезное</h3>

23 Это самый приятный этап - внести свой вклад в проект. Начните лучше c исправления ошибки, которая вас раздражает. Либо найдите подходящую в трекере проблем проекта - "<a>Issues</a>". Если вы не уверенны, с чего начать, многие проекты используют ярлык "good first issue" (или его разновидность), чтобы указать, что эту проблему может решить даже новичок в проекте.

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

25 <h4>Ветвление</h4>

26 Важное правило - размещать каждую часть разработки в отдельной ветке. Изучите, какая модель ветвления используется в проекте. Если в документации бранч-стратегия не описана, посмотрите, как называются уже существующие ветки. Вы можете назвать свою ветку как угодно, но важно, чтобы она была осмысленной. Названия веток типа "feature", "bugfix", "hotfix", "update" с указанием на то, что меняется - это лучший вариант.

27 В нашем примере мы исправляем README.md, поэтому мы создадим ветку readme-update:

28 В первую очередь мы убеждаемся, что находимся на _ main_-ветке. Затем команда git pull синхронизирует нашу локальную копию с основной веткой проекта, а команда git push синхронизирует ее с нашим форкнутым проектом на GitHub. Наконец, мы создаем новую веткуreadme-update.

29 Теперь вы можете заняться устранением проблемы.

30 Если в проекте есть тесты, запустите их, чтобы убедиться, что вы ничего не сломали. Вы также можете добавить новый тест, чтобы показать, что ваше изменение устраняет первоначальную проблему.

31 Убедитесь, что вы исправляете только то, над чем работаете. Не поддавайтесь искушению исправить другие вещи, которые вы видите по пути, включая проблемы форматирования, так как ваш PR, скорее всего, будет отклонен.

32 Убедитесь, что вы коммитите логичными блоками. Каждый коммит должен быть обоснованным. Прочитайте статью<a>Как правильно составлять описания коммитов и почему это важно</a>.

33 <h3>Шаг 4: Создайте Pull Request</h3>

34 Чтобы создать PR, вам нужно отправить ветку в ваш форк на GitHub, а затем нажать несколько кнопок на GitHub.

35 Чтобы отправить новую ветку:

36 В результате будет создана ветка в вашем проекте на GitHub. Флаг -u связывает эту ветку с удаленной, так что в будущем вы сможете просто набрать git push origin в терминале.

37 Вернитесь в браузер и перейдите к вашему форку проекта (в нашем примере это будет выглядеть вот<a>так</a>, и вы увидите, что ваша новая ветка появилась в верхней части с удобной кнопкой "Compare & pull request":

38 Нажмите эту кнопку!

39 Если вы видите выделенную надпись, как показано ниже:

40 Нажмите на ссылку, которая приведет вас к файлу CONTRIBUTING проекта, и прочитайте его! Он содержит ценную информацию, как работать с кодовой базой проекта, и поможет вам добиться одобрения вашего вклада.

41 На этой странице убедитесь, что "base repository" и "base" указывает на правильный репозиторий и ветку. Затем дайте хорошее, краткое название вашему запросу и объясните, почему вы его создали в поле описания. Добавьте соответствующие номера проблем, если они у вас есть.

42 Ниже в примере выполнена работа с веткой Master, но вам для работы с Хекслетом нужно работать с веткой main.

43 Если вы прокрутите страницу немного вниз, вы увидитеdiffс вашими изменениями. Дважды проверьте, что он содержит то, что вы ожидаете.

44 Как только вы будете уверены, нажмите кнопку "Create pull request" и все - готово.

45 <h3>Шаг 5: Проверка разработчиками проекта</h3>

46 Чтобы ваши изменения были приняты в проект, разработчики должны проанализировать вашу работу. После этого они либо запросят изменения, либо объединят ее с основной веткой (либо отклонят их).

47 Зачем и как нужно ревьюить код, вы можете посмотреть<a>Вебинар о код-ревью: зачем он нужен, как оптимизировать код и как делают в Skyeng</a>.

48 <h3>Итоги</h3>

49 Главные этапы работы в Open Source:

50 <ol><li>Форкни проект и склонируй его на свой компьютер.</li>

51 <li>Установи связь с основным репозиторием проекта (upstreamremote) и синхронизируй с ним локальную копию.</li>

52 <li>Создавай локальный бранч для каждого логического блока работы.</li>

53 <li>Внеси изменения, создавай<a>хорошие описания коммитов</a>и читай файл CONTRIBUTING, если он есть.</li>

54 <li>Синхронизируй изменения со свом форком (originremote).</li>

55 <li>Создай Pull Request на GitHub.</li>

56 <li>Отвечай на все замечания, полученные в ходе<a>код-ревью</a>.</li>

57 </ol><h3>Дополнение от переводчика</h3>

58 Оригинальная статья была написана в 2015 году. С тех пор вышла GitHub cli, и в git появились новые команды. Теперь эти шаги можно сделать ещё проще.

59 <ol><li>gh repo fork Hexlet/hexlet-sicp</li>

60 <li>git switch -c readme-update</li>

61 <li>Тут делаем полезные изменения</li>

62 <li>git push -u origin readme-update</li>

63 <li>gh pr create --title "update README.md" --body "Slightly updated Russian README"</li>

64 <li>Тут ревью кода и успешное принятие вашего PR</li>

65 </ol>