Вам понадобится как папка с проектом кода на вашем локальном компьютере (ноутбуке или ПК), так и общедоступный репозиторий на GitHub, который мы используем, чтобы показать, как внести свой вклад в другие проекты.
Допустим, у вас есть локальная папка с каким-то проектом и вы хотите начать отслеживать свой прогресс с помощью системы контроля версий Git. Некоторые люди сравнивают использование git с написанием любовного письма себе в будущем. Читая сообщения коммитов через несколько дней, недель или месяцев, вы сможете вспомнить, почему вы сделали так, а не иначе, или сможете «откатить» изменения.
1.**Создайте репозиторий на GitHub**. На GitHub.com на вкладке репозиториев или в правом верхнем углу панели навигации найдите кнопку **новый репозиторий**.
1.**Перейдите в свою рабочую папку**. В вашем терминале перейдите в папку (также известную как каталог), которую вы хотите начать отслеживать. Введите:
```bash
cd [имя вашей папки]
```
1.**Инициализируйте git репозиторий**. В вашем проекте напечатайте:
```bash
git init
```
1.**Проверьте статус**. Чтобы проверить статус вашего репозитория введите:
```bash
git status
```
вывод может выглядеть примерно так:
```output
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
Обычно команда `git status` сообщает вам, какие файлы готовы к _сохранению_ в репозиторий или в каких есть изменения, которые вы, возможно, захотите сохранить.
1.**Сохраняйте свою работу**. На этом этапе вы добавили файлы в так называемую _staging area (область подготовки)_. Место, где Git отслеживает ваши файлы. Чтобы сделать изменение постоянным, вам необходимо _закоммитить (зафиксировать)_ файлы. Для этого вы создаете _коммит_с помощью команды `git commit`. _Коммит_ представляет собой точку сохранения в истории вашего репозитория. Введите следующее, чтобы создать новый _коммит_:
Эта команда сохраняет все ваши файлы, добавляя сообщение «первый коммит». Для будущих сообщений коммитов вам нужно будет быть более информативным в своем описании, чтобы передать, какой тип изменения вы внесли.
1.**Подключите локальный репозиторий Git к GitHub**. Репозиторий Git хорош на вашем компьютере, но в какой-то момент вы захотите сделать резервную копию ваших файлов, а также пригласить других людей поработать с вами над вашим проектом. Одно из таких прекрасных мест для этого - GitHub. Помните, что мы уже создали репозиторий на GitHub, поэтому единственное, что нам нужно сделать, это подключить наш локальный репозиторий Git к GitHub. Команда `git remote add` предназначена именно для этого. Введите следующую команду:
> Обратите внимание: прежде чем вводить команду, перейдите на страницу репозитория GitHub, чтобы найти URL-адрес репозитория. Вы будете использовать его в приведенной ниже команде. Замените `username/repository_name` своим URL-адресом репозитория на GitHub.
1.**Отправьте локальные файлы в GitHub**. Итак, вы создали _соединение_ между локальным репозиторием и репозиторием на GitHub. Давайте отправим эти файлы на GitHub с помощью следующей команды `git push`, вот так:
1.**Добавление последующих изменений**. Если вы хотите продолжить вносить изменения и отправлять их на GitHub, вам просто нужно использовать следующие три команды:
```bash
git add .
git commit -m "напишите здесь свое сообщения для коммита"
> Совет: вы также можете использовать файл `.gitignore`, чтобы файлы, которые вы не хотите отслеживать, не отправлялись на GitHub. Например, файл заметок, который вы храните в той же папке, но не хотите, чтобы он отображался в публичном репозитории. Вы можете найти шаблоны для файлов `.gitignore` по следующей ссылке [.gitignore templates](https://github.com/github/gitignore).
Для основного сообщения к коммиту используйте повелительное наклонение в настоящем времени: «change», а не «changed» или «changes». Также и в расширенном сообщении (которое необязательно) используйте повелительное наклонение в настоящем времени. Основное сообщение должно включать мотивацию к изменению и противопоставлять это предыдущему поведению. Вы объясняете `почему`, а не `как`.
✅ Потратьте несколько минут, чтобы немного исследовать GitHub. Сможете ли вы найти действительно отличное сообщение к коммиту? Можете ли вы найти минимальное сообщение к коммиту? Какую информацию вы считаете наиболее важной и полезной для передачи в сообщении к коммиту?
- **Описание**. Вы добавили описание для своего проекта?
- **README**. Вы добавили README? GitHub предлагает руководство по написанию [README](https://docs.github.com/articles/about-readmes/).
- **Рекомендации по внесению вклада**. У вашего проекта есть [рекомендации по внесению вклада (contributing guideline)](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/)?
Все эти ресурсы принесут пользу новым членам команды. И это, как правило, те вещи, на которые новые участники смотрят, прежде чем даже взглянуть на ваш код, чтобы узнать, является ли ваш проект подходящим местом для них, чтобы тратить свое время.
✅ Файлы README часто игнорируются занятыми разработчиками из-за нехватки времени на их подготовку. Можете ли вы найти пример README с хорошим описанием проекта? Примечание: есть несколько [инструментов для создания хороших README](https://www.makeareadme.com/), которые вы, возможно, захотите попробовать.
Правила соучастия (например, документ `CONTRIBUTING.md`) помогают людям разобраться, как вносить свой вклад в проект. В нем объясняется, какие типы вкладов вас интересуют и как работает этот процесс. Чтобы внести свой вклад в ваш репозиторий на GitHub, участникам потребуется выполнить ряд шагов:
1.**Сделать ответвление вашего репозитория (Forking)**. Вы, вероятно, захотите, чтобы люди сделали _ответвление (fork)_ вашего проекта. Ответвление означает создание копии вашего репозитория в их профиле GitHub.
1.**Создать ветку**. Вы можете попросить их создать _ветку_ для своей работы.
1.**Сосредоточить свои изменения на одной области**. Попросите участников концентрировать свой вклад на чем-то одном - так шансы, что вы сможете провести _слияние кода_с их работой, будут выше. Представьте, что они написали исправление ошибки, добавили новую функцию и обновили несколько тестов - что, если вы хотите или можете принять только 2 из 3 или 1 из 3 изменений?
> Примечание: будьте тем изменением, которое вы хотите увидеть в мире, и также создавайте ответвления для своей собственной работы. Любые совершаемые вами коммиты будут выполняться в той ветке, в которой вы в настоящее время находитесь. Используйте `git status`, чтобы узнать, какая это ветка.
Давайте рассмотрим рабочий процесс соавтора. Предположим, что соавтор уже _сделал ответвление_ и _склонировал_ ваш репозиторий, поэтому у него на локальном компьютере есть репозиторий Git, готовый к работе:
1.**Совместите свою работу с веткой `main`**. В какой-то момент вы закончили работу и хотите совместить свою работу с работой над веткой `main`. Ветка `main` за это время могла измениться, поэтому убедитесь, что вы сначала обновили ее до последней версии с помощью следующих команд:
На этом этапе вы хотите убедиться, что любые _конфликты_, ситуации, когда Git не может легко _комбинировать_ изменения, происходят в вашей рабочей ветке. Поэтому выполните следующие команды:
Это внесет все изменения из main в вашу ветку, и, надеюсь, вы сможете продолжить. Если нет, VS Code сообщит вам, где Git _не может самостоятельно решить конфликт_, и вы просто измените затронутые файлы, чтобы указать, какой контент является наиболее точным.
1.**Отправьте свою работу на GitHub**. Отправка вашей работы на GitHub означает две вещи. Отправьте свою ветку (push) в репозиторий, а затем откройте пул реквест (сокращенно PR).
1.**Открытие PR**. Далее, вы хотите открыть PR. Вы делаете это, перейдя к ответвленному репозиторию на GitHub. Вы увидите подсказку на GitHub, где вам предложат, хотите ли вы создать новый PR. Вы нажимаете на это указание, и попадаете в интерфейс, где вы можете изменить заголовок сообщения к пул реквесту, можете дать ему более подходящее описание. Теперь владелец репозитория, от которого вы сделали ответвление, увидит этот PR, и (_скрестим пальцы_) он одобрит и примет ваш PR в свой репозиторий. Теперь вы соавтор, ура :)
1.**Чистка (Clean up)**. Хорошей практикой считается _чистка_ после успешного слияния PR. Вы хотите очистить как локальную ветку, так и ветку, которую вы отправили на GitHub. Сначала удалим ее локально с помощью следующей команды:
`Pull request` (дословно: запрос на стягивание) кажется глупым термином, потому что на самом деле вы хотите отправить (push) свои изменения в проект. Но владелец проекта или основная команда должны рассмотреть ваши изменения перед слиянием их с основной ветвью проекта ("main"), поэтому вы действительно запрашиваете разрешение у владедьца о стягивании ваших изменений.
Pull request - это место, где можно сравнить и обсудить изменения, представленные в ветке, проверками, комментариями, интегрированными тестами и т.д. Хороший pull request следует примерно тем же правилам, что и сообщение к коммиту. Вы можете добавить ссылку на вопрос (issue) в систему отслеживания проблем, например, когда вы работаете над устранением проблемы/бага. Это делается с помощью символа `#`, за которым следует номер вашего issue. Например, `# 97`.
Обновите текущую локальную рабочую ветку всеми новыми коммитами из соответствующей удаленной ветки на GitHub с помощью следующей команды:
`git pull`
## Как внести свой вклад в открытый исходный код
Во-первых, давайте найдем репозиторий на GitHub, который вас интересует и в который вы хотели бы внести изменения. Вам неоходимо скопировать его содержимое на свой компьютер.
✅ Хороший способ найти репозитории, удобные для новичков, - это [поиск по тегу 'good-first-issue'](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/).
Есть несколько способов копирования кода. Один из способов - «клонировать» содержимое репозитория, используя HTTPS, SSH или используя GitHub CLI (интерфейс командной строки).
Откройте свой терминал и клонируйте репозиторий вот так:
`git clone https://github.com/ProjectURL`
Для работы над проектом перейдите в правильную папку:
`cd ProjectURL`
Вы также можете открыть весь проект, используя [Codespaces](https://github.com/features/codespaces), встроенный редактор кода / облачная среда разработки GitHub или [GitHub Desktop](https://desktop.github.com/).
Наконец, вы можете загрузить код в заархивированной папке.
### Еще несколько интересных вещей о GitHub
Вы можете отметить, посмотреть и / или «разветвить» любой публичный репозиторий на GitHub. Вы можете найти свои отмеченные репозитории в раскрывающемся меню в правом верхнем углу. Это как закладка, но для кода.
В проектах есть средство отслеживания проблем, в основном на GitHub на вкладке «Проблемы» (Issues), если не указано иное, где люди обсуждают проблемы, связанные с проектом. А на вкладке «Pull Requests» люди обсуждают и просматривают изменения, которые происходят.
Проекты также могут обсуждаться на форумах, в списках рассылки или в чатах, таких как Slack, Discord или IRC.
✅ Осмотрите свой новый репозиторий GitHub и попробуйте несколько вещей, например, отредактируйте настройки, добавьте информацию в репозиторий и создайте проект (например, доску Канбан). Вы можете многое сделать!
---
## 🚀 Челлендж
Объединитесь с другом, чтобы работать над кодом друг друга. Совместно создавайте проект, разветвляйте код, создавайте ветви и объединяйте изменения.
Подробнее об [участие в разработке программного обеспечения с открытым исходным кодом](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
[Шпаргалка по Git](https://training.github.com/downloads/github-git-cheat-sheet/).
Практика, практика, практика. GitHub предлагает отличные способы обучения, доступные через [lab.github.com](https://lab.github.com/):
- [Первая неделя на GitHub](https://lab.github.com/githubtraining/first-week-on-github)
Вы также можете найти более продвинутые лаборатории для практики.
## Задание
Завершите [первую неделю в учебной лаборатории GitHub](https://lab.github.com/githubtraining/first-week-on-github)