|
|
<!--
|
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
|
{
|
|
|
"original_hash": "05666cecb8983a72cf0ce1d18932b5b7",
|
|
|
"translation_date": "2025-08-27T22:51:41+00:00",
|
|
|
"source_file": "1-getting-started-lessons/2-github-basics/README.md",
|
|
|
"language_code": "uk"
|
|
|
}
|
|
|
-->
|
|
|
# Вступ до GitHub
|
|
|
|
|
|
Цей урок охоплює основи GitHub — платформи для розміщення та управління змінами у вашому коді.
|
|
|
|
|
|
|
|
|
> Скетчноут від [Tomomi Imura](https://twitter.com/girlie_mac)
|
|
|
|
|
|
## Тест перед лекцією
|
|
|
[Тест перед лекцією](https://ff-quizzes.netlify.app/web/quiz/3)
|
|
|
|
|
|
## Вступ
|
|
|
|
|
|
У цьому уроці ми розглянемо:
|
|
|
|
|
|
- відстеження роботи, яку ви виконуєте на своєму комп'ютері
|
|
|
- роботу над проєктами разом з іншими
|
|
|
- як робити внесок у програмне забезпечення з відкритим кодом
|
|
|
|
|
|
### Попередні вимоги
|
|
|
|
|
|
Перед початком перевірте, чи встановлено у вас Git. У терміналі введіть:
|
|
|
`git --version`
|
|
|
|
|
|
Якщо Git не встановлено, [завантажте Git](https://git-scm.com/downloads). Потім налаштуйте свій локальний профіль Git у терміналі:
|
|
|
* `git config --global user.name "ваше-ім'я"`
|
|
|
* `git config --global user.email "ваш-email"`
|
|
|
|
|
|
Щоб перевірити, чи вже налаштовано Git, введіть:
|
|
|
`git config --list`
|
|
|
|
|
|
Вам також знадобиться обліковий запис GitHub, текстовий редактор (наприклад, Visual Studio Code) і доступ до терміналу (або командного рядка).
|
|
|
|
|
|
Перейдіть на [github.com](https://github.com/) і створіть обліковий запис, якщо у вас його ще немає, або увійдіть і заповніть свій профіль.
|
|
|
|
|
|
✅ GitHub — це не єдине сховище коду у світі; є й інші, але GitHub є найвідомішим.
|
|
|
|
|
|
### Підготовка
|
|
|
|
|
|
Вам знадобиться папка з кодом проєкту на вашому локальному комп'ютері (ноутбуці або ПК) і публічне сховище на GitHub, яке слугуватиме прикладом для того, як робити внески в проєкти інших.
|
|
|
|
|
|
---
|
|
|
|
|
|
## Управління кодом
|
|
|
|
|
|
Припустимо, у вас є папка з кодом проєкту на вашому комп'ютері, і ви хочете почати відстежувати свій прогрес за допомогою git — системи контролю версій. Дехто порівнює використання git із написанням любовного листа до свого майбутнього "я". Читаючи свої повідомлення про коміти через дні, тижні чи місяці, ви зможете згадати, чому прийняли те чи інше рішення, або "відкотити" зміни — за умови, що ви пишете хороші повідомлення про коміти.
|
|
|
|
|
|
### Завдання: Створіть репозиторій і закомітьте код
|
|
|
|
|
|
> Перегляньте відео
|
|
|
>
|
|
|
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
|
|
|
|
|
|
1. **Створіть репозиторій на GitHub**. На GitHub.com, у вкладці репозиторіїв або у верхньому правому куті навігаційної панелі, знайдіть кнопку **new repo**.
|
|
|
|
|
|
1. Дайте своєму репозиторію (папці) назву.
|
|
|
1. Виберіть **create repository**.
|
|
|
|
|
|
1. **Перейдіть до робочої папки**. У терміналі перейдіть до папки (також відомої як директорія), яку ви хочете почати відстежувати. Введіть:
|
|
|
|
|
|
```bash
|
|
|
cd [name of your folder]
|
|
|
```
|
|
|
|
|
|
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)
|
|
|
|
|
|
modified: file.txt
|
|
|
modified: file2.txt
|
|
|
```
|
|
|
|
|
|
Зазвичай команда `git status` повідомляє вам, які файли готові до _збереження_ у репозиторії або мають зміни, які ви, можливо, захочете зберегти.
|
|
|
|
|
|
1. **Додайте всі файли для відстеження**
|
|
|
Це також називається стадіюванням файлів/додаванням файлів до області підготовки.
|
|
|
|
|
|
```bash
|
|
|
git add .
|
|
|
```
|
|
|
|
|
|
Аргумент `git add` плюс `.` вказує, що всі ваші файли та зміни будуть відстежуватися.
|
|
|
|
|
|
1. **Додайте вибрані файли для відстеження**
|
|
|
|
|
|
```bash
|
|
|
git add [file or folder name]
|
|
|
```
|
|
|
|
|
|
Це дозволяє додати лише вибрані файли до області підготовки, якщо ви не хочете комітити всі файли одразу.
|
|
|
|
|
|
1. **Відмініть стадіювання всіх файлів**
|
|
|
|
|
|
```bash
|
|
|
git reset
|
|
|
```
|
|
|
|
|
|
Ця команда дозволяє відмінити стадіювання всіх файлів одразу.
|
|
|
|
|
|
1. **Відмініть стадіювання конкретного файлу**
|
|
|
|
|
|
```bash
|
|
|
git reset [file or folder name]
|
|
|
```
|
|
|
|
|
|
Ця команда дозволяє відмінити стадіювання лише конкретного файлу, який ви не хочете включати до наступного коміту.
|
|
|
|
|
|
1. **Збережіть свою роботу**. На цьому етапі ви додали файли до так званої _області підготовки_. Це місце, де Git відстежує ваші файли. Щоб зробити зміни постійними, вам потрібно _закомітити_ файли. Для цього створіть _коміт_ за допомогою команди `git commit`. Коміт представляє точку збереження в історії вашого репозиторію. Введіть наступне, щоб створити _коміт_:
|
|
|
|
|
|
```bash
|
|
|
git commit -m "first commit"
|
|
|
```
|
|
|
|
|
|
Це закомітить усі ваші файли, додавши повідомлення "first commit". У майбутніх повідомленнях про коміти вам слід бути більш описовими, щоб передати, які саме зміни ви зробили.
|
|
|
|
|
|
1. **Підключіть локальний Git-репозиторій до GitHub**. Git-репозиторій корисний на вашому комп'ютері, але в якийсь момент ви захочете створити резервну копію своїх файлів десь і запросити інших людей працювати з вами над вашим репозиторієм. Одне з чудових місць для цього — GitHub. Пам'ятайте, що ми вже створили репозиторій на GitHub, тому єдине, що нам потрібно зробити, це підключити наш локальний Git-репозиторій до GitHub. Команда `git remote add` зробить це. Введіть наступну команду:
|
|
|
|
|
|
> Зверніть увагу, перед введенням команди перейдіть на сторінку вашого репозиторію на GitHub, щоб знайти URL репозиторію. Ви використаєте його в команді нижче. Замініть ```https://github.com/username/repository_name.git``` на ваш URL GitHub.
|
|
|
|
|
|
```bash
|
|
|
git remote add origin https://github.com/username/repository_name.git
|
|
|
```
|
|
|
|
|
|
Це створює _віддалене підключення_, назване "origin", яке вказує на репозиторій GitHub, створений раніше.
|
|
|
|
|
|
1. **Відправте локальні файли на GitHub**. Досі ви створили _підключення_ між локальним репозиторієм і репозиторієм GitHub. Відправимо ці файли на GitHub за допомогою команди `git push`, ось так:
|
|
|
|
|
|
> Зверніть увагу, ваша назва гілки за замовчуванням може відрізнятися від ```main```.
|
|
|
|
|
|
```bash
|
|
|
git push -u origin main
|
|
|
```
|
|
|
|
|
|
Це відправляє ваші коміти у вашу гілку "main" на GitHub.
|
|
|
|
|
|
2. **Додайте більше змін**. Якщо ви хочете продовжити вносити зміни та відправляти їх на GitHub, вам потрібно буде використовувати наступні три команди:
|
|
|
|
|
|
```bash
|
|
|
git add .
|
|
|
git commit -m "type your commit message here"
|
|
|
git push
|
|
|
```
|
|
|
|
|
|
> Порада: Можливо, вам також захочеться створити файл `.gitignore`, щоб запобігти відстеженню файлів, які ви не хочете бачити на GitHub, наприклад, нотаток, які ви зберігаєте в тій самій папці, але які не мають місця в публічному репозиторії. Ви можете знайти шаблони для файлів `.gitignore` на сторінці [.gitignore templates](https://github.com/github/gitignore).
|
|
|
|
|
|
#### Повідомлення про коміти
|
|
|
|
|
|
Чудовий заголовок повідомлення про коміт завершує наступне речення:
|
|
|
Якщо застосувати, цей коміт <ваш заголовок тут>.
|
|
|
|
|
|
Для заголовка використовуйте наказовий, теперішній час: "змінити", а не "змінив" чи "зміни".
|
|
|
Як і в заголовку, у тілі (за бажанням) також використовуйте наказовий, теперішній час. Тіло має включати мотивацію для зміни та порівняння з попередньою поведінкою. Ви пояснюєте `чому`, а не `як`.
|
|
|
|
|
|
✅ Приділіть кілька хвилин, щоб переглянути GitHub. Чи можете ви знайти дійсно чудове повідомлення про коміт? А мінімальне? Яка інформація, на вашу думку, є найважливішою та найкориснішою для передачі в повідомленні про коміт?
|
|
|
|
|
|
### Завдання: Співпраця
|
|
|
|
|
|
Основна причина розміщення проєктів на GitHub — це можливість співпрацювати з іншими розробниками.
|
|
|
|
|
|
## Робота над проєктами разом з іншими
|
|
|
|
|
|
> Перегляньте відео
|
|
|
>
|
|
|
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
|
|
|
|
|
|
У вашому репозиторії перейдіть до `Insights > Community`, щоб побачити, як ваш проєкт відповідає рекомендованим стандартам спільноти.
|
|
|
|
|
|
Ось кілька речей, які можуть покращити ваш репозиторій на GitHub:
|
|
|
- **Опис**. Чи додали ви опис до свого проєкту?
|
|
|
- **README**. Чи додали ви README? GitHub надає рекомендації щодо написання [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon).
|
|
|
- **Керівництво для внесків**. Чи має ваш проєкт [керівництво для внесків](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon)?
|
|
|
- **Кодекс поведінки**. Чи додали ви [Кодекс поведінки](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)?
|
|
|
- **Ліцензія**. Можливо, найважливіше — [ліцензію](https://docs.github.com/articles/adding-a-license-to-a-repository/)?
|
|
|
|
|
|
Усі ці ресурси допоможуть новим учасникам швидше адаптуватися. Зазвичай це ті речі, на які нові учасники звертають увагу перед тим, як переглядати ваш код, щоб зрозуміти, чи є ваш проєкт правильним місцем для їхнього часу.
|
|
|
|
|
|
✅ README-файли, хоча їх підготовка займає час, часто ігноруються зайнятими підтримувачами. Чи можете ви знайти приклад особливо описового README? Примітка: існують [інструменти для створення хороших README](https://www.makeareadme.com/), які вам можуть сподобатися.
|
|
|
|
|
|
### Завдання: Об'єднайте код
|
|
|
|
|
|
Документація для внесків допомагає людям робити внески в проєкт. Вона пояснює, які типи внесків ви шукаєте і як працює процес. Учасники повинні пройти серію кроків, щоб мати змогу зробити внесок у ваш репозиторій на GitHub:
|
|
|
|
|
|
1. **Форк вашого репозиторію**. Ви, ймовірно, захочете, щоб люди _форкали_ ваш проєкт. Форкінг означає створення копії вашого репозиторію у їхньому профілі GitHub.
|
|
|
1. **Клонування**. Після цього вони клонують проєкт на свій локальний комп'ютер.
|
|
|
1. **Створення гілки**. Ви захочете попросити їх створити _гілку_ для своєї роботи.
|
|
|
1. **Зосередження змін на одній області**. Попросіть учасників зосередити свої внески на одній речі за раз — таким чином шанси, що ви зможете _об'єднати_ їхню роботу, будуть вищими. Уявіть, що вони виправляють помилку, додають нову функцію та оновлюють кілька тестів — що, якщо ви хочете або можете реалізувати лише 2 із 3, або 1 із 3 змін?
|
|
|
|
|
|
✅ Уявіть ситуацію, коли гілки є особливо важливими для написання та впровадження якісного коду. Які випадки використання ви можете придумати?
|
|
|
|
|
|
> Примітка: будьте зміною, яку хочете бачити у світі, і створюйте гілки для своєї роботи також. Усі коміти, які ви робите, будуть зроблені у гілці, до якої ви зараз "перемкнуті". Використовуйте `git status`, щоб побачити, у якій гілці ви перебуваєте.
|
|
|
|
|
|
Розглянемо робочий процес учасника. Припустимо, учасник вже _форкнув_ і _клонував_ репозиторій, тому у нього є готовий Git-репозиторій на локальному комп'ютері:
|
|
|
|
|
|
1. **Створіть гілку**. Використовуйте команду `git branch`, щоб створити гілку, яка міститиме зміни, які вони планують внести:
|
|
|
|
|
|
```bash
|
|
|
git branch [branch-name]
|
|
|
```
|
|
|
|
|
|
1. **Перемкніться на робочу гілку**. Перемкніться на вказану гілку та оновіть робочу директорію за допомогою `git switch`:
|
|
|
|
|
|
```bash
|
|
|
git switch [branch-name]
|
|
|
```
|
|
|
|
|
|
1. **Виконайте роботу**. На цьому етапі ви хочете додати свої зміни. Не забудьте повідомити про це Git за допомогою наступних команд:
|
|
|
|
|
|
```bash
|
|
|
git add .
|
|
|
git commit -m "my changes"
|
|
|
```
|
|
|
|
|
|
Переконайтеся, що ви дали своєму коміту гарну назву, для вашого ж блага, а також для підтримувача репозиторію, якому ви допомагаєте.
|
|
|
|
|
|
1. **Об'єднайте свою роботу з гілкою `main`**. У якийсь момент ви закінчите роботу і захочете об'єднати її з гілкою `main`. Гілка `main` могла змінитися за цей час, тому переконайтеся, що ви спочатку оновили її до останньої версії за допомогою наступних команд:
|
|
|
|
|
|
```bash
|
|
|
git switch main
|
|
|
git pull
|
|
|
```
|
|
|
|
|
|
На цьому етапі ви хочете переконатися, що будь-які _конфлікти_, ситуації, коли Git не може легко _об'єднати_ зміни, виникають у вашій робочій гілці. Тому виконайте наступні команди:
|
|
|
|
|
|
```bash
|
|
|
git switch [branch_name]
|
|
|
git merge main
|
|
|
```
|
|
|
|
|
|
Це принесе всі зміни з `main` у вашу гілку, і, сподіваємося, ви зможете продовжити. Якщо ні, VS Code покаже вам, де Git _заплутався_, і ви просто зміните відповідні файли, щоб вказати, який вміст є найбільш точним.
|
|
|
|
|
|
1. **Відправте свою роботу на GitHub**. Відправка вашої роботи на GitHub означає дві речі: відправку вашої гілки у ваш форкований репозиторій і відкриття PR (Pull Request).
|
|
|
|
|
|
```bash
|
|
|
git push --set-upstream origin [branch-name]
|
|
|
```
|
|
|
|
|
|
Наведена вище команда створює гілку у вашому форкованому репозиторії.
|
|
|
|
|
|
1. **Відкрийте PR**. Далі ви хочете відкрити PR. Для цього перейдіть до форкованого репозиторію на GitHub. Ви побачите індикацію на GitHub, де вас запитають, чи хочете ви створити новий PR, натисніть на це, і вас перенаправлять на інтерфейс, де ви зможете змінити заголовок повідомлення про коміт, дати йому більш відповідний опис. Тепер підтримувач репозиторію, який ви форкнули, побачить цей PR і, _сподіваємося_, оцінить і _об'єднає_ ваш PR. Ви тепер учасник, ура :)
|
|
|
|
|
|
1. **Очистіть**. Вважається гарною практикою _очищати_ після успішного об'єднання PR. Ви хочете очистити як вашу локальну гілку, так і гілку, яку ви відправили на GitHub. Спочатку видаліть її локально за допомогою наступної команди:
|
|
|
|
|
|
```bash
|
|
|
git branch -d [branch-name]
|
|
|
```
|
|
|
Перейдіть на сторінку GitHub для форкнутого репозиторію та видаліть віддалену гілку, яку ви щойно запушили.
|
|
|
|
|
|
`Pull request` здається дивним терміном, адже насправді ви хочете запушити свої зміни до проєкту. Але мейнтейнер (власник проєкту) або основна команда повинні розглянути ваші зміни перед тим, як об'єднати їх із "головною" гілкою проєкту, тому ви фактично запитуєте рішення про зміну у мейнтейнера.
|
|
|
|
|
|
Pull request — це місце для порівняння та обговорення відмінностей, внесених у гілку, з рецензіями, коментарями, інтегрованими тестами тощо. Хороший pull request дотримується приблизно тих самих правил, що й повідомлення про коміт. Ви можете додати посилання на проблему в трекері проблем, якщо ваша робота, наприклад, виправляє проблему. Це робиться за допомогою символу `#`, за яким слідує номер вашої проблеми. Наприклад, `#97`.
|
|
|
|
|
|
🤞Сподіваємося, що всі перевірки пройдуть успішно, і власник(и) проєкту об'єднають ваші зміни в проєкт🤞
|
|
|
|
|
|
Оновіть вашу поточну локальну робочу гілку всіма новими комітами з відповідної віддаленої гілки на GitHub:
|
|
|
|
|
|
`git pull`
|
|
|
|
|
|
## Як зробити внесок у проєкт з відкритим кодом
|
|
|
|
|
|
Спочатку знайдіть репозиторій (або **repo**) на 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 і спробуйте кілька речей, наприклад, змінити налаштування, додати інформацію до репозиторію та створити проєкт (наприклад, дошку Kanban). Є багато цікавого, що можна зробити!
|
|
|
|
|
|
---
|
|
|
|
|
|
## 🚀 Виклик
|
|
|
|
|
|
Попрацюйте разом із другом над кодом один одного. Створіть проєкт спільно, форкніть код, створіть гілки та об'єднайте зміни.
|
|
|
|
|
|
## Післялекційний тест
|
|
|
[Післялекційний тест](https://ff-quizzes.netlify.app/web/quiz/4)
|
|
|
|
|
|
## Огляд і самостійне навчання
|
|
|
|
|
|
Дізнайтеся більше про [внесок у програмне забезпечення з відкритим кодом](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
|
|
|
|
|
|
[Шпаргалка по Git](https://training.github.com/downloads/github-git-cheat-sheet/).
|
|
|
|
|
|
Практикуйтеся, практикуйтеся, практикуйтеся. GitHub пропонує чудові навчальні шляхи через [skills.github.com](https://skills.github.com):
|
|
|
|
|
|
- [Перший тиждень на GitHub](https://skills.github.com/#first-week-on-github)
|
|
|
|
|
|
Там ви також знайдете більш просунуті курси.
|
|
|
|
|
|
## Завдання
|
|
|
|
|
|
Пройдіть [курс "Перший тиждень на GitHub"](https://skills.github.com/#first-week-on-github)
|
|
|
|
|
|
---
|
|
|
|
|
|
**Відмова від відповідальності**:
|
|
|
Цей документ був перекладений за допомогою сервісу автоматичного перекладу [Co-op Translator](https://github.com/Azure/co-op-translator). Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критичної інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникають внаслідок використання цього перекладу. |
