Repository в 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/ — всички обекти на хранилището: blob, tree, commit, tag. Съхраняват се в компресиран вид.
• refs/ — референции към комити: heads (клонове), tags (етикети), remotes (отдалечени клонове).
• HEAD — файл, който сочи към текущия активен клон или комит.
• config — настройки на хранилището: отдалечен URL, потребителско име, имейл и други параметри.
• 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 — създава моментна снимка на проекта въз основа на данни от индекса и я запазва като нов обект комит.
• 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 граф на разклоненията, което е особено полезно в хранилища с активна работа в множество клонове. За мобилни проекти с чести издания, визуалният граф помага за бърза оценка на структурата на разработката.