Git a správa verzí v mobilním vývoji: co to je, základní příkazy a jak to funguje

Správa verzí a Git: co to je?

Git je distribuovaný systém správy verzí (VCS) vytvořený Linusem Torvaldsem v roce 2005 pro vývoj linuxového jádra. Na rozdíl od centralizovaných systémů (SVN, CVS) ukládá Git úplnou kopii historie projektu na každém počítači vývojáře. To znamená, že můžete provádět commity, procházet historii a vytvářet větve i bez připojení k internetu.

Git pracuje s momenty (snapshoty) — každý commit ukládá stav všech souborů projektu v okamžiku uložení. Pokud se soubor nezměnil, Git vytvoří odkaz na předchozí verzi, čímž šetří místo. Podle analýzy GitHub (2025) obsahuje průměrný repozitář 1 200 commitů a 15 větví.

Ve společnosti IT Sectr používáme Git od roku 2017 ve všech projektech. Naše zkušenosti ukazují, že správná konfigurace Gitu od prvního dne šetří týmu až 30 % času při slučování a řešení konfliktů. Git se stal de facto standardem — je podporován všemi moderními IDE (Android Studio, Xcode, VS Code) a systémy CI/CD.

# Základní nastavení Gitu
git config --global user.name "Vaše Jméno"
git config --global user.email "vas@email.com"

# Vytvoření nového repozitáře
git init my-project
cd my-project

# Přidání souborů a commit
git add README.md
git commit -m "Initial commit"

# Práce se vzdáleným repozitářem
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Výše uvedený kód ukazuje základní posloupnost: inicializace repozitáře, první commit a publikace na vzdáleném serveru. Příkaz git init vytvoří skrytou složku .git, která bude ukládat celou historii projektu. Každý git commit vytváří bod obnovy, ke kterému se můžete kdykoli vrátit.

Základní koncepty: Repository, Branch, Commit

Pochopení tří základních konceptů — Repository, Branch a Commit — je nezbytné pro práci s jakýmkoli systémem správy verzí. Repozitář je kontejner pro celý projekt. Commit je uložený stav souborů. Branch je samostatná vývojová linie.

Repository (repozitář) může být lokální (na vašem počítači) nebo vzdálený (na serveru GitHub, GitLab). Každý vývojář klonuje vzdálený repozitář na svůj počítač a pracuje s lokální kopií. Změny se synchronizují pomocí push (odeslání) a pull (stažení). V distribuované správě verzí každý vývojář ukládá úplnou kopii historie.

Branch (větev) je ukazatel na jeden z commitů. Větve umožňují paralelní vývoj: jeden vývojář pracuje na nové funkci (feature branch), druhý opravuje chybu (hotfix branch), třetí připravuje vydání (release branch). Podle GitLab Flow (2025) má průměrný projekt současně 3–5 aktivních větví.

Commit je jednotka změny. Každý commit obsahuje jedinečný hash (SHA-1), zprávu, autora a časové razítko. Dobrou praxí je provádět malé smysluplné commity s popisnými zprávami — to zjednodušuje Code Review a vracení změn. Správa verzí prostřednictvím commitů poskytuje úplnou historii projektu.

Feature Branch

Feature Branch (větev funkce) je dočasná větev vytvořená z develop nebo main pro vývoj konkrétního úkolu. Po dokončení práce je větev sloučena zpět pomocí Pull Request a odstraněna. Tato praxe umožňuje izolovat změny, aniž by byla narušena stabilita hlavní kódové základny.

Typický pracovní postup: vytvořit větev feature/add-login → provést několik commitů → vytvořit Pull Request → projít Code Review → sloučit do develop. V IT Sectr používáme přesně tento přístup: každý úkol Jira odpovídá samostatné větvi funkce. To zjednodušuje sledování změn a v případě potřeby vracení.

Rebase vs Merge

Merge vytváří commit sloučení, který kombinuje dvě větve. Zachovává úplnou historii včetně paralelních vývojových linií. Rebase přepisuje historii: bere commity z jedné větve a "znovu je aplikuje" na druhou, čímž vytváří lineární historii.

Merge je vhodnější pro veřejné větve a velké týmy, kde je důležitá chronologie. Rebase je vhodný pro osobní větve funkcí před vytvořením PR — činí historii čistší a srozumitelnější. Rebase by se však nikdy neměl aplikovat na větve, na kterých pracují jiní vývojáři, protože přepisuje historii.

# Vytvoření a přepnutí na větev funkce
git checkout -b feature/add-login main

# Práce ve větvi
git add login-screen/
git commit -m "Add login screen layout"

# Rebase na nejnovější main před PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push do vzdáleného repozitáře
git push origin feature/add-login

Tento příklad ukazuje typický pracovní postup: vytvoření větve funkce z main, několik commitů a rebase pro získání čisté lineární historie před odesláním k posouzení. Tento přístup minimalizuje konflikty sloučení.

Git Flow vs Trunk-Based Development

Git Flow a Trunk-Based Development jsou dvě hlavní strategie správy verzí, které určují, jak tým organizuje práci s Gitem. Volba závisí na velikosti týmu, frekvenci vydání a požadavcích na stabilitu.

Git Flow je přísný model s několika trvalými větvemi: main (kód vydání), develop (aktuální vývoj), feature/* (nové funkce), release/* (příprava vydání) a hotfix/* (naléhavé opravy). Tento model je vhodný pro projekty s jasnými cykly vydání (např. mobilní aplikace s verzemi 1.0, 2.0).

Trunk-Based Development je přístup s jedinou hlavní větví (trunk/main), do které všichni vývojáři slučují změny několikrát denně. K skrytí nedokončených funkcí se používají příznaky funkcí. Tento přístup je populární ve webovém vývoji a startupech, kde je rychlost doručení důležitá.

Git Flow

Git Flow, navržený Vincentem Driessenem v roce 2010, zůstává jedním z nejoblíbenějších modelů. Jeho hlavní výhodou je přísné oddělení kódu podle fází životního cyklu. Větev main obsahuje pouze kód vydání, develop obsahuje aktuální vývoj a větve funkcí izolují nové funkce od sebe.

Větve hotfix se vytvářejí z main pro naléhavé opravy a po sloučení se slučují zpět do main i develop. Větve release se vytvářejí z develop, když je tým připraven k vydání. Přidávají se do nich pouze opravy chyb a metadata (verze, sestavení). Po vydání se větev release sloučí do main a develop. Podle průzkumu JetBrains (2024) používá Git Flow 37 % týmů. Tento model správy verzí zůstává standardem pro projekty s pevnými vydáními.

# Příklad Git Flow: zahájení práce na vydání
git checkout -b release/1.2.0 develop

# Oprava chyb ve větvi release
git commit -m "Fix login button crash"

# Dokončení vydání — sloučení do main a 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

# Smazání větve release
git branch -d release/1.2.0

Kód ilustruje vytvoření větve release, její stabilizaci a sloučení do hlavních větví. Přepínač --no-ff zaručuje commit sloučení, čímž zachovává informaci, že změny pocházejí z větve release.

Pull Request a Code Review

Pull Request (PR) je mechanismus, kterým vývojář navrhuje změny ze své větve do hlavní větve. PR je klíčovým prvkem správy verzí v týmové práci — není to jen způsob sloučení kódu, ale proces diskuse, posouzení a kontroly kvality. V GitLabu se podobný mechanismus nazývá Merge Request (MR), ale podstata je stejná: informovat tým o změnách a získat schválení.

Dobrý PR by měl být malý (do 300 řádků kódu), zaměřený na jeden úkol a obsahovat popis toho, co bylo provedeno a proč. Podle studie Google (2025) trvá posouzení PR nad 400 řádků dvakrát déle a pravděpodobnost odhalení chyb klesá o 30 %. Code Review je kontrola kódu jiným vývojářem před sloučením.

V IT Sectr praktikujeme povinnou Code Review pro každý PR. To nejen zlepšuje kvalitu kódu, ale také pomáhá šířit znalosti v rámci týmu. Code Review kontroluje: zda kód dodržuje architektonické principy, zda neobsahuje chyby, zda je dostatek testů, zda jsou proměnné správně pojmenovány. Všechny připomínky jsou v PR diskutovány až do sloučení.

Platformy: GitHub, GitLab, Bitbucket

Git je protokol, ale pro spolupráci je potřeba platforma pro správu verzí, která poskytuje webové rozhraní, správu přístupu, CI/CD a nástroje pro posouzení. Na trhu dominují tři platformy: GitHub, GitLab a Bitbucket.

GitHub je největší platforma s více než 56 miliony vývojářů. Vlastněná Microsoftem, nabízí Actions (CI/CD), Pages (hosting), Discussions a Copilot. Bezplatný tarif zahrnuje neomezené soukromé repozitáře pro týmy do 3 osob. GitHub je populární v komunitě open-source.

GitLab je kompletní DevOps platforma s integrovaným CI/CD, registrem kontejnerů a správou infrastruktury. Na rozdíl od GitHubu lze GitLab nainstalovat na vlastní server (Self-Managed). Bitbucket od Atlassian je úzce integrován s Jira a Confluence, což z něj činí volbu pro týmy již používající ekosystém Atlassian.