У цій статті ви розберетеся, що таке Git і навіщо він потрібен, створите свій перший репозиторій на GitHub і налаштуєте робоче середовище. Роботу з Git ми навмисно розбираємо через графічний інтерфейс IDE - так наочніше і спокійніше на старті, не треба тримати в голові десятки команд.
Приклади і знімки інтерфейсу стосуються IDE JetBrains; назви й розташування дій у вашій версії можуть відрізнятися. Для вправ використовуйте окремий навчальний репозиторій. У робочому проєкті дотримуйтеся його правил щодо гілок, фіксації та надсилання змін.
Але такий підхід має і другий сенс. Claude Code під капотом робить ті самі операції з Git - тільки командами в консолі. Коли він пропонує зробити коміт, створити гілку або надіслати зміни, за цим стоять звичайні команди Git. Розуміючи, що відбувається за кнопками IDE, ви розумітимете і те, що пропонує Claude Code, і зможете свідомо це перевірити та схвалити.
Навіщо потрібен контроль версій
Коли ви починаєте працювати над проєктом, здається, що головне - щоб код працював. Але досить швидко з'ясовується, що код змінюється частіше, ніж працює стабільно. Ви виправляєте баг, додаєте фічу, передумуєте, відкочуєте, знову додаєте.
Уявіть, що ви працюєте над своїм проєктом. Усе йде добре, аж поки не настає час експериментів. Ви вирішуєте щось змінити, але боїтеся зламати робочу версію. Що робити? Звісно, копіювати проєкт. І ось на диску з'являються такі шедеври:
MyProject/
├── main.py
├── main_backup.py
├── main_final.py
├── main_final2.py
├── main_really_final.py
├── main_really1_really_final2.pyЗнайомо? А тепер уявіть, що до проєкту долучився ще й друг. Він теж любить копіювати файли - тільки по-своєму. Як зрозуміти, де найсвіжіша і робоча версія? Як дізнатися, хто що змінив? Як усе повернути, якщо експеримент не вдався?
Без збереженої історії все зводиться до ручного розбору копій, і виходить приблизно так:
- робочий код легко загубити або переплутати;
- немає єдиного способу знайти і відновити збережену версію;
- важко працювати вдвох чи втрьох;
- хаос і страх перед експериментами.
Саме ці проблеми розв'язують системи контролю версій - такі як Git.
Відео - основи Git у терміналі
Це відео дає міцну базу для роботи з Git через термінал - воно допомагає зрозуміти саму механіку процесів, прихованих за кнопками IDE.
У відео приклади на Java, але основні операції Git однакові для різних мов.
Що таке Git - основні поняття
Git - це система керування версіями, якою відстежують зміни в коді під час розробки. Вона дає змогу зберігати різні версії файлів і координувати роботу кількох людей над спільним проєктом.
Репозиторій (або "репо") - це місце, де зберігається вся історія проєкту: усі зміни й версії файлів.
Коміт (commit) - збережений знімок відстежуваного вмісту проєкту з повідомленням, відомостями про автора і зв'язками з батьківськими комітами. Незакомічені та ігноровані файли до цього знімка не потрапляють. Історія дає змогу знайти й відновити раніше збережену версію.
Кожен коміт - це знімок проєкту, що йде слідом за попереднім. з таких знімків і складається послідовна історія змін.
Гілка (branch) - ім'я, яке вказує на поточний коміт однієї лінії розробки. У прикладах основна гілка називається main; у вашому репозиторії ім'я може бути іншим. Воно залежить від налаштувань і способу створення репозиторію.
Від основної гілки main відгалужується гілка develop для паралельної розробки. Коли роботу завершено, зміни з develop зливаються назад у main.
Основні команди Git - що відбувається під капотом
Нижче - список основних команд для роботи з Git через термінал. Ми працюватимемо через графічний інтерфейс IDE, але корисно розуміти, які команди лежать в основі всіх операцій: саме їх виконує Git за кожною кнопкою - і саме їх виконує Claude Code, коли працює з вашим репозиторієм. Дивіться на них як на те, що відбувається під капотом.
| Команда | Що робить |
|---|---|
git init | ініціалізує новий Git-репозиторій у поточній теці |
git clone | копіює репозиторій за URL у нову теку |
git status | показує, які файли змінено, які підготовлено і які Git поки не відстежує |
git add | додає файли в індекс (staging) для наступного коміту |
git commit | фіксує підготовлені зміни як новий знімок історії |
git push | надсилає коміти з локального репозиторію у віддалений |
git pull | отримує зміни й об'єднує їх з поточною гілкою відповідно до налаштувань |
git fetch | завантажує зміни із сервера, але поки не вливає їх у вашу гілку |
git branch | показує, створює або видаляє гілки |
git checkout / git switch | switch перемикає гілки; checkout також уміє відкривати окремий коміт і відновлювати файли |
git merge | зливає зміни вказаної гілки в поточну |
git log | показує історію комітів |
git diff | без прапорців порівнює робочі файли з індексом; підготовлені зміни дивляться окремо |
git restore | відновлює вибрані файли; якщо джерело не вказано, робочі файли беруться з індексу, а не обов'язково з останнього коміту |
git reset | змінює індекс або положення поточної гілки; наслідки залежать від форми команди і режиму |
git stash | тимчасово ховає незавершені зміни, щоб повернутися до них пізніше |
git remote -v | показує, до яких віддалених репозиторіїв підключено проєкт |
git config | налаштування Git, наприклад ім'я та email автора комітів |
Заучувати весь список не треба, так ніхто й не робить. На старті досить розуміти, що дії IDE та агента спираються на операції Git; одна дія інтерфейсу може виконати кілька команд. Наприклад, фіксація через Commit використовує git commit, кнопка Push - це git push.
- Робочі файли
- git add → індекс
- git commit → історія
- git push → сервер
На схемі показано надсилання: ви готуєте вміст через add, фіксуєте його локально через commit і надсилаєте коміти через push. Зворотний напрямок, pull, отримує віддалені коміти й об'єднує їх з поточною гілкою за налаштуваннями.
Це та сама механіка, яку Claude Code виконує за вас. Коли він каже, що зробить коміт і надішле зміни, за цим стоять git add, git commit і git push. Ви бачите результат у тому самому вікні IDE і можете його перевірити.
Чотири стани коду
Коли ви користуєтеся контролем версій, ваш код логічно проходить через чотири стани:
1. Робоча директорія (Working Directory). Актуальні файли проєкту на вашому комп'ютері, які ви саме зараз редагуєте.
2. Область індексації (Staging Area). Підготовлений вміст наступного коміту. У JetBrains можна працювати через списки змін або ввімкнути окремий staging-режим. Галочки у звичайному вікні Commit вибирають вміст для коміту, але не означають, що він уже в індексі Git.
3. Локальний репозиторій (Local Repository). Ваша особиста копія історії коду на комп'ютері. Коміти, гілки, злиття - усе це працює тут навіть без інтернету.
4. Віддалений репозиторій (Remote Repository). Центральне сховище коду на сервісах на кшталт GitHub, GitLab чи Bitbucket. Воно надійно зберігає код і слугує основою для командної роботи.
Коли Claude Code просить додати новий файл до відстеження, він переводить файл із робочої директорії в staging - це команда git add. Так готується вміст файлу на момент додавання; наступні правки треба підготувати знову. Якщо файл додавати не потрібно (наприклад, це тимчасове сміття), можете не погоджуватися.
Git і GitHub - у чому різниця
Тут важливо не плутати два поняття. Git - це програма, яка працює на вашому комп'ютері локально (навіть без інтернету) і стежить за версіями файлів. GitHub - це хмарний сервіс (сайт), де зберігаються віддалені копії ваших Git-репозиторіїв.
GitHub дає змогу створювати репозиторії, відстежувати зміни і працювати над кодом разом з іншими. Для сучасного розробника профіль на GitHub - важлива частина портфоліо, яку можна показати роботодавцю.
Створення першого репозиторію на GitHub
Крок 1. Зайдіть на https://github.com і зареєструйтеся.
Крок 2. Натисніть кнопку New repository, щоб створити новий репозиторій.
Крок 3. Задайте параметри репозиторію:
- ім'я репозиторію - придумайте змістовне ім'я;
- Public або Private - вибирайте видимість свідомо. Public доступний усім; Private обмежує доступ. Для особистої вправи, яку ви не збираєтеся публікувати, можна вибрати Private.
- Add a README file - для нового порожнього проєкту зручно додати README. Якщо збираєтеся надсилати вже наявну локальну історію, створіть порожній віддалений репозиторій без README, щоб не отримати дві незалежні початкові історії.
- Add .gitignore - виберіть шаблон для технології вашого проєкту. У випадному списку є готові шаблони для популярних мов. Це важливо: збірка і менеджери пакетів створюють багато тимчасових файлів і кешу, які не повинні засмічувати репозиторій, а шаблон допоможе Git їх ігнорувати;
- Choose a license - можна пропустити;
- натисніть
Create repository.
Крок 4. От і все: ваш перший віддалений репозиторій створено.
Встановлення і налаштування Git
Далі показано інтерфейс IntelliJ IDEA. В інших IDE JetBrains є схожі операції, але розташування кнопок і назви пунктів залежать від версії. Орієнтуйтеся на назву дії; її можна знайти через пошук дій IDE.
Щоб працювати з Git, його спочатку треба встановити. Якщо ви користуєтеся IDE від JetBrains, вона, найімовірніше, сама запропонує встановити Git, якщо не знайде його в системі - найпростіше погодитися.
Закрийте поточний проєкт через File | Close Project. На стартовому екрані (Welcome Screen) натисніть Clone Repository (у деяких версіях кнопка називається Get from VCS).
Хочете встановити Git вручну - завантажте його з офіційного сайту: https://git-scm.com/downloads.
Важливий нюанс
Під час першого коміту Git потрібні ім'я автора та email. Це підпис коміту, а не вхід в акаунт. Для зв'язку з GitHub використовуйте підтверджену адресу з налаштувань акаунта або адресу noreply, яку видає GitHub, якщо не хочете публікувати особистий email.
GitHub пов'язує коміти з профілем за email. Сам збіг адреси не гарантує, що запис з'явиться в графіку активності. там є ще додаткові умови.
Що встановити, щоб Claude Code працював із Git і GitHub напряму
Для локальних комітів і гілок досить встановленого Git: вхід у GitHub не потрібен. Для операцій з віддаленим репозиторієм налаштуйте доступ до нього. GitHub CLI (gh) - додатковий інструмент для PR та інших функцій GitHub, а не обов'язкова частина Git.
1. Git. Потрібен для роботи з локальною історією. Встановіть його через IDE або з офіційного сайту Git.
2. GitHub CLI (gh) - офіційна консольна утиліта GitHub. Навіщо вона? Щоб Claude Code міг створювати pull request, читати issues і дивитися статуси перевірок безпосередньо з термінала, не перемикаючись у браузер. Спосіб встановлення залежить від вашої операційної системи.
Інструкції для вашої ОС є на офіційній сторінці GitHub CLI. Встановіть утиліту і перевірте, чи вона доступна, командою gh --version.
Якщо вибрали GitHub CLI, запустіть налаштування доступу і відповідайте на його запитання. Для GitHub.com можна вибрати HTTPS і вхід через браузер:
# вхід в акаунт GitHub з термінала
gh auth loginClaude Code може використовувати git для історії та gh для функцій GitHub. Встановлення gh і gh auth login потрібні, якщо ви обираєте такий спосіб роботи з GitHub. PR створюються і коміти надсилаються за вашим завданням, після перевірки того, що буде надіслано.
main vs master
У репозиторіях трапляються імена main і master. GitHub зазвичай пропонує main, а Git під час локальної ініціалізації враховує свою версію і налаштування init.defaultBranch. Перевіряйте справжнє ім'я гілки в проєкті.
Власне, обидва імені позначають звичайну гілку, нічого особливого. Команди з прикладів треба зіставляти зі справжніми іменами гілок вашого репозиторію.
Як це працює у зв'язці з Claude Code
Тепер, коли ви розумієте базові поняття Git, дії Claude Code читати простіше. Коротко, що він робить за вас із цією технологією і на що варто дивитися:
- виконує за вас
git add,git commit,git pushта інші команди - ті самі, що стоять за кнопками IDE; - пропонує додати файл до відстеження (
git add) - ви вирішуєте, чи потрібен цей файл в історії; - пропонує коміт із готовим повідомленням - ви читаєте, що він зафіксує, і погоджуєтеся або правите;
- через GitHub CLI вміє створювати й коментувати pull request (PR - пропозиція влити гілку в основну) і дивитися статуси перевірок.
Перш ніж погодитися, подивіться, які файли і зміни потраплять у коміт. Claude Code показує їх так само, як IDE, - у вигляді diff. Це ваша точка контролю: ви завжди розумієте, що саме піде в історію проєкту і на сервер.