Репозиторій у Git: що це, які типи бувають і як працюють

Що таке репозиторій у Git

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

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

Git використовує модель розподіленого репозиторію: кожен учасник проекту має повну копію історії на своєму комп’ютері. Це означає, що більшість операцій — коміт, перегляд історії, створення гілок — виконуються локально без звернення до сервера.

За даними документації Git, розподілена архітектура робить систему стійкою до збоїв: якщо сервер вийде з ладу, будь-який локальний репозиторій може стати джерелом для відновлення повної історії проекту.

Локальний і віддалений репозиторій

Локальний репозиторій — це копія проекту на комп’ютері розробника. Він містить усю історію комітів, гілок і тегів і дозволяє виконувати операції commit, branch, merge і rebase без підключення до мережі.

Віддалений репозиторій — розміщується на сервері і служить точкою синхронізації для всіх учасників команди. Розробники надсилають свої зміни командою git push і забирають чужі командою git pull.

Зв’язок між локальним і віддаленим репозиторієм налаштовується через remote origin — URL сервера, який зберігається в конфігурації Git. Один локальний репозиторій може бути пов’язаний з кількома віддаленими, що корисно при роботі з форками.

Основна перевага такої моделі — розробник може працювати над кодом в офлайн-режимі, а синхронізувати зміни тільки при готовності надіслати результат.

Відмінності між локальним і віддаленим репозиторієм

Як Git зберігає дані в репозиторії

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

Кожен об’єкт у репозиторії ідентифікується унікальним SHA-1 хешем довжиною 40 символів. Якщо вміст файлу не змінився між комітами, Git не створює новий об’єкт, а перевикористовує існуючий — це економить місце.

Git використовує чотири типи об’єктів: blob (вміст файлу), tree (структура директорії), commit (знімок з метаданими) і tag (іменоване посилання на коміт). Всі об’єкти зберігаються в папці .git/objects.

За даними Git Internals, об’єктна модель Git забезпечує цілісність даних: будь-яка зміна вмісту файлу призводить до нового хешу, що робить неможливою непомітну зміну історії.

Структура папки .git

Папка .git — це серце репозиторію. Без неї Git не може відстежувати зміни, а звичайна директорія залишається просто набором файлів. Розуміння структури цієї папки допомагає діагностувати проблеми з репозиторієм.

• objects/ — всі об’єкти репозиторію: blobs, trees, commits, tags. Зберігаються у стисненому вигляді.
• refs/ — посилання на коміти: heads (гілки), tags (мітки), remotes (віддалені гілки).
• HEAD — файл, який вказує на поточну активну гілку або коміт.
• config — налаштування репозиторію: remote URL, ім’я користувача, email та інші параметри.
• index — staging area (індекс), де Git зберігає інформацію про підготовлені до коміту файли.
• logs/ — журнали оновлення посилань (reflog), які зберігають історію переміщення HEAD і гілок.

Файл HEAD заслуговує особливої уваги. У нормальному стані він містить символічне посилання на гілку, наприклад ref: refs/heads/main. При стані detached HEAD він вказує безпосередньо на коміт — це означає, що нові коміти не будуть прив’язані до жодної гілки.

Основні операції з репозиторієм

Робота з Git-репозиторієм включає набір базових операцій, які розробник виконує щодня. Кожна операція змінює стан репозиторію, додаючи нові об’єкти або переміщуючи посилання.

• git init — створює новий порожній репозиторій у поточній директорії. Git створює папку .git з початковою структурою.
• git clone — копіює існуючий віддалений репозиторій на локальну машину разом з усією історією комітів.
• git add — додає зміни файлів у staging area (індекс), готуючи їх до коміту.
• git commit — створює знімок проекту на основі даних з індексу та зберігає його як новий об’єкт commit.
• git push — надсилає нові коміти з локального репозиторію у віддалений, оновлюючи гілки на сервері.
• git pull — забирає нові коміти з віддаленого репозиторію та зливає їх з поточною локальною гілкою.

Операції push і pull — єдині, які потребують підключення до віддаленого сервера. Всі інші операції виконуються повністю локально, що забезпечує високу швидкість роботи навіть при великому обсязі історії.

Життєвий цикл файлу в репозиторії

Кожен файл у репозиторії проходить через чотири стани: untracked (не відстежується), modified (змінений), staged (підготовлений) і committed (закомічений). Git відстежує тільки файли, які були явно додані через git add або вже знаходяться в історії комітів.

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

Популярні платформи для зберігання репозиторіїв

Віддалені репозиторії зазвичай розміщуються на спеціалізованих платформах, які надають веб-інтерфейс, систему управління доступом та додаткові інструменти для спільної розробки.

• GitHub — найбільша платформа з більш ніж 100 мільйонами репозиторіїв. Надає Actions, Pull Requests, Issues і Wiki. Безкоштовно для публічних проектів.
• GitLab — платформа з інтегрованим CI/CD, Container Registry та вбудованим DevOps-пайплайном. Доступна як SaaS і self-hosted версія.
• Bitbucket — рішення від Atlassian з інтеграцією Jira і Trello. Популярне в корпоративному середовищі завдяки гнучким налаштуванням доступу.

Вибір платформи залежить від розміру команди, вимог до приватності та необхідних інтеграцій. Для мобільної розробки часто обирають GitHub через широку підтримку спільноти та інтеграцію з інструментами CI/CD для iOS і Android.

Приклади команд для роботи з репозиторієм

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

# Клонування віддаленого репозиторію
git clone https://github.com/user/mobile-app.git

# Перехід у директорію проекту
cd mobile-app

# Створення нової гілки feature і переключення на неї
git checkout -b feature/auth

# Перевірка статусу змінених файлів
git status

# Додавання всіх змін до staging area
git add .

# Створення коміту з описом
git commit -m "Add authentication module"

# Надсилання змін до віддаленого репозиторію
git push origin feature/auth

Команда git status — одна з найкорисніших у повсякденній роботі. Вона показує, які файли змінено, які підготовлено до коміту, а які взагалі не відстежуються Git.

Перегляд історії комітів

Для аналізу історії репозиторію використовується команда git log з різними прапорцями форматування. Вона відображає хронологію комітів, їхніх авторів, дати та SHA-1 ідентифікатори.

# Перегляд історії з візуалізацією графа гілок
git log --oneline --graph --all

# Перегляд змін у конкретному коміті
git show a1b2c3d

# Порівняння поточного стану з останнім комітом
git diff HEAD

# Перегляд історії конкретного файлу
git log --follow src/MainActivity.kt

Прапорець --graph відображає ASCII-граф розгалужень, що особливо корисно в репозиторіях з активною роботою в кількох гілках. Для мобільних проектів з частими релізами візуальний граф допомагає швидко оцінити структуру розробки.