Repository i Git: vad det är, vilka typer som finns och hur de fungerar

Vad är ett repository i Git

Git-repository — är en datastruktur där versionshanteringssystemet lagrar metadata och objekt som beskriver ändringshistoriken för projektets filer. När en utvecklare initierar ett repository med kommandot git init, skapar Git en dold mapp .git i projektets rot.

Inuti denna mapp finns alla objekt, referenser och konfigurationsfiler som krävs för systemets funktion. Repositoryt är inte bundet till en specifik plats — utvecklaren kan skapa det lokalt och sedan ansluta det till en fjärrserver.

Git använder modellen för distribuerat repository: varje deltagare i projektet har en fullständig kopia av historiken på sin egen dator. Detta innebär att de flesta operationerna — commit, historikvisning, skapande av grenar — utförs lokalt utan att kontakta servern.

Enligt Git-dokumentationen gör den distribuerade arkitekturen systemet motståndskraftigt mot fel: om servern kraschar kan vilket lokalt repository som helst bli en källa för att återställa projektets fullständiga historik.

Lokalt och fjärranslutet repository

Lokalt repository — är en kopia av projektet på utvecklarens dator. Det innehåller hela historiken över commits, grenar och taggar och gör det möjligt att utföra commit-, branch-, merge- och rebase-operationer utan nätverksanslutning.

Fjärranslutet repository är värd på en server och fungerar som en synkroniseringspunkt för alla teammedlemmar. Utvecklare skickar sina ändringar med kommandot git push och hämtar andras ändringar med kommandot git pull.

Anslutningen mellan lokalt och fjärranslutet repository konfigureras via remote origin — serverns URL som lagras i Git-konfigurationen. Ett lokalt repository kan anslutas till flera fjärranslutna repositories, vilket är användbart vid arbete med forks.

Den främsta fördelen med denna modell är att utvecklaren kan arbeta med koden offline och synkronisera ändringarna endast när hen är redo att skicka resultatet.

Skillnader mellan lokalt och fjärranslutet repository

Hur Git lagrar data i repositoryt

Gits lagringsmodell skiljer sig fundamentalt från andra versionshanteringssystem. Istället för att lagra en lista över ändringar (delta) mellan versioner, lagrar Git fullständiga ögonblicksbilder av alla projektfiler vid tidpunkten för varje commit.

Varje objekt i repositoryt identifieras av en unik SHA-1-hash på 40 tecken. Om innehållet i en fil inte har ändrats mellan commits, skapar Git inte ett nytt objekt utan återanvänder det befintliga — detta sparar utrymme.

Git använder fyra objekttyper: blob (filinnehåll), tree (katalogstruktur), commit (ögonblicksbild med metadata) och tag (namngiven referens till en commit). Alla objekt lagras i mappen .git/objects.

Enligt Git Internals säkerställer Gits objektmodell dataintegritet: varje ändring av filinnehåll leder till en ny hash, vilket gör det omöjligt att obemärkt ändra historiken.

Struktur för .git-mappen

Mappen .git — är repositoryts hjärta. Utan den kan Git inte spåra ändringar, och en vanlig katalog förblir bara en samling filer. Att förstå strukturen i denna mapp hjälper till att diagnostisera problem med repositoryt.

• objects/ — alla objekt i repositoryt: blobbar, träd, commits, taggar. Lagras i komprimerad form.
• refs/ — referenser till commits: heads (grenar), tags (etiketter), remotes (fjärrgrenar).
• HEAD — fil som pekar på den nuvarande aktiva grenen eller commiten.
• config — repositoryinställningar: fjärr-URL, användarnamn, e-post och andra parametrar.
• index — staging area (index), där Git lagrar information om filer som är förberedda för commit.
• logs/ — referensuppdateringsloggar (reflog), som lagrar historiken över HEAD- och grenförflyttningar.

Fil HEAD förtjänar särskild uppmärksamhet. I normalt tillstånd innehåller den en symbolisk referens till en gren, till exempel ref: refs/heads/main. I tillståndet detached HEAD pekar den direkt på en commit — detta innebär att nya commits inte kommer att vara kopplade till någon gren.

Grundläggande operationer med repositoryt

Arbete med Git-repositoryt omfattar en uppsättning grundläggande operationer som en utvecklare utför dagligen. Varje operation ändrar repositoryts tillstånd, lägger till nya objekt eller flyttar referenser.

• git init — skapar ett nytt tomt repository i den aktuella katalogen. Git skapar .git-mappen med en initial struktur.
• git clone — kopierar ett befintligt fjärranslutet repository till den lokala datorn tillsammans med hela commit-historiken.
• git add — lägger till filändringar i staging area (index) och förbereder dem för commit.
• git commit — skapar en ögonblicksbild av projektet baserat på data från index och lagrar den som ett nytt commit-objekt.
• git push — skickar nya commits från det lokala repositoryt till det fjärranslutna och uppdaterar grenar på servern.
• git pull — hämtar nya commits från det fjärranslutna repositoryt och slår samman dem med den aktuella lokala grenen.

Operationerna push och pull — är de enda som kräver anslutning till fjärrservern. Alla andra operationer utförs helt lokalt, vilket säkerställer hög arbetshastighet även med en stor historik.

Livscykel för en fil i repositoryt

Varje fil i repositoryt går igenom fyra tillstånd: untracked (ej spårad), modified (ändrad), staged (förberedd) och committed (committad). Git spårar endast filer som uttryckligen har lagts till via git add eller redan finns i commit-historiken.

Att förstå denna modell — nyckeln till effektivt arbete med Git. Utvecklaren kan selektivt förbereda endast en del av de ändrade filerna för commit, vilket skapar logiskt fullständiga commits med tydliga beskrivningar.

Populära plattformar för att lagra repositories

Fjärranslutna repositories är vanligtvis värd på specialiserade plattformar som tillhandahåller webbgränssnitt, åtkomsthanteringssystem och ytterligare verktyg för samarbetsutveckling.

• GitHub — den största plattformen med över 100 miljoner repositories. Erbjuder Actions, Pull Requests, Issues och Wiki. Gratis för offentliga projekt.
• GitLab — plattform med integrerad CI/CD, Container Registry och inbyggd DevOps-pipeline. Tillgänglig som SaaS och self-hosted version.
• Bitbucket — lösning från Atlassian med integration av Jira och Trello. Populär i företagsmiljöer tack vare flexibla åtkomstinställningar.

Valet av plattform beror på teamets storlek, integritetskrav och nödvändiga integrationer. För mobilutveckling väljs ofta GitHub på grund av dess breda community-stöd och integration med CI/CD-verktyg för iOS och Android.

Exempel på kommandon för att arbeta med repositoryt

Låt oss titta på ett praktiskt scenario: en utvecklare klonar ett befintligt repository, skapar en ny gren, gör ändringar och skickar dem till servern. Varje kommando demonstrerar arbete med olika komponenter i repositoryt.

# Kloning av fjärranslutet repository
git clone https://github.com/user/mobile-app.git

# Navigera till projektkatalogen
cd mobile-app

# Skapa en ny feature-gren och växla till den
git checkout -b feature/auth

# Kontrollera status för ändrade filer
git status

# Lägga till alla ändringar i staging area
git add .

# Skapa en commit med beskrivning
git commit -m "Add authentication module"

# Skicka ändringar till fjärranslutet repository
git push origin feature/auth

Kommandot git status — ett av de mest användbara i dagligt arbete. Det visar vilka filer som har ändrats, vilka som är förberedda för commit och vilka som inte alls spåras av Git.

Visa commit-historik

För att analysera repositoryts historik används kommandot git log med olika formateringsflaggor. Det visar kronologin för commits, deras författare, datum och SHA-1-identifierare.

# Visa historik med visualisering av gengraf
git log --oneline --graph --all

# Visa ändringar i en specifik commit
git show a1b2c3d

# Jämföra aktuell status med senaste commiten
git diff HEAD

# Visa historik för en specifik fil
git log --follow src/MainActivity.kt

Flaggan --graph visar en ASCII-graf över förgreningar, vilket är särskilt användbart i repositories med aktivt arbete i flera grenar. För mobilprojekt med frekventa releaser hjälper den visuella grafen att snabbt bedöma utvecklingsstrukturen.