Git — що це, принципи роботи та команди

Що таке Git?

Git — це розподілена система контролю версій (VCS), яка відстежує зміни у файлах і дозволяє кільком розробникам працювати над одним проєктом одночасно. На відміну від централізованих систем, у Git кожен розробник має повну копію репозиторію, включаючи всю історію змін, що робить систему стійкою до втрати даних і не потребує постійного підключення до центрального сервера.

Історія Git почалася 2005 року, коли Лінус Торвальдс створив нову VCS після того, як компанія BitKeeper відкликала безкоштовну ліцензію на свою систему для розробників ядра Linux. Цілями були: швидкість, простота архітектури, підтримка нелінійної розробки через відгалуження та повна розподіленість. За 3 місяці Торвальдс написав ядро Git, а вже через рік проєкт перейшов на самообслуговування під управлінням Дзюн Хамано.

За даними опитування Stack Overflow (2024), Git використовують 93,9% професійних розробників, що робить його домінуючою системою контролю версій в індустрії. Найближчий конкурент — Subversion (SVN) — використовується лише в 5,2% проєктів, переважно у великих корпоративних середовищах з централізованими процесами.

Як працює Git: репозиторій і коміти

Репозиторій Git — це директорія, в якій Git відстежує зміни всіх файлів. Усередині директорії знаходиться прихована папка .git, де зберігаються всі об’єкти системи: коміти, дерева, блоки та посилання. Коли розробник створює коміт, Git не копіює файли цілком — він створює знімок стану та зберігає посилання на нього.

Кожен коміт містить: унікальний SHA-1 хеш (40 символів), посилання на попередній коміт (parent), автора, дату, повідомлення коміту та посилання на дерево, яке описує стан файлів на момент коміту. Ланцюжок комітів утворює спрямований ациклічний граф, де кожен коміт вказує на одного або кількох батьків.

# Ініціалізація репозиторію
git init my-project
cd my-project

# Створення коміту
echo "Привіт, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Перегляд історії
git log --oneline --graph --all

Git використовує три основні області: working directory (файли на диску), staging area (індекс, куди потрапляють підготовлені файли) та repository (історія комітів). Команда git add переміщує зміни з робочої директорії до staging, а git commit фіксує вміст staging у репозиторії. Це розділення дозволяє розробнику зібрати осмислений коміт з набору змін, не фіксуючи кожну правку окремо.

Основні команди Git

Основні команди Git покривають 90% щоденних операцій розробника. Команда git clone створює локальну копію віддаленого репозиторію, git pull забирає зміни з сервера та зливає їх з поточною гілкою, а git push надсилає локальні коміти на сервер. Ці три команди формують основний цикл роботи з Git.

Для перегляду стану використовується git status — вона показує, які файли змінено, які додано до staging, а які не відстежуються. git diff відображає конкретні зміни у файлах до додавання в staging. Нижче наведено таблицю з найбільш часто використовуваними командами:

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

Гілки в Git: main, feature і release

Гілки в Git — це легкі переміщувані покажчики на певний коміт. Створення нової гілки не копіює файли, а лише створює новий покажчик, що робить відгалуження практично миттєвим. Гілка main (раніше master) — основна гілка проєкту, яка містить стабільний, готовий до релізу код.

Стандартна практика — використовувати Git Flow або GitHub Flow. У Git Flow використовуються гілки: main (релізний код), develop (інтеграційна гілка), feature/* (нові функції), release/* (підготовка релізів) і hotfix/* (термінові виправлення). GitHub Flow простіший: лише main і feature-гілки, а всі зміни доставляються через Pull Request.

# Створення та перемикання гілки
git branch feature-auth
git checkout feature-auth
# або однією командою:
git checkout -b feature-auth

# Список гілок
git branch --list
git branch -a  # все ветки, включая удалённые

# Видалення гілки
git branch -d feature-auth

Важлива властивість відгалуження Git — можливість cherry-pick: перенесення окремого коміту з однієї гілки в іншу за допомогою команди git cherry-pick <hash>. Це корисно, коли потрібно перенести виправлення багу з feature-гілки в release без злиття всієї гілки. Також Git підтримує перебазування (rebase) та інтерактивне перебазування (git rebase -i) для склеювання, перевпорядкування та редагування комітів.

Merge і Rebase

Merge (злиття) створює спеціальний merge-коміт, який має двох батьків. Цей коміт фіксує факт об’єднання двох гілок і зберігає повну історію — видно, де й коли відбулося злиття. Merge зберігає історію в тому вигляді, в якому вона була створена, що спрощує аудит, але робить граф комітів більш складним.

Rebase (перебазування) замість створення merge-коміту переносить коміти поточної гілки на верхівку цільової гілки. Історія стає лінійною — створюється враження, що розробка велася послідовно. Однак rebase переписує історію, змінюючи SHA-1 хеші комітів, що робить його небезпечним для спільних гілок, до яких мають доступ інші розробники.

Рекомендація щодо вибору: використовуйте merge для публічних гілок, де історію бачать інші розробники (feature → develop), і rebase для локальної роботи, коли потрібно застосувати свіжі зміни з main у свою feature-гілку перед створенням Pull Request. Правило просте: якщо коміт уже відправлено на сервер — не перебазовуйте його.

Вирішення конфліктів

Конфлікт злиття виникає, коли Git не може автоматично об’єднати зміни в одному файлі. Git позначає конфліктуючі ділянки у файлі спеціальними маркерами: <<<<<<< (наші зміни), ======= (розділювач), >>>>>>> (їхні зміни). Розробник вручну редагує файл, вибираючи потрібний варіант або комбінуючи обидва, і завершує злиття комітом.

Робота з віддаленими репозиторіями

Віддалений репозиторій (remote) — це копія Git-репозиторію, розташована на сервері. GitHub, GitLab і Bitbucket — найпопулярніші платформи для хостингу віддалених репозиторіїв. Вони надають вебінтерфейс для перегляду коду, управління доступом, код-рев’ю та інтеграції з CI/CD-системами.

У Git можна налаштувати кілька віддалених репозиторіїв для одного проєкту. За замовчуванням основний remote називається origin. Команда git remote add додає новий remote, git fetch забирає зміни без злиття, а git pull — це скорочення для git fetch + git merge. Для роботи з кодом через Pull Request розробник створює форк репозиторію, клонує його, працює в feature-гілці та надсилає запит на злиття в оригінальний репозиторій.

# Додавання віддаленого репозиторію
git remote add origin https://github.com/user/repo.git

# Перегляд віддалених репозиторіїв
git remote -v

# Відправлення гілки на сервер
git push -u origin feature-auth

# Забрати зміни з віддаленої гілки
git pull origin main

Віддалені репозиторії підтримують тегування для маркування релізних версій. Теги бувають легкими (просто покажчик на коміт) і анотованими (містять метадані: автор, дата, повідомлення). Анотовані теги рекомендується використовувати для релізних версій, оскільки вони передають повну інформацію про версію та можуть бути підписані GPG-ключем для верифікації авторства.

Git Worktree для паралельної роботи

Git Worktree дозволяє одночасно працювати з кількома гілками в різних директоріях без перемикання між ними. Команда git worktree add ../feature-auth feature-auth створює нову робочу директорію feature-auth, де можна писати код, не перемикаючи гілку в основній директорії. Worktree корисний для швидких виправлень у release-гілці, коли основна директорія зайнята довгою розробкою.

Git Submodules для залежностей

Git Submodules — механізм включення одного Git-репозиторію в інший. Submodule зберігає посилання на фіксований коміт зовнішнього репозиторію, що гарантує відтворюваність збірки. Команда git submodule add https://github.com/example/lib.git додає зовнішню бібліотеку як підмодуль. При клонуванні проєкту з підмодулями потрібно виконати git submodule update --init --recursive для завантаження всіх залежностей.