Philip Withnall
philip.withnall@collabora.co.uk 2015
Správa verzí zdrojového kódu pomocí git

# Správa verzí

#

        Shrnutí

        Pro správu verzí se u všech projektů GNOME používá Git. Tato stránka předpokládá dobrou znalost práce se systémem git. Materiály pro úvod do této problematiky najdete zde a přehledný tahák zde. V češtině je volně k dispozici překlad knihy Pro Git.

          Vytvářejte atomická zařazení, která jdou vzít zpět. ()
          Do zprávy k zařazení uveďte jeho plný důvod, plus odkazy na příslušná chybová hlášení nebo specifikace. ()
          Rozsáhlé změny, jako třeba přejmenování, zařazujte zvlášť. ()
          Slučujte změny z větví pro nové funkce pomocí přeskládání. ()

# Používání správy verzí Git

Většina repozitářů GNOME dodržuje tato následující pravidla:

Nepoužívejte nahrávání s parametrem „force“. Vyjma větví s prefixem `wip/` (work-in-progres) pro rozpracované věci, se nesmí historie zařazení měnit, protože přispěvatelé na ni spoléhají.

Používejte přeskládání (rebase) místo slučování (merge), aby historie byla lineární (je to přehlednější pro sledování).

Větve, ve kterých pracujete na nových funkcích GNOME, umisťujte v Gitu do větve `wip/`, pak přeskládejte hlavní větev a změny slučte rychle vpřed (fast-forward merge). Je také dobrým zvykem přidat do názvu větve svoji přezdívku, nějak jako `wip/prezdivka/funkce`.

Před sloučením skryjte vytvořený guláš pomocí komprimace (squash).

# Pokyny pro vytváření zařazení

Jednotlivá zařazení by měla být co nejmenší je rozumné, ale ne menší. Každé zařazení se má zabývat jediným problémem a obsahovat jen změny vztahující se k tomuto problému. Zpráva u jednotlivých zařazení by pak měla obsahovat popis onoho problému, vysvětlit co způsobuje a vysvětlit jak byl opraven, pokud to není očividné. Pokud se k problému vztahuje chybové hlášení, měla by se na konec zprávy na samostatný řádek vložit úplná adresa URI tohoto hlášení. A naopak, do chybového hlášení by se mělo nakopírovat ID zařazení (z git log --oneline), aby bylo jednoduché obě věci navzájem dohledat.

Změny v jednotlivých zařazeních by měly být snadno čitelné. Například by neměly obsahovat samoúčelné změny v bílých znacích nebo odsazení. Rozsáhlé mechanické změny, jako je přejmenování souborů nebo funkcí, by měly být v samostatném zařazení, odděleně od změn v kódu v souboru nebo funkci, takže pozdější změny někam nezapadnou a nebudou ztraceny v prvním jmenovaném případě.

Důvodem pro všechny uvedené rady jsou následující principy:

Každé zařazení by mělo dostat repozitář z jednoho plně funkčního stavu do dalšího plně funkčního stavu, jinak znemožníte použití binárního vyhledávání příkazem bisect.

Každé zařazení by mělo jít samostatně vzít zpět. Když se později zjistí, že zařazení nebylo dobrým nápadem, měl by příkaz git revert ID zařazení převést repozitář z jednoho plně funkčního stavu do jiného plně funkčního stavu.

Důvod každého zařazení a jeho vztah k externím prostředkům, jako je zadání nebo nahlášená chyba, by měly být jasné do té míry, že zařazení, které napsal jeden vývojář před rokem, pochopí hned i jiný vývojář, bez zdlouhavého procházení změn a studování, co dělají.

Každé zařazení by mělo být napsáno jednou naráz, ale navrženo s tím, že čteno může být nesčetněkrát, mnoha lidmi provádějícimi kontrolu a budoucími programátory.

# Slučovací procedura

Pro sloučení větve s novou funkcionalitou, pojmenované `my-branch`, do hlavní větve použijte následující příkazy:

git checkout master git pull

git checkout wip/my-branch git rebase --interactive master # Kontrola úspěšnosti přeskládání, test změn

git checkout master git merge wip/my-branch git push

# wip/my-branch lze nyní smazat git push origin :wip/my-branch git branch -D wip/my-branch

# Externí odkazy

Git best practices

Git FAQ

Atlassian git tutorial

Official git tutorial

Interactive git tutorial

git-tower tutorial