Git для початківців: встановлення, основні команди й робота з GitHub

Git — система контролю версій: вона пам'ятає кожну збережену зміну у вашому коді, дозволяє повернутися до будь-якого моменту в минулому й працювати над кількома задачами паралельно, не заважаючи колегам. Сьогодні Git потрібен усім: розробникам, тестувальникам, DevOps-інженерам і навіть тим, хто пише документацію.

Цей посібник проведе вас від встановлення до першого git push на GitHub — на одному наскрізному прикладі, з поясненням, що відбувається на кожному кроці.

Як Git бачить ваш код

Головне, що варто зрозуміти на старті: у Git є чотири місця, між якими «подорожують» зміни.

1. Робоча папка — звичайні файли, які ви редагуєте.
2. Індекс (staging area) — «чернетка» наступного коміту. Сюди ви додаєте лише ті зміни, які хочете зберегти разом.
3. Локальний репозиторій — історія комітів у прихованій папці .git.
4. Віддалений репозиторій — копія на GitHub, GitLab чи власному сервері, спільна для команди.

Коміт — це знімок стану проєкту з описом, автором і датою. Коміти утворюють історію, по якій можна ходити вперед і назад.

Встановлення Git

Ubuntu / Debian:

sudo apt update
sudo apt install git

macOS: найпростіше — xcode-select --install (Git входить до Command Line Tools) або brew install git для свіжішої версії.

Windows: встановіть Git for Windows або через winget:

winget install --id Git.Git -e

Разом з Git на Windows ставиться Git Bash — термінал, де працюють ті самі команди, що й на Linux.

Перевірка:

git --version

Перше налаштування

Ці команди виконуються один раз на комп'ютері. Ім'я й пошта потрапляють у кожен коміт — вказуйте ті, що й на GitHub:

git config --global user.name "Ім'я Прізвище"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Корисні додаткові налаштування:

git config --global core.editor "code --wait"   # редактор для повідомлень комітів — VS Code
git config --global core.autocrlf input         # Linux і macOS; на Windows — true

Що таке autocrlf

Windows закінчує рядки символами CRLF, Linux і macOS — LF. Налаштування core.autocrlf стежить, щоб у репозиторії були однакові закінчення рядків, і через них у diff не з'являлися «змінені» файли, яких ви не чіпали.

Подивитися всі налаштування: git config --list --show-origin.

Перший репозиторій: від нуля до коміту

Створимо проєкт і пройдемо повний цикл.

mkdir notes-app && cd notes-app
git init

git init створює папку .git — тепер це репозиторій. Додайте файл і подивіться, що бачить Git:

echo "# Notes App" > README.md
git status

Git покаже README.md як untracked — файл є в робочій папці, але Git за ним ще не стежить. Додамо його в індекс і зробимо коміт:

git add README.md
git commit -m "Додати README"

Змініть файл ще раз і подивіться різницю:

echo "Простий застосунок для нотаток." >> README.md
git diff              # що змінено, але ще не додано в індекс
git add README.md
git diff --staged     # що потрапить у наступний коміт
git commit -m "Описати проєкт у README"

Історія комітів:

git log --oneline --graph

Кожен коміт має унікальний хеш (наприклад, a1b2c3d), за яким до нього можна повернутися.

Як писати повідомлення комітів

Пишіть, що і навіщо змінює коміт, у наказовому способі: «Додати перевірку email при реєстрації», «Виправити падіння на порожньому списку». Повідомлення «fix», «wip» чи «зміни» через місяць нічого не скажуть ні вам, ні колегам.

.gitignore: що не потрапляє в репозиторій

Деякі файли комітити не можна або не потрібно: залежності, результати збірки, локальні налаштування й особливо секрети. Створіть у корені проєкту файл .gitignore:

# Залежності та збірка
node_modules/
.venv/
dist/
__pycache__/

# Локальні налаштування й секрети
.env
*.log
.idea/
.vscode/
.DS_Store

Секрет у коміті — це назавжди

Якщо пароль чи API-ключ потрапив у коміт і був відправлений на GitHub, видалення файлу наступним комітом не допоможе: він лишається в історії. Ключ треба негайно відкликати й перевипустити, а вже потім чистити історію.

Гілки: паралельна робота без хаосу

Гілка — окрема лінія розробки. Основна гілка (main) має бути робочою, а кожна нова задача робиться у своїй гілці:

git switch -c feature/search     # створити гілку і перейти в неї
# ... правите код ...
git add .
git commit -m "Додати пошук по нотатках"

Повернутися в main і влити зміни:

git switch main
git merge feature/search
git branch -d feature/search     # гілка більше не потрібна

Список гілок — git branch, разом із віддаленими — git branch -a.

switch і checkout

У старих інструкціях замість git switch пишуть git checkout. Обидві команди працюють, але switch (для гілок) і restore (для файлів) зрозуміліші: checkout робить надто багато різних речей.

Конфлікти злиття

Конфлікт виникає, коли в двох гілках по-різному змінили той самий рядок. Git зупиниться й позначить проблемне місце у файлі:

<<<<<<< HEAD
Простий застосунок для нотаток.
=======
Застосунок для нотаток з пошуком.
>>>>>>> feature/search

Що робити:

1. Відкрийте файл і залиште правильний варіант (або поєднайте обидва). Приберіть рядки з <<<<<<<, ======= і >>>>>>>.
2. git add README.md — позначити конфлікт як вирішений.
3. git commit — завершити злиття.

Передумали зливати — git merge --abort поверне все як було. VS Code підсвічує конфлікти й дає кнопки «Accept Current / Incoming / Both» — це зручно на старті.

Робота з GitHub

Крок 1. SSH-ключ

Пароль від акаунта для git push на GitHub не підходить — потрібен SSH-ключ або токен. SSH зручніший: налаштували раз — і забули.

ssh-keygen -t ed25519 -C "you@example.com"
cat ~/.ssh/id_ed25519.pub

Скопіюйте вивід (це публічний ключ) і додайте його на GitHub: Settings → SSH and GPG keys → New SSH key. Перевірка:

ssh -T git@github.com

Відповідь Hi username! You've successfully authenticated означає, що все гаразд.

Файл без .pub — секретний

~/.ssh/id_ed25519 — приватний ключ. Нікому його не надсилайте й не комітьте. На GitHub завантажується лише id_ed25519.pub.

Крок 2. Відправити проєкт на GitHub

Створіть на GitHub порожній репозиторій (без README, щоб не було конфлікту історій) і підключіть його:

git remote add origin git@github.com:username/notes-app.git
git push -u origin main

Прапорець -u запам'ятовує зв'язок локальної main з origin/main, тож далі достатньо просто git push.

Крок 3. Отримати зміни колег

git pull           # завантажити й одразу влити в поточну гілку
git fetch          # лише завантажити, нічого не змінюючи

git fetch безпечний: він оновлює знання про віддалений репозиторій, але не чіпає ваші файли. Корисно спершу подивитися, що прийшло (git log main..origin/main), а потім уже зливати.

Склонувати чужий чи свій репозиторій на нову машину:

git clone git@github.com:username/notes-app.git

Як скасувати зміни

Найчастіші ситуації — і безпечні способи з них вийти.

Обережно з reset --hard і push --force

git reset --hard безповоротно викидає незакомічені зміни. git push --force переписує історію на сервері — і в колег, які вже стягнули старі коміти, почнуться проблеми. Для вже опублікованих комітів використовуйте git revert: він створює новий коміт, що скасовує старий, і нічого не переписує.

Навіть після невдалого reset коміти зазвичай можна врятувати через git reflog — журнал усіх переміщень HEAD. Детальніше про це — в рубриці Git and GitHub.

Типові помилки Git

fatal: not a git repository

Ви не в папці репозиторію. Перейдіть у неї (cd) або створіть репозиторій командою git init.

Author identity unknown / Please tell me who you are

Не задано ім'я й пошту. Виконайте git config --global user.name ... і user.email ... з розділу «Перше налаштування».

error: src refspec main does not match any

Git не знайшов гілку main. Або в репозиторії ще немає жодного коміту, або гілка називається інакше (часто master). Перевірте git branch і зробіть перший коміт.

! [rejected] main -> main (fetch first)

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:username/notes-app.git'

На сервері є коміти, яких немає у вас (наприклад, колега вже щось запушив або ви створили README на GitHub). Спершу заберіть їх — git pull, вирішіть конфлікти, якщо будуть, — і повторіть git push.

Permission denied (publickey)

GitHub не прийняв ваш SSH-ключ. Перевірте, що публічний ключ додано в акаунт, і запустіть ssh -T git@github.com. Якщо ключ має нестандартне ім'я, додайте його в агент: ssh-add ~/.ssh/my_key.

Support for password authentication was removed

Ви клонували репозиторій за HTTPS і вводите пароль від акаунта. GitHub давно приймає лише токени. Перейдіть на SSH:

git remote set-url origin git@github.com:username/notes-app.git

fatal: refusing to merge unrelated histories

У локальному й віддаленому репозиторіях немає спільного коміту — зазвичай тому, що на GitHub при створенні додали README. Якщо ви впевнені, що хочете поєднати історії: git pull origin main --allow-unrelated-histories.

Шпаргалка

Часті питання

Git і GitHub — це одне й те саме? Ні. Git — програма на вашому комп'ютері. GitHub — сервіс, де зберігають Git-репозиторії й працюють над ними разом: pull request'и, рев'ю коду, CI/CD. Альтернативи — GitLab, Bitbucket, Gitea.

merge чи rebase? Для початку — merge: він не переписує історію і прощає помилки. rebase робить історію лінійною й охайною, але переписує коміти — його варто опанувати, коли базові речі стануть звичними.

Як часто комітити? Часто й невеликими порціями: один коміт — одна логічна зміна. Маленькі коміти легко переглядати, а за потреби й скасовувати.

Чи можна користуватися Git без терміналу? Можна: вбудований Git у VS Code, GitHub Desktop, GitKraken. Але розуміння команд допоможе, коли щось піде не так — а графічні клієнти все одно виконують ті самі команди.

Що далі

Опануйте щоденний цикл «гілка → коміти → push → pull request», а далі переходьте до автоматизації: у рубриці Git and GitHub є статті про rebase і reflog, а в рубриці DevOps — про CI/CD з GitHub Actions.