Repository w Git: co to jest, jakie są typy i jak działają

Co to jest repozytorium w Git

Repozytorium Git — to struktura danych, w której system kontroli wersji przechowuje metadane i obiekty opisujące historię zmian plików projektu. Gdy programista inicjalizuje repozytorium poleceniem git init, Git tworzy ukryty folder .git w katalogu głównym projektu.

Wewnątrz tego folderu znajdują się wszystkie obiekty, referencje i pliki konfiguracyjne niezbędne do działania systemu. Repozytorium nie jest przypisane do konkretnej lokalizacji — programista może utworzyć je lokalnie, a następnie połączyć ze zdalnym serwerem.

Git wykorzystuje model rozproszonego repozytorium: każdy uczestnik projektu ma pełną kopię historii na swoim komputerze. Oznacza to, że większość operacji — commit, przeglądanie historii, tworzenie gałęzi — wykonywana jest lokalnie bez dostępu do serwera.

Według danych dokumentacji Git, rozproszona architektura sprawia, że system jest odporny na awarie: jeśli serwer ulegnie awarii, każde lokalne repozytorium może stać się źródłem do przywrócenia pełnej historii projektu.

Repozytorium lokalne i zdalne

Repozytorium lokalne — to kopia projektu na komputerze programisty. Zawiera całą historię commitów, gałęzi i tagów oraz umożliwia wykonywanie operacji commit, branch, merge i rebase bez połączenia z siecią.

Repozytorium zdalne jest hostowane na serwerze i służy jako punkt synchronizacji dla wszystkich członków zespołu. Programiści wysyłają swoje zmiany poleceniem git push i pobierają zmiany innych poleceniem git pull.

Połączenie między repozytorium lokalnym a zdalnym konfiguruje się przez remote origin — adres URL serwera przechowywany w konfiguracji Git. Jedno lokalne repozytorium może być połączone z wieloma zdalnymi, co jest przydatne podczas pracy z forkami.

Główną zaletą takiego modelu jest to, że programista może pracować nad kodem w trybie offline, a synchronizować zmiany dopiero po przygotowaniu wyników do wysłania.

Różnice między repozytorium lokalnym a zdalnym

Jak Git przechowuje dane w repozytorium

Model przechowywania Git zasadniczo różni się od innych systemów kontroli wersji. Zamiast przechowywania listy zmian (delta) między wersjami, Git przechowuje pełne migawki wszystkich plików projektu w momencie każdego commita.

Każdy obiekt w repozytorium jest identyfikowany przez unikalny skrót SHA-1 o długości 40 znaków. Jeśli zawartość pliku nie zmieniła się między commitami, Git nie tworzy nowego obiektu, ale ponownie wykorzystuje istniejący — oszczędza to miejsce.

Git używa czterech typów obiektów: blob (zawartość pliku), tree (struktura katalogu), commit (migawka z metadanymi) i tag (nazwana referencja do commita). Wszystkie obiekty są przechowywane w folderze .git/objects.

Według danych Git Internals, model obiektowy Git zapewnia integralność danych: każda zmiana zawartości pliku powoduje nowy skrót, co uniemożliwia niezauważalną modyfikację historii.

Struktura folderu .git

Folder .git — to serce repozytorium. Bez niego Git nie może śledzić zmian, a zwykły katalog pozostaje tylko zbiorem plików. Zrozumienie struktury tego folderu pomaga diagnozować problemy z repozytorium.

• objects/ — wszystkie obiekty repozytorium: bloby, drzewa, commity, tagi. Przechowywane w skompresowanej formie.
• refs/ — referencje do commitów: heads (gałęzie), tags (etykiety), remotes (gałęzie zdalne).
• HEAD — plik wskazujący na aktualnie aktywną gałąź lub commit.
• config — ustawienia repozytorium: zdalny URL, nazwa użytkownika, e-mail i inne parametry.
• index — staging area (indeks), gdzie Git przechowuje informacje o plikach przygotowanych do commita.
• logs/ — dzienniki aktualizacji referencji (reflog), które przechowują historię przemieszczania HEAD i gałęzi.

Plik HEAD zasługuje na szczególną uwagę. W normalnym stanie zawiera symboliczną referencję do gałęzi, na przykład ref: refs/heads/main. W stanie detached HEAD wskazuje bezpośrednio na commit — oznacza to, że nowe commity nie będą przypisane do żadnej gałęzi.

Podstawowe operacje na repozytorium

Praca z repozytorium Git obejmuje zestaw podstawowych operacji, które programista wykonuje codziennie. Każda operacja zmienia stan repozytorium, dodając nowe obiekty lub przesuwając referencje.

• git init — tworzy nowe puste repozytorium w bieżącym katalogu. Git tworzy folder .git z początkową strukturą.
• git clone — kopiuje istniejące zdalne repozytorium na lokalny komputer wraz z całą historią commitów.
• git add — dodaje zmiany plików do staging area (indeksu), przygotowując je do commita.
• git commit — tworzy migawkę projektu na podstawie danych z indeksu i zapisuje ją jako nowy obiekt commit.
• git push — wysyła nowe commity z lokalnego repozytorium do zdalnego, aktualizując gałęzie na serwerze.
• git pull — pobiera nowe commity ze zdalnego repozytorium i scala je z bieżącą lokalną gałęzią.

Operacje push i pull — to jedyne, które wymagają połączenia ze zdalnym serwerem. Wszystkie pozostałe operacje są wykonywane całkowicie lokalnie, co zapewnia wysoką szybkość działania nawet przy dużej historii.

Cykl życia pliku w repozytorium

Każdy plik w repozytorium przechodzi przez cztery stany: untracked (nieśledzony), modified (zmodyfikowany), staged (przygotowany) i committed (zatwierdzony). Git śledzi tylko pliki, które zostały jawnie dodane przez git add lub już znajdują się w historii commitów.

Zrozumienie tego modelu — klucz do efektywnej pracy z Git. Programista może wybiórczo przygotowywać do commita tylko część zmodyfikowanych plików, tworząc logicznie kompletne commity z przejrzystym opisem.

Popularne platformy do przechowywania repozytoriów

Repozytoria zdalne są zwykle hostowane na specjalistycznych platformach, które zapewniają interfejs webowy, system zarządzania dostępem i dodatkowe narzędzia do wspólnego tworzenia oprogramowania.

• GitHub — największa platforma z ponad 100 milionami repozytoriów. Oferuje Actions, Pull Requests, Issues i Wiki. Bezpłatna dla projektów publicznych.
• GitLab — platforma z zintegrowanym CI/CD, Container Registry i wbudowanym pipeline DevOps. Dostępna jako SaaS i wersja self-hosted.
• Bitbucket — rozwiązanie od Atlassian z integracją Jira i Trello. Popularne w środowisku korporacyjnym dzięki elastycznym ustawieniom dostępu.

Wybór platformy zależy od wielkości zespołu, wymagań dotyczących prywatności i potrzebnych integracji. Do tworzenia aplikacji mobilnych często wybiera się GitHub ze względu na szerokie wsparcie społeczności i integrację z narzędziami CI/CD dla iOS i Android.

Przykłady poleceń do pracy z repozytorium

Rozważmy praktyczny scenariusz: programista klonuje istniejące repozytorium, tworzy nową gałąź, wprowadza zmiany i wysyła je na serwer. Każde polecenie demonstruje pracę z różnymi komponentami repozytorium.

# Klonowanie zdalnego repozytorium
git clone https://github.com/user/mobile-app.git

# Przejście do katalogu projektu
cd mobile-app

# Utworzenie nowej gałęzi feature i przełączenie się na nią
git checkout -b feature/auth

# Sprawdzenie statusu zmodyfikowanych plików
git status

# Dodanie wszystkich zmian do staging area
git add .

# Utworzenie commita z opisem
git commit -m "Add authentication module"

# Wysłanie zmian do zdalnego repozytorium
git push origin feature/auth

Polecenie git status — jedno z najbardziej przydatnych w codziennej pracy. Pokazuje, które pliki zostały zmodyfikowane, które są przygotowane do commita, a które w ogóle nie są śledzone przez Git.

Przeglądanie historii commitów

Do analizy historii repozytorium używane jest polecenie git log z różnymi flagami formatowania. Wyświetla chronologię commitów, ich autorów, daty i identyfikatory SHA-1.

# Wyświetlenie historii z wizualizacją grafu gałęzi
git log --oneline --graph --all

# Wyświetlenie zmian w konkretnym commicie
git show a1b2c3d

# Porównanie bieżącego stanu z ostatnim commitem
git diff HEAD

# Wyświetlenie historii konkretnego pliku
git log --follow src/MainActivity.kt

Flaga --graph wyświetla ASCII-wykres rozgałęzień, co jest szczególnie przydatne w repozytoriach z aktywną pracą w wielu gałęziach. Dla projektów mobilnych z częstymi wydaniami wizualny wykres pomaga szybko ocenić strukturę rozwoju.