Репозиторијум у 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-а са интеграцијом Jire и 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 граф гранања, што је посебно корисно у репозиторијумима са активним радом у више грана. За мобилне пројекте са честим издањима, визуелни граф помаже да се брзо процени структура развоја.