Slovník pojmů

Git

Git eviduje změny, větve a historii projektu. Není totéž co GitHub, automatické nasazení ani náhrada promyšleného review a zálohování.

Stručná definice

Lokální historie změn, kterou lze sdílet s ostatními.

Git ukládá commity jako navazující historii obsahu projektu. Vývojář pracuje ve working tree, vybere změny do staging area, vytvoří commit a podle potřeby jej odešle do vzdáleného repozitáře. Větve umožňují rozvíjet změny odděleně a poté je vědomě integrovat.

Protože je Git distribuovaný, vzdálený repozitář není „Git sám“, ale jedno z míst pro sdílení historie. GitHub, GitLab nebo jiná služba mohou nad repozitářem poskytovat pull requesty, oprávnění, issue tracker a CI, ale nejsou součástí základního Git modelu.

Jaký problém řeší

Dohledatelné změny a spolupráci nad stejným kódem

Verzování umožňuje týmům porozumět změně, propojit ji s testy a bezpečně ji začlenit do společné historie.

oddělený vývoj funkcí a oprav ve větvích
dohledání autora, obsahu a souvislostí změny v historii
review a CI kontroly před spojením do hlavní větve
tagování konkrétní verze pro release nebo nasazení
návrat k dřívějšímu stavu kódu s vědomím dopadu na data a provoz

Praktický příklad

Větev pro import skladu

Vývojář vytvoří větev, připraví malou změnu, přidá ji do staging area a vytvoří commit. Větev pak odešle do vzdáleného repozitáře, kde může vzniknout pull request s review a kontrolami.

Příkazy neznamenají automatické nasazení ani dokončení úkolu. Teprve pravidla týmu, CI, review a deployment určují, co se po spojení změny do hlavní větve skutečně stane.

git switch -c feature/stock-import
git add src/Import/
git commit -m "Add idempotent stock import"
git push -u origin feature/stock-import

Jak funguje

Od pracovní kopie ke sdílené změně

Textový diagram: working tree → staging area → lokální commit → vzdálený repozitář.

Working tree Vývojář mění soubory v pracovní kopii projektu.
Staging area Příkaz git add vybírá, které změny budou součástí dalšího commitu.
Commit Git uloží lokální záznam historie s vybraným obsahem a rodičovskými commity.
Sdílení větve Push odešle lokální reference do remote repozitáře; neznamená sám o sobě produkční deployment.
Integrace Merge nebo rebase řeší vztah větví. Konflikt znamená, že tým musí rozhodnout mezi neslučitelnými změnami.

Důležité pojmy

Commit, větev a remote mají různý účel.

Porozumění rozdílům zabraňuje tomu, aby se změny sdílely nebo přepisovaly nečekaně.

Commit a hash

Commit je záznam vybraného obsahu a jeho vztahu k historii. Je identifikovaný hashem, ne obyčejným názvem souboru.

Větev

Branch je pohyblivý odkaz do historie, nikoli úplná kopie celého projektu. Umožňuje izolovat změnu před integrací.

Fetch, pull a push

Fetch stáhne informace z remote. Pull obvykle kombinuje fetch s integrací podle konfigurace. Push odešle lokální větev.

Merge a rebase

Merge vytváří spojení historií; rebase přesazuje commity na jiný základ. Oba postupy mají týmová pravidla a rizika.

.gitignore

Brání přidání dosud nesledovaných souborů podle pravidel. Neodstraní secret, který už byl commitnutý.

Vztah k podobným pojmům

Git, GitHub a nasazení nejsou stejné věci.

Slovní rozlišení je praktické při řešení přístupů, incidentu i workflow týmu.

Git a GitHub: Git je verzovací systém. GitHub je hostingová a spolupracovní služba nad Git repozitáři.
Commit a push: Commit uloží změnu lokálně; push ji odešle do konkrétního vzdáleného repozitáře.
Větev a kopie projektu: Větev je reference do historie. Pracovní kopie může obsahovat více větví postupně, aniž by se celý projekt fyzicky duplikoval.
Push a deployment: Push může spustit CI, ale produkční nasazení je samostatný proces s vlastními pravidly a kontrolami.

Výhody a omezení

Historie pomáhá jen spolu s disciplínou týmu.

Přínosy

dohledatelné a porovnatelné změny kódu
práce offline s lokální historií
větve pro paralelní vývoj a review
napojení na CI, release a pravidla ochrany hlavní větve

Časté chyby

považovat commit za zálohu mimo lokální disk nebo za publikaci změny
commitnout secret a jen jej později smazat bez rotace přístupu
force pushem přepsat sdílenou historii bez dohody
posílat velké nesourodé commity, které nelze efektivně reviewovat

Kdy dává smysl

Pro zdrojový kód i konfiguraci, která musí mít historii.

Git je vhodný od malého projektu po týmový produkt. Největší hodnotu přináší, když se změny dělí na čitelné commity a na jejich integraci navazují testy, review a jasná release pravidla.

Není náhradou zálohy databáze, uživatelských souborů nebo secrets manageru. Data a nasazení mají vlastní životní cyklus, i když konfigurace pro jejich správu může být verzovaná.

Na co myslet

Čitelná historie je součást kvality změny.

Způsob práce s verzováním ovlivňuje review, incident response i budoucí údržbu.

dělit změny na smysluplné commity s jasným záměrem
chránit hlavní větev review a povinnými CI kontrolami
necommitovat secrets; při úniku je odvolat nebo rotovat
domluvit v týmu pravidla pro merge, rebase a force push
před změnou historie ověřit, kdo na ní už může záviset

Časté otázky

Git bez častých záměn

Je Git totéž co GitHub?

Ne. Git je verzovací systém, GitHub je jedna ze služeb pro hostování a spolupráci nad Git repozitáři.

Jaký je rozdíl mezi commitem a pushem?

Commit uloží změnu do lokální historie. Push odešle větev do vzdáleného repozitáře.

Je branch kopie projektu?

Ne. Větev je reference v historii, která umožňuje odděleně rozvíjet změny.

Co udělat po omylem commitnutém secretu?

Přístupový údaj je třeba co nejdříve odvolat nebo rotovat. Pouhé smazání souboru nezaručuje, že secret zmizel ze sdílené historie či klonů.

Jak držím kvalitu vývoje

Změny spojuji s testy, review a opakovatelným procesem.

V PHP projektech používám Git worktrees, CI a quality gates, aby šla změna bezpečně ověřit dříve, než se dostane do provozu.

Jak pracuji s testováním a kvalitou Nezávazně probrat projekt