Git & GitHub

Git a GitHub jsou základní součástí toho, jak spravuji zdrojový kód, bezpečně vyvíjím software a udržuji projekty dlouhodobě přehledné a spravovatelné.

Git používám pro správu verzí a GitHub jako platformu pro spolupráci, repozitáře a automatizaci. Společně mi poskytují strukturovaný způsob, jak sledovat změny, experimentovat bez poškození stabilního kódu, procházet historii vývoje a udržovat spolehlivá vydání.

Správa verzí pro mě není pouze místem pro ukládání zdrojových souborů. Je součástí samotného inženýrského procesu.

Jak používám Git & GitHub

Git a GitHub používám pro:

• správu verzí zdrojového kódu,
• vývoj nových funkcí,
• opravy chyb,
• správu vydání,
• branching a merging,
• kontrolu historických změn,
• udržování více verzí projektu,
• spolupráci,
• sledování issues,
• dokumentaci,
• automatizované buildy a testy,
• deployment workflow,
• zálohu historie vývoje.

To platí pro webový vývoj, Android aplikace, backendové projekty, utility i experimentální software.

Správa verzí jako bezpečnostní vrstva

Software se neustále mění.

Nové funkce, aktualizace závislostí i opravy chyb mohou přinést neočekávané problémy, i když původní změna působí jako drobná.

Git mi poskytuje kompletní historii těchto změn.

Pokud se něco pokazí, mohu zjistit:

• co se změnilo,
• kdy se to změnilo,
• proč ke změně došlo,
• které soubory byly ovlivněny,
• který dřívější stav byl prokazatelně funkční.

Vývoj je díky tomu výrazně bezpečnější než úpravy jediné nekontrolované kopie projektu.

Smysluplné commity

Preferuji commity, které představují srozumitelné kroky vývoje.

Užitečný commit by měl přiměřeně jasně sdělovat, co se změnilo a proč.

To zlepšuje:

• debugging,
• code review,
• historii projektu,
• budoucí údržbu.

Při hledání regrese o několik měsíců později je smysluplná historie mnohem užitečnější než řada neurčitých commitů typu „update“ nebo „fix“.

Historii commitů proto považuji za technickou dokumentaci.

Branching

Branches mi umožňují vyvíjet změny bez okamžitého zásahu do stabilní verze projektu.

Používám je například pro:

• nové funkce,
• experimentální změny,
• refaktoring,
• opravy chyb,
• větší změny architektury.

Změnu tak mohu samostatně otestovat před rozhodnutím, zda patří do hlavní codebase.

U větších projektů je toto oddělení stále důležitější, protože současně může probíhat několik různých vývojových aktivit.

Merging a řešení konfliktů

Paralelní vývoj někdy vede ke konfliktům.

Git konflikty řeším pochopením skutečných změn v kódu, nikoli slepým výběrem jedné ze stran.

Konflikt často znamená, že dvě změny zasahují do stejné části systému, takže správný výsledek může vyžadovat spojení obou záměrů.

To je zvlášť důležité u konfiguračních souborů, aplikační architektury a často upravovaných komponent.

Stabilní hlavní větve

Primární větev preferuji udržovat v použitelném stavu.

Experimentální práce patří do samostatných branches, dokud nejsou dostatečně otestované a připravené stát se součástí hlavního projektu.

Tím se snižuje riziko, že se nedokončená práce nečekaně dostane do vydání.

U produkčního softwaru by z repozitáře mělo být jasně patrné, který kód představuje aktuální stabilní stav.

Tagy a releases

U projektů s jasně identifikovatelnými verzemi používám tagy a releases pro zachování důležitých milníků.

Může jít například o verze:

• 1.0.0,
• 1.1.0,
• 2.0.0.

Release by měl odpovídat známému stavu zdrojového kódu.

Díky tomu lze reprodukovat starší buildy, zkoumat historické problémy a přesně určit, který kód byl v konkrétním okamžiku vydán.

Semantic Versioning

Tam, kde je to vhodné, používám strukturovaná čísla verzí pro vyjádření rozsahu změn mezi jednotlivými releases.

Typická verze může rozlišovat mezi:

• zásadními změnami,
• novou zpětně kompatibilní funkcionalitou,
• opravami chyb.

Konkrétní release strategie závisí na projektu, ale předvídatelné verzování usnadňuje správu softwaru vývojářům i uživatelům.

GitHub repozitáře

GitHub je centrálním místem pro řadu mých vývojových projektů.

Repozitář může obsahovat mnohem víc než jen zdrojový kód.

Používám jej pro organizaci:

• kódu,
• dokumentace,
• konfigurace,
• informací o releases,
• vývojových poznámek,
• issues,
• automatizačních workflow.

Technická historie projektu tak zůstává přímo spojena s projektem samotným.

Veřejné a soukromé repozitáře

Ne každý repozitář by měl být veřejný.

Viditelnost repozitáře volím podle typu projektu.

Veřejné repozitáře jsou vhodné pro:

• open-source software,
• ukázky,
• znovupoužitelné nástroje,
• technické demonstrace.

Soukromé repozitáře jsou vhodné pro:

• práci pro klienty,
• proprietární aplikace,
• infrastrukturu citlivou na přihlašovací údaje,
• interní vývoj.

Správa verzí zůstává hodnotná bez ohledu na to, zda je kód veřejně dostupný.

GitHub Issues

U projektů, které potřebují strukturovanou správu úkolů a chyb, používám GitHub Issues pro dokumentování práce, které je potřeba se věnovat.

Issue může popisovat:

• chybu,
• požadovanou funkci,
• technický problém,
• vylepšení,
• budoucí práci.

Udržování těchto informací přímo u repozitáře usnadňuje propojení vývojových rozhodnutí s kódem, který je následně implementuje.

Pull Requests

Pull requests poskytují užitečnou kontrolní hranici před začleněním změn do stabilní větve.

I při samostatné práci může být pull-request model užitečný pro větší změny, protože poskytuje přehled o:

• změněných souborech,
• commitech,
• rozdílech v kódu,
• diskusi,
• automatizovaných kontrolách.

U týmových projektů pull requests zároveň vytvářejí strukturované prostředí pro kontrolu příspěvků před jejich sloučením.

Code Review

Code review není pouze o hledání syntaktických chyb.

Užitečná kontrola zohledňuje:

• správnost,
• udržovatelnost,
• bezpečnost,
• architekturu,
• zbytečnou složitost,
• okrajové případy,
• kompatibilitu.

Porovnávací nástroje GitHubu usnadňují přesně zjistit, co navrhovaná změna upravuje.

To je zvlášť hodnotné u velkých patchů, kde je pochopení rozdílu užitečnější než opětovné pročítání celých souborů.

GitHub Actions

GitHub Actions umožňují automatizovat vývojové úlohy při událostech v repozitáři.

Používám nebo navrhuji automatizovaná workflow například pro:

• buildování aplikací,
• spouštění testů,
• validaci zdrojového kódu,
• vytváření artefaktů,
• kontrolu releases,
• deployment.

Automatizace omezuje opakovanou manuální práci a zvyšuje konzistenci důležitých kontrol.

Namísto spoléhání na to, že si někdo pokaždé vzpomene na všechny kroky vydání, lze velkou část procesu zakódovat přímo do repozitáře.

Continuous Integration

Continuous integration je zvlášť hodnotná s rostoucí velikostí projektu.

Repozitář může nové změny automaticky ověřit dříve, než se stanou součástí stabilní codebase.

Podle projektu mohou kontroly zahrnovat:

• kompilaci,
• automatizované testy,
• statickou analýzu,
• validaci závislostí,
• balíčkování.

Neúspěšná kontrola poskytuje okamžitý signál, že změna vyžaduje pozornost.

To je výrazně bezpečnější než objevit problém až po nasazení.

GitHub a vývoj pro Android

Git workflow používám také u Android projektů.

Repozitář může sledovat:

• zdrojový kód v Kotlinu,
• rozhraní v Jetpack Compose,
• Gradle konfiguraci,
• Android resources,
• lokalizační soubory,
• verze aplikace.

To poskytuje jasnou historii vývoje aplikace a umožňuje přesně izolovat změny mezi jednotlivými releases.

Generované build artefakty a soubory specifické pro konkrétní počítač vylučuji tam, kde do správy verzí nepatří.

GitHub a webový vývoj

U webových projektů používám Git ke sledování vlastního aplikačního kódu, konfigurace a znovupoužitelných komponent.

To je obzvlášť důležité u vlastního vývoje pro WordPress, kde by kód neměl existovat pouze jako anonymní změna na produkčním serveru.

Mohu verzovat změny v:

• PHP,
• JavaScriptu,
• CSS,
• vlastních pluginech,
• tématech,
• konfiguraci,
• aplikačně specifické funkcionalitě.

To poskytuje výrazně bezpečnější workflow než úpravy produkčního kódu bez historie vývoje.

Git a backendový vývoj

Ze správy verzí výrazně těží také backendové aplikace.

Git používám pro správu:

• Python aplikací,
• API,
• kódu souvisejícího s databázemi,
• Docker konfigurace,
• deployment skriptů,
• šablon prostředí.

Kód a definice infrastruktury se tak mohou vyvíjet společně.

Git a Docker

Docker konfigurace přirozeně patří do správy verzí.

Dockerfiles, Compose definice a související konfigurace lze ukládat společně s aplikačním kódem.

Repozitář tak popisuje nejen to, jak software funguje, ale také jak je sestaveno jeho běhové prostředí.

V kombinaci s Git tagy to může pomoci reprodukovat prostředí spojené s konkrétním releasem.

Ignorování generovaných a citlivých souborů

Ne vše, co se nachází ve vývojovém adresáři, patří do Gitu.

Pravidla .gitignore používám k vyloučení souborů, jako jsou:

• výstupy buildu,
• dočasné soubory,
• lokální cache,
• generované závislosti,
• data specifická pro IDE tam, kde nejsou vhodná,
• lokální konfigurace prostředí.

Citlivé údaje, jako jsou API klíče, hesla a produkční přihlašovací údaje, by neměly být commitovány do repozitáře.

Citlivou konfiguraci držím mimo správu verzí a používám místo toho vhodné mechanismy pro práci s prostředím nebo secrets.

Bezpečnost repozitáře

Git repozitář může zachovat smazaný obsah ve své historii, takže omylem commitnutý secret je vážnější problém než pouhé smazání souboru v pozdějším commitu.

Přihlašovací údaje proto od začátku považuji za externí konfiguraci.

Pokud dojde k odhalení citlivých údajů, správným postupem je zpravidla daný credential zneplatnit nebo rotovat, nikoli předpokládat, že jeho odstranění z aktuální verze repozitáře problém vyřeší.

Dokumentace

Repozitář by měl být srozumitelný i mimo počítač, na kterém vznikl.

U vhodných projektů udržuji dokumentaci zahrnující například:

• účel projektu,
• instalaci a nastavení,
• závislosti,
• vývojové příkazy,
• deployment,
• důležité poznámky k architektuře.

Kvalitní README může výrazně zkrátit dobu potřebnou k pochopení projektu nebo k návratu k němu po delší době.

Struktura repozitáře

Preferuji předvídatelnou strukturu projektů.

Zdrojový kód, konfigurace, dokumentace a generované soubory by měly mít jasně definované role.

Dobře organizovaný repozitář usnadňuje:

• orientaci v projektu,
• zapojení dalšího vývojáře,
• automatizaci buildů,
• diagnostiku problémů,
• pozdější údržbu softwaru.

Struktura repozitáře je proto součástí udržovatelnosti, nikoli jen kosmetické rozhodnutí.

Práce s existujícími codebases

Git je mimořádně hodnotný při práci s existujícím projektem.

Před provedením změny mohu zkontrolovat:

• předchozí commity,
• branches,
• blame historii,
• tagy,
• historii releases.

To poskytuje kontext, který nemusí být patrný pouze z aktuálního kódu.

Pochopení toho, proč kód existuje, bývá často stejně důležité jako pochopení toho, co aktuálně dělá.

Bezpečný refaktoring

Správa verzí zvyšuje bezpečnost větších refaktoringových změn.

Kód mohu restrukturalizovat postupně a přitom zachovat známé funkční stavy.

Pokud se nový přístup ukáže jako horší, mohu jej porovnat s předchozí implementací nebo relevantní změny vrátit zpět.

Experimentování je díky tomu výrazně méně rizikové.

Debugging regresí

Pokud určitá funkce dříve fungovala a později se rozbila, historie Gitu může pomoci určit, kdy byla regrese zavedena.

Porovnáváním revizí lze problém zúžit na konkrétní sadu změn.

U obtížných případů mohou nástroje historie Gitu ušetřit výrazně více času než debugging současného kódu bez historického kontextu.

Spolupráce

Git a GitHub poskytují sdílenou technickou historii v případech, kdy na projektu pracuje více vývojářů.

Namísto ručního předávání upravených souborů mohou přispěvatelé pracovat s:

• branches,
• commity,
• pull requests,
• reviews,
• issues.

Všichni mohou vidět, jak se projekt vyvíjel a které změny jsou aktuálně navrhovány.

To výrazně snižuje nejednoznačnost při týmovém vývoji.

Vývoj s podporou AI a Git

Správa verzí je ještě důležitější v případech, kdy je součástí workflow vývoj podporovaný AI.

AI může rychle generovat nebo upravovat velké množství kódu, ale tyto změny je stále potřeba kontrolovat a validovat.

Git používám jako důležitou bezpečnostní vrstvu kolem vývoje podporovaného AI.

Umožňuje mi:

• kontrolovat přesné změny,
• porovnávat generovaný kód s předchozí implementací,
• izolovat experimenty,
• vracet neúspěšné změny,
• testovat změny před jejich mergem.

Rychlé generování kódu by nemělo znamenat nekontrolované změny v codebase.

Historie Gitu jako znalost projektu

V průběhu času se z repozitáře stává něco víc než jen kopie aktuálního zdrojového kódu.

Stává se záznamem o tom, jak se aplikace vyvíjela.

Tato historie může odpovídat na otázky typu:

• Proč byla zvolena tato architektura?
• Kdy se toto chování změnilo?
• Který release přidal tuto funkci?
• Jak vypadala předchozí implementace?
• Které změny byly provedeny společně?

Udržování této historie přináší projektu dlouhodobou hodnotu.

Záloha není správa verzí

Git poskytuje také určitou míru redundance, zejména pokud jsou repozitáře uloženy vzdáleně, ale nepovažuji jej za kompletní zálohovací strategii.

Repozitáře chrání především historii zdrojového kódu.

Produkční databáze, nahrané soubory, generovaný obsah a další aplikační data vyžadují vlastní odpovídající zálohovací systémy.

Oddělení těchto odpovědností zabraňuje falešnému pocitu bezpečí ohledně možnosti obnovy.

Git & GitHub v mém technologickém stacku

Git a GitHub používám společně s technologiemi, jako jsou:

• JavaScript,
• TypeScript,
• PHP,
• Python,
• Kotlin,
• Android,
• C++,
• Qt,
• Docker,
• Linux,
• PostgreSQL,
• WordPress,
• CI/CD.

Poskytují vrstvu správy verzí a spolupráce, která propojuje jinak velmi odlišná vývojová prostředí.

Proč používám Git & GitHub

Git a GitHub používám proto, že spolehlivý vývoj softwaru vyžaduje víc než jen napsat kód, který funguje dnes.

Projekt potřebuje historii, jasně identifikovatelná vydání, bezpečný prostor pro experimentování a přehledný způsob, jak chápat jeho změny v čase.

Git poskytuje tuto technickou historii.

GitHub kolem ní staví spolupráci, automatizaci a správu projektu.

Společně mi poskytují vývojové workflow, ve kterém jsou změny dohledatelné, vratné a snadněji ověřitelné — vlastnosti, které jsou s růstem a dalším vývojem projektu stále důležitější.