Git i kontrola wersji w rozwoju mobilnym: co to jest, podstawowe polecenia i jak działa

Kontrola wersji i Git: co to jest?

Git to rozproszony system kontroli wersji (VCS) stworzony przez Linusa Torvaldsa w 2005 roku do rozwoju jądra Linux. W przeciwieństwie do systemów scentralizowanych (SVN, CVS), Git przechowuje pełną kopię historii projektu na każdym komputerze programisty. Oznacza to, że możesz wykonywać commity, przeglądać historię i tworzyć gałęzie nawet bez połączenia z internetem.

Git działa za pomocą migawek (snapshotów) — każdy commit zapisuje stan wszystkich plików projektu w momencie zapisu. Jeśli plik się nie zmienił, Git tworzy odniesienie do poprzedniej wersji, oszczędzając miejsce. Według analizy GitHub (2025), przeciętne repozytorium zawiera 1200 commitów i 15 gałęzi.

W IT Sectr używamy Gita od 2017 roku we wszystkich projektach. Nasze doświadczenie pokazuje, że prawidłowa konfiguracja Gita od pierwszego dnia oszczędza zespołowi do 30% czasu na scalanie i rozwiązywanie konfliktów. Git stał się standardem de facto — jest obsługiwany przez wszystkie nowoczesne IDE (Android Studio, Xcode, VS Code) i systemy CI/CD.

# Podstawowa konfiguracja Gita
git config --global user.name "Twoje Imię"
git config --global user.email "twoj@email.com"

# Tworzenie nowego repozytorium
git init my-project
cd my-project

# Dodawanie plików i commit
git add README.md
git commit -m "Initial commit"

# Praca z repozytorium zdalnym
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Powyższy kod pokazuje podstawową sekwencję: inicjalizację repozytorium, pierwszy commit i publikację na zdalnym serwerze. Polecenie git init tworzy ukryty folder .git, który będzie przechowywać całą historię projektu. Każdy git commit tworzy punkt przywracania, do którego możesz wrócić w dowolnym momencie.

Podstawowe koncepcje: Repository, Branch, Commit

Zrozumienie trzech podstawowych koncepcji — Repository, Branch i Commit — jest niezbędne do pracy z dowolnym systemem kontroli wersji. Repozytorium jest kontenerem dla całego projektu. Commit jest zapisanym stanem plików. Branch jest oddzielną linią rozwoju.

Repository (repozytorium) może być lokalne (na twoim komputerze) lub zdalne (na serwerze GitHub, GitLab). Każdy programista klonuje zdalne repozytorium na swoją maszynę i pracuje z lokalną kopią. Zmiany są synchronizowane przez push (wysyłanie) i pull (pobieranie). W rozproszonej kontroli wersji każdy programista przechowuje pełną kopię historii.

Branch (gałąź) to wskaźnik do jednego z commitów. Gałęzie umożliwiają równoległy rozwój: jeden programista pracuje nad nową funkcją (feature branch), drugi naprawia błąd (hotfix branch), trzeci przygotowuje wydanie (release branch). Według GitLab Flow (2025), przeciętny projekt ma 3–5 aktywnych gałęzi jednocześnie.

Commit to jednostka zmiany. Każdy commit zawiera unikalny skrót (SHA-1), wiadomość, autora i znacznik czasu. Dobrą praktyką jest robienie małych znaczących commitów z opisowymi wiadomościami — upraszcza to Code Review i wycofywanie zmian. Kontrola wersji poprzez commity daje pełną historię projektu.

Feature Branch

Feature Branch (gałąź funkcji) to tymczasowa gałąź tworzona z develop lub main do opracowania konkretnego zadania. Po zakończeniu pracy gałąź jest scalana z powrotem przez Pull Request i usuwana. Ta praktyka pozwala izolować zmiany bez naruszania stabilności głównej bazy kodu.

Typowy przepływ pracy: utwórz gałąź feature/add-login → wykonaj kilka commitów → utwórz Pull Request → przejdź Code Review → scal z develop. W IT Sectr używamy dokładnie takiego podejścia: każde zadanie Jira odpowiada oddzielnej gałęzi funkcji. Upraszcza to śledzenie zmian i wycofywanie w razie potrzeby.

Rebase vs Merge

Merge tworzy commit scalenia, który łączy dwie gałęzie. Zachowuje pełną historię, w tym równoległe linie rozwoju. Rebase przepisuje historię: pobiera commity z jednej gałęzi i "nakłada" je na drugą, tworząc liniową historię.

Merge lepiej sprawdza się w przypadku publicznych gałęzi i dużych zespołów, gdzie ważna jest chronologia. Rebase jest wygodny dla osobistych gałęzi funkcji przed utworzeniem PR — czyni historię czystszą i bardziej zrozumiałą. Jednak rebase nigdy nie powinien być stosowany do gałęzi, nad którymi pracują inni programiści, ponieważ przepisuje historię.

# Tworzenie i przełączanie na gałąź funkcji
git checkout -b feature/add-login main

# Praca w gałęzi
git add login-screen/
git commit -m "Add login screen layout"

# Rebase na najnowszy main przed PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push do zdalnego repozytorium
git push origin feature/add-login

Ten przykład pokazuje typowy przepływ pracy: utworzenie gałęzi funkcji z main, kilka commitów i rebase w celu uzyskania czystej liniowej historii przed wysłaniem do przeglądu. Takie podejście minimalizuje konflikty scalania.

Git Flow vs Trunk-Based Development

Git Flow i Trunk-Based Development to dwie główne strategie kontroli wersji, które określają, jak zespół organizuje pracę z Gitem. Wybór zależy od wielkości zespołu, częstotliwości wydań i wymagań dotyczących stabilności.

Git Flow to ścisły model z wieloma stałymi gałęziami: main (kod wydania), develop (bieżący rozwój), feature/* (nowe funkcje), release/* (przygotowanie wydania) i hotfix/* (pilne poprawki). Ten model jest dobry dla projektów z jasnymi cyklami wydań (np. aplikacje mobilne z wersjami 1.0, 2.0).

Trunk-Based Development to podejście z pojedynczą główną gałęzią (trunk/main), do której wszyscy programiści scalają zmiany kilka razy dziennie. Flagi funkcji są używane do ukrywania niekompletnych funkcji. To podejście jest popularne w tworzeniu stron internetowych i startupach, gdzie liczy się szybkość dostarczania.

Git Flow

Git Flow, zaproponowany przez Vincenta Driessena w 2010 roku, pozostaje jednym z najpopularniejszych modeli. Jego główną zaletą jest ścisłe oddzielenie kodu według etapów cyklu życia. Gałąź main zawiera tylko kod wydania, develop zawiera bieżący rozwój, a gałęzie funkcji izolują nowe funkcje od siebie.

Gałęzie hotfix są tworzone z main do pilnych poprawek i po scaleniu są scalane zarówno z main, jak i develop. Gałęzie release są tworzone z develop, gdy zespół jest gotowy do wydania. Dodawane są tylko poprawki błędów i metadane (wersja, kompilacja). Po wydaniu gałąź release jest scalana z main i develop. Według ankiety JetBrains (2024), 37% zespołów używa Git Flow. Ten model kontroli wersji pozostaje standardem dla projektów ze stałymi wydaniami.

# Przykład Git Flow: rozpoczęcie pracy nad wydaniem
git checkout -b release/1.2.0 develop

# Naprawa błędów w gałęzi release
git commit -m "Fix login button crash"

# Zakończenie wydania — scalenie z main i develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Usunięcie gałęzi release
git branch -d release/1.2.0

Kod ilustruje tworzenie gałęzi release, jej stabilizację i scalanie z głównymi gałęziami. Flaga --no-ff gwarantuje commit scalenia, zachowując informację, że zmiany pochodzą z gałęzi release.

Pull Request i Code Review

Pull Request (PR) to mechanizm, za pomocą którego programista proponuje zmiany ze swojej gałęzi do głównej. PR jest kluczowym elementem kontroli wersji w pracy zespołowej — to nie tylko sposób na scalenie kodu, ale proces dyskusji, przeglądu i kontroli jakości. W GitLab podobny mechanizm nazywa się Merge Request (MR), ale istota jest ta sama: poinformowanie zespołu o zmianach i uzyskanie zatwierdzenia.

Dobry PR powinien być mały (do 300 linii kodu), skoncentrowany na jednym zadaniu i zawierać opis tego, co zostało zrobione i dlaczego. Według badania Google (2025), PR o objętości ponad 400 linii są sprawdzane dwa razy dłużej, a prawdopodobieństwo wykrycia błędów spada o 30%. Code Review to sprawdzenie kodu przez innego programistę przed scaleniem.

W IT Sectr praktykujemy obowiązkowe Code Review dla każdego PR. To nie tylko poprawia jakość kodu, ale także pomaga rozpowszechniać wiedzę w zespole. Code Review sprawdza: czy kod przestrzega zasad architektonicznych, czy nie ma błędów, czy jest wystarczająco testów, czy zmienne są prawidłowo nazwane. Wszystkie uwagi są omawiane w PR aż do scalenia.

Platformy: GitHub, GitLab, Bitbucket

Git to protokół, ale do współpracy potrzebna jest platforma kontroli wersji, która zapewnia interfejs webowy, zarządzanie dostępem, CI/CD i narzędzia do przeglądu. Na rynku dominują trzy platformy: GitHub, GitLab i Bitbucket.

GitHub to największa platforma z ponad 56 milionami programistów. Należąca do Microsoft, oferuje Actions (CI/CD), Pages (hosting), Discussions i Copilot. Darmowy plan obejmuje nieograniczone prywatne repozytoria dla zespołów do 3 osób. GitHub jest popularny w społeczności open-source.

GitLab to pełna platforma DevOps z zintegrowanym CI/CD, rejestrem kontenerów i zarządzaniem infrastrukturą. W przeciwieństwie do GitHub, GitLab można zainstalować na własnym serwerze (Self-Managed). Bitbucket od Atlassian jest ściśle zintegrowany z Jira i Confluence, co czyni go wyborem dla zespołów już korzystających z ekosystemu Atlassian.