Blob Blame History Raw
<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="version-control" xml:lang="cs">

  <info>
    <link type="guide" xref="index#general-guidelines"/>

    <credit type="author copyright">
      <name>Philip Withnall</name>
      <email its:translate="no">philip.withnall@collabora.co.uk</email>
      <years>2015</years>
    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>Správa verzí zdrojového kódu pomocí git</desc>
  </info>

  <title>Správa verzí</title>

  <synopsis>
    <title>Shrnutí</title>

    <p>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 <link href="https://www.atlassian.com/git/tutorials/">zde</link> a <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">přehledný tahák zde</link>. V češtině je volně k dispozici <link href="https://knihy.nic.cz/">překlad knihy Pro Git</link>.</p>

    <list>
      <item><p>Vytvářejte atomická zařazení, která jdou vzít zpět. (<link xref="#guidelines-for-making-commits"/>)</p></item>
      <item><p>Do zprávy k zařazení uveďte jeho plný důvod, plus odkazy na příslušná chybová hlášení nebo specifikace. (<link xref="#guidelines-for-making-commits"/>)</p></item>
      <item><p>Rozsáhlé změny, jako třeba přejmenování, zařazujte zvlášť. (<link xref="#guidelines-for-making-commits"/>)</p></item>
      <item><p>Slučujte změny z větví pro nové funkce pomocí přeskládání. (<link xref="#use-of-git"/>)</p></item>
    </list>
  </synopsis>

  <section id="use-of-git">
    <title>Používání správy verzí Git</title>

    <p>Většina repozitářů GNOME dodržuje tato následující pravidla:</p>
    <list>
      <item><p>Nepoužívejte nahrávání s parametrem „force“. Vyjma větví s prefixem <code>wip/</code> (work-in-progres) pro rozpracované věci, se nesmí historie zařazení měnit, protože přispěvatelé na ni spoléhají.</p></item>
      <item><p>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í).</p></item>
      <item><p>Větve, ve kterých pracujete na nových funkcích GNOME, umisťujte v Gitu do větve <code>wip/</code>, 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 <code>wip/prezdivka/funkce</code>.</p></item>
      <item><p>Před sloučením skryjte <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">vytvořený guláš</link> pomocí komprimace (squash).</p></item>
    </list>
  </section>

  <section id="guidelines-for-making-commits">
    <title>Pokyny pro vytváření zařazení</title>

    <p>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 <cmd>git log --oneline</cmd>), aby bylo jednoduché obě věci navzájem dohledat.</p>

    <p>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ě.</p>

    <p>Důvodem pro všechny uvedené rady jsou následující principy:</p>
    <list>
      <item><p>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í <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">binárního vyhledávání příkazem bisect</link>.</p></item>
      <item><p>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 <cmd>git revert <var>ID zařazení</var></cmd> převést repozitář z jednoho plně funkčního stavu do jiného plně funkčního stavu.</p></item>
      <item><p>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í.</p></item>
      <item><p>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.</p></item>
    </list>
  </section>

  <section id="merging-procedure">
    <title>Slučovací procedura</title>

    <p>Pro sloučení větve s novou funkcionalitou, pojmenované <code>my-branch</code>, do hlavní větve použijte následující příkazy:</p>
    <code mime="application/x-shellscript">
git checkout master
git pull

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

git checkout master
git merge wip/<var>my-branch</var>
git push

# wip/<var>my-branch</var> lze nyní smazat
git push origin :wip/<var>my-branch</var>
git branch -D wip/<var>my-branch</var></code>
  </section>

  <section id="external-links">
    <title>Externí odkazy</title>

    <list>
      <item><p><link href="https://sethrobertson.github.io/GitBestPractices/">Git best practices</link></p></item>
      <item><p><link href="https://help.github.com/categories/using-git/">Git FAQ</link></p></item>
      <item><p><link href="https://www.atlassian.com/git/tutorials/">Atlassian git tutorial</link></p></item>
      <item><p><link href="http://git-scm.com/docs/gittutorial">Official git tutorial</link></p></item>
      <item><p><link href="https://try.github.io/">Interactive git tutorial</link></p></item>
      <item><p><link href="http://www.git-tower.com/learn/">git-tower tutorial</link></p></item>
    </list>
  </section>
</page>