{"meta":{"title":"Вклад в open source","intro":"Узнайте, как внести вклад в проект open source, который будет принят сопровождающими.","product":"Начало работы","breadcrumbs":[{"href":"/ru/get-started","title":"Начало работы"},{"href":"/ru/get-started/exploring-projects-on-github","title":"Изучение проектов"},{"href":"/ru/get-started/exploring-projects-on-github/contributing-to-open-source","title":"Внесите вклад в open source"}],"documentType":"article"},"body":"# Вклад в open source\n\nУзнайте, как внести вклад в проект open source, который будет принят сопровождающими.\n\nВ этой статье вы узнаете, как внести вклад в проект с open source, проработав пример. Мы поможем вам внести свой вклад `github/docs` в репозиторий: знакомство с репозиторием, поиск области для участия, отправки и отправки запроса на вытягивание, а также работы со службами поддержки для принятия изменений.\n\n## Ориентирование на себя с помощью рекомендаций по проекту\n\nПрежде чем начать, важно понять рекомендации и требования проекта.\n\n### Почему важны рекомендации?\n\nКаждый проект имеет собственные соглашения, стандарты кодирования и процессы вклада, которые необходимо выполнить.\n\n* **Требования к стилю кода и форматированию:** форматирование кода, соглашения об именовании и правилах подстраивание\n* **Рекомендации по тестированию:** как выполнять тесты, какие тесты требуются для новых функций и соглашений о тестировании\n* **Процесс запроса на вытягивание:** структура запроса на вытягивание, сведения, которые необходимо включить, и проверить ожидания\n* **Настройка разработки:** настройка локальной среды разработки, необходимых зависимостей и процессов сборки\n* **Отчеты о проблемах:** как сообщать об ошибках, функциях запроса или задавать вопросы\n* **Каналы коммуникации:** где задавать вопросы, обсуждать изменения или получать помощь от обслуживающих\n\nВремя, чтобы прочитать эти данные, сэкономит время, как для вас, так и для хранителей, и сделать его более вероятным, что ваш вклад будет принят.\n\n### Поиск рекомендаций\n\nЧтобы получить доступ к этим рекомендациям и требованиям, перейдите в **контрольный список \"Стандарты** сообщества\" на вкладке **\"Аналитика** \". В нашем примере мы будем использовать [`github/docs` стандарты](https://github.com/github/docs/community) сообщества.\n\n* **README:** предоставляет общие сведения о проекте. Содержимое может отличаться, но README помогает пользователям и участникам быстро понять, что такое проект и как его использовать, а также ссылки на другую документацию.\n\n* **Кодекс поведения:** определяет допустимые стандарты поведения для участников проекта и членов сообщества, а также устанавливает ожидания и процедуры для устранения нарушений.\n\n* **Участие.** Предоставляет рекомендации и инструкции для участников проекта. Это помогает упростить процесс вклада, задав четкие ожидания и поощряя последовательную совместную работу.\n\n* **Лицензия:** юридически определяет, как другие могут использовать, изменять и распространять код, защищая как обслуживающих, так и пользователей, устанавливая четкие условия для авторских прав и разрешений.\n\n * Например, `github/docs` репозиторий использует лицензию Creative Commons для документации, которая является типом лицензии, специально предназначенной для творческих работ. Код `github/docs` программного обеспечения находится под лицензией MIT, которая является разрешительной лицензией, которая позволяет любому пользователю использовать код, содержащийся в нем.\n * Вы можете узнать о других распространенных типах лицензий с помощью [средства выбора лицензии](https://choosealicense.com/licenses/) .\n\n* **Политика безопасности.** Предоставляет инструкции по созданию отчетов об уязвимостях безопасности для обслуживания репозитория.\n\nПросмотрите все ресурсы, доступные для `github/docs` репозитория.\n\n## Поиск области для участия\n\nПри первом участии в проекте, начиная с незначительных исправлений, таких как улучшения документации или небольшие отчеты об ошибках, можно ознакомиться с рабочей процессом базы кода и участника. В этом примере вы будете искать проблемы с помощью `help wanted` меток и `good first issue` меток для решения конкретных проблем, открытых для внешних участников. Затем вы будете использовать Copilot для предоставления контекста о проблеме.\n\n1. Перейдите на \\*\\*\\*\\*\" репозитория, а затем используйте `github/docs` и выберите \"Нужная помощь\", чтобы просмотреть открытые проблемы, которые поддержку специально помечают как нуждающиеся в помощи сообщества.\n\n2. Просмотрите список проблем и найдите интересующий вас вопрос.\n\n3. Перейдите к [https://github.com/copilot](https://github.com/copilot?ref_product=copilot\\&ref_type=engagement\\&ref_style=text).\n\n4. В поле запроса введите следующую строку:\n\n ```text copy\n Can you summarize the key points and next steps from this issue?\n ```\n\n5. Прочитайте контекст Copilot и комментарии других участников и поддержку, чтобы узнать, является ли проблема одной из них. Если у вас есть конкретные вопросы, вы можете задать непосредственно в этой проблеме или в дискорде проекта, IRC или Slack, если применимо.\n\n> \\[!TIP] Если вы когда-либо работаете над проблемой \\*\\*\\*\\*`help wanted` меток, рекомендуется попросить поддержку в этом вопросе, если вы можете открыть запрос на вытягивание, чтобы подтвердить запланированный вклад в соответствии с целями проекта.\n\n## Создание собственной копии проекта\n\nТеперь вы готовы приступить к участию. Так как у вас нет доступа к редактированию репозитория, сначала необходимо создать **вилку**: собственную копию репозитория, где можно безопасно вносить изменения и отправлять их обратно для проверки обслуживания. В этом примере мы рассмотрим создание вилки репозитория `github/docs` .\n\n1. Перейдите к проекту `GitHub Docs` на .\n\n2. В правом верхнем углу страницы щелкните **Вилка**.\n\n3. В разделе \"Владелец\" выберите раскрывающееся меню и щелкните владельца для вилированного репозитория.\n\n4. По умолчанию вилки называются теми же, что и их вышестоящий репозиторий. При необходимости для дальнейшего отличия вилки в поле \"Имя репозитория\" введите имя.\n\n5. При необходимости в поле \"Описание\" введите описание вилки.\n\n6. При необходимости выберите \" **Копировать только** ветвь DEFAULT\".\n\n Для многих сценариев разветвления, таких как участие в проектах с открытым кодом, необходимо скопировать только ветвь по умолчанию. Если этот параметр не выбран, все ветви будут скопированы в новую вилку.\n\n7. Нажмите **Создать вилку**.\n\n## Клонирование вилки проекта\n\nТеперь у вас есть вилка репозитория `github/docs` в вашей учетной записи, но вам нужно получить его на локальный компьютер, чтобы приступить к работе с изменениями.\n\n1. В GitHubперейдите к **вилку** репозитория `github/docs` .\n\n2. Над списком файлов щелкните ** Code**.\n\n ![Снимок экрана: список файлов на целевой странице репозитория. Кнопка \"Код\" выделена темно-оранжевым контуром.](/assets/images/help/repository/code-button.png)\n\n3. Скопируйте URL-адрес репозитория.\n\n * Чтобы клонировать репозиторий с помощью HTTPS, в разделе \"HTTPS\" нажмите .\n * Чтобы клонировать репозиторий с помощью ключа SSH, включая сертификат, выданный центром сертификации SSH вашей организации, щелкните **SSH**, а затем щелкните .\n * Чтобы клонировать репозиторий с помощью GitHub CLI, щелкните **GitHub CLI**, а затем щелкните .\n\n ![Снимок экрана: раскрывающееся меню \"Код\". Справа от URL-адреса HTTPS для репозитория значок копирования описывается темно-оранжевым цветом.](/assets/images/help/repository/https-url-clone-cli.png)\n\n4. В Mac или Linux откройте терминал. В Windows откройте Git Bash.\n\n5. Измените текущий рабочий каталог на расположение, где должен находиться клонированный каталог.\n\n6. Введите `git clone`, а затем вставьте URL-адрес, скопированный ранее. Это будет выглядеть следующим образом: вместо имени пользователя GitHub :`YOUR-USERNAME`\n\n ```shell copy\n git clone https://github.com/YOUR-USERNAME/docs\n ```\n\n7. Нажмите клавишу **ВВОД**. Будет создан локальный клон.\n\n## Внесение изменений в ветвь раздела\n\nТеперь пришло время внести изменения! Перед началом работы рекомендуется создать **ветвь** раздела с **описательным именем** в вилке. Использование ветви разделов позволяет сохранять работу отдельно от ветвь по умолчанию репозитория.\n\n```shell copy\ngit checkout -b YOUR_TOPIC_BRANCH\n```\n\nПосле переключения в ветвь раздела откройте любимый текстовый редактор или интегрированную среду разработки и начните писать код. Следуйте приведенным далее рекомендациям.\n\n* Используйте Copilot для предоставления предложений кода, что дает вам уверенность в изменениях.\n* Задокументируйте код и напишите тесты. Это часто не учитывается и может помочь обеспечить объединение вашего вклада.\n* Попросите Copilot вопросы об этой проблеме, чтобы получить более подробные сведения о требованиях к реализации.\n* Используйте Copilot для проверки изменений, чтобы убедиться, что они соответствуют стилю кода проекта и требованиям к документации.\n* Используйте Copilot для получения инструкций по созданию и тестированию проекта на локальном компьютере.\n\n## Фиксация и отправка изменений\n\nКогда изменения будут готовы, вы можете выполнить этап и зафиксировать их в репозитории. При написании сообщения фиксации используйте четкое краткое название фиксации в 50 символов, которые суммируют то, что делает фиксация. Группируйте связанные изменения в отдельные фиксации, если это возможно, но сохраняйте несвязанные изменения в отдельных фиксациях.\n\n```shell copy\ngit add .\ngit commit -m \"a short description of the change\"\n```\n\nПопробуйте сохранить строки описания фиксации в 72 символах для повышения удобочитаемости. Когда вы завершите фиксацию локальных изменений и готовы отправить их в GitHub, отправьте изменения в удаленный.\n\n```shell copy\ngit push\n```\n\n## Отправка запроса на внесение изменений\n\nПосле отправки изменений в GitHubвы можете открыть запрос на вытягивание. Вы можете открыть запрос на вытягивание для проверки, даже если вы не завершили изменения, внесенные в вашей ветви. Открытие запроса на вытягивание в начале процесса вклада дает осведомленность о обслуживающих, и позволяет им предоставлять первоначальные отзывы о ваших изменениях.\n\n1. Зайдите в свой форкированный репозиторий на GitHub. Например: `https://github.com/YOUR-USERNAME/docs`.\n2. Появится запрос на сравнение и запрос на вытягивание для недавно отправленной ветви. Нажмите ее.\n3. В противном случае перейдите на вкладку \"Запросы на вытягивание\" и нажмите кнопку \"Создать запрос на вытягивание\".\n4. Убедитесь, что базовый \\*\\*\\*\\* репозиторий находится`github/docs`, и базовая ветвь является их основной ветвью (например, `main`).\n5. Убедитесь, что головной\\*\\* репозиторий \\*\\*является вашим вилкой (`YOUR-USERNAME/docs`) и ветвь сравнения является вашей ветвью.\n6. Введите название и описание для запроса на вытягивание. В описании обратитесь к проблеме, в которую будет закрыт запрос на вытягивание. Например: `Closes: #15`. Это обеспечит контекст запроса на вытягивание и автоматически закрывает проблему после объединения запроса на вытягивание.\n\n> \\[!TIP] Избегайте принудительная отправка после отправки запроса на вытягивание для проверки. Это затрудняет обслуживание, чтобы увидеть, что вы обращаетесь к своим отзывам.\n\n## Работа с обслуживателями проектов\n\nПосле отправки запроса на вытягивание следующий шаг предназначен для поддержки проекта для просмотра и предоставления отзывов. Обслуживание проектов может запрашивать изменения в соответствии со стилем или архитектурой базы кода, иногда требуя рефакторинг существенных частей работы.\n\n* Когда обратная связь поступает о запросе на вытягивание, реагировать быстро и профессионально, даже если критика чувствует себя жесткой. Обслуживающие специалисты обычно ориентированы на качество кода.\n* Если изменения запрашиваются для запроса на вытягивание, не открывайте новый запрос на вытягивание, чтобы устранить изменения. Сохранение существующего запроса на вытягивание и внесение изменений в нее помогает предотвратить потерю контекста хранителями.\n* Если запрос на вытягивание остается незамеченным в течение нескольких недель, вежливо следите за комментарием, запрашивающим отзыв.\n \\*\\* Не упоминайте \\*\\*непосредственно дескрипторы обслуживания. Сопровождающие часто балансируют между работой с open source и полными обязанностями, а понимание ограничений по времени способствует лучшему сотрудничеству.\n* Если ваш вклад не принимается, попросите поддержку отзывов, чтобы вы могли иметь этот контекст в следующий раз, когда вы хотите внести вклад.\n\n## Следующие шаги\n\nТеперь вы знаете, как определить правильные проблемы для работы, создать вклады, которые поддержку хотят объединить, и как перейти к процессу проверка запроса на вытягивание. Сообщество open source на GitHub готово принять ваш уникальный взгляд и навыки. Найдите новый проект, который возбуждает вас, определите проблему для работы и начните вносить свой вклад."}