Git – poznámky

Poznámky k používání Gitu vypsané z knihy „Pro Git“ od Scotta Chacona, která je volně dostupná v edici http://knihy.nic.cz/.

Git

  • je distribuovaný systém správy verzí (DVCS = Distributed
    Version Control System)
  • při checkoutu na lokální kopii uchovává kompletní kopii repozitáře (lokální kopie je plnohodnotnou zálohou dat) + většinou se pro činnost Gitu vyžadují pouze lokální soubory => rychlost
  • nabízí systém větvení pro nelineární způsob větvení
  • ukládá změny jako snímky (snapshots) – zapíše, jak vypadají všechny soubory v okamžiku uložení stavu (Subversion ukládá seznam změn jednotlivých souborů) => rychlost procházení historie, sestavování změn
  • seznam hostingů pro Git https://git.wiki.kernel.org/index.php/GitHosting
    • u hostingů bývají repozitáře pod konkrétním uživatelem a nelze je přenést, např. na GitHubu proto možnost „fork“, která vytvoří kopii pro jiného uživatele (kam může odesílat), správce výchozího projektu pak má možnost přidat vzdálený (nový) repositář a začlenit případné změny do původního projktu

Git nastavení

  • globální config – na Windows v C:\Users\{user}\.gitconfig
  • kontrola nastavení

Základní používání

  • inicializace ve složce existujícího projektu (vytvoření .git adresáře, přidání souborů k verzování a první commit -m <komentář commitu>, -a všechny změny u sledovaných souborů)
  •  kopie existujícího repozitáře
  • kontrola stavu jednotlivých souborů (např. při změně souboru bude soubor vypsán jako „Changed but not updated“ => před commitem je potřbe tento soubor do commitu přidat pomocí add)

    podrobnější výpis
  • .gitignore – soubor obsahující masky neverzovaných souborů

    Hvězdička (*) označuje žádný nebo více znaků; [abc] označuje jakýkoli znak uvedený v závorkách (v tomto případě a, b nebo c); otazník (?) označuje jeden znak; znaky v závorkách oddělené pomlčkou ([0-9]) označují jakýkoli znak v daném rozmezí

  • odstranění souboru

  • přesunutí soubor

  • zobrazení historie revizí (zobrazí poslední 2 záznamy, podrobně, souhrnná statistika revize, kratší zápis = „hlavička“ na jeden řádek, „grafické“ zobrazení větví)

    u výpisu je možné nastavit celý formát výpisu pomocí

    parametry formátu jsou v knize na stránce 42

  • změna posledního commitu

  • rušení změn
    • git reset HEAD {soubor}  vrátí soubor z commitu
    • git checkout -- {soubor}  vrátí změny v souboru
  • Zahodit změny

    • pokud by se příkaz použil k návratu např. o 2 revize zpět, ty by se „ztratily“ (viz kapitola 9.7.2)
      • git log -g  získání lepšího logu pro reflog
        • pokud tento příkaz nevypíše hledanou revizi, lze použít příkaz  git fsck --full, který vypíše objekty, na které neukazuje žádný objekt (fsck – kontrola integrity)
      • git branch recover-branch ab1afef  obnovení revize do větve „recover-branch“ podle hashe z výpis
  • git umožňuje pracovat s několika vzdálenými repozitáři (origin je označení repozitáře) – přejmenování repozitáře origin na origin2
  • značky – tagy
    • prosté (v podstatě jen kontrolní součet v souboru)
    • anotované (obsahují kontrolní součet, autor, vlastní zprávu)
    • tagy se neodesílají automaticky, je potřeba jejich odeslání vynutit
    • git tag -a {tag name} b81ddf9  vytvoření tagu na konkrétní commit
  • vypsání tagů
    • git tag  seznam tagů
    • git show
    • git tag -n1  -n{počet řádek z anotace}

Větvení

  • výchozím názvem větve je master
  • vytvoření nové větve: git branch nova_vetev_nazev (bez přepnutí se na ni)
    • git branch  vypíše všechny větve a před aktivní dá hvězdičku

    • seznam začleněných a nezačleněných větví do větve aktuální
  • aktuální větev je označena ukazatelem HEAD
  • přepnutí se na jinou větev git checkout nova_vetev_nazev
  • přepnutí na hlavní větev a sloučení s vedlejší
    • git checkout master  přepnutí se na hlavní větev
    • git merge nova_vetev_nazev  přidání změn do aktuálně aktivní větve
  • slučování (začlenění)
    • Fast forward – pokud se slučujou 2 větve a ze starší větve se lze do nové větve dostat sledováním historie (neexistuje rozdílná práce – konflikty), př. z větve v1 vytvořím novou v2, kam se přidají nové soubory a mezitím se v1 nemění – sloučením pak jen Git posune ukazatel na novější větev
    • Merge commit – revize sloučením – třícestné sloučení (společný předek větví, a konečný stav každé větve) – Git sám vybere nejvhodnějšího předka, ke kterému se provede sloučení a vznikne nový snímek (stav)
    • přeskládání (rebase) – další možnost začlenění změn
      • pomocí příkazu  git rebase  se vezmou všechny změny provedené na dané větvi a nechají se znovu provést na jiné
      • příkaz najde společného předka obou větví,provede diff na všechny revize aktuální větve, dočastně uloží rozdíly, vrátí aktuální větev na stejnou revizi jako větev na kterou se přeskakuje a aplikuje postupně změny
      • příkaz ke sloučení do hlavní větve lze použít i na větev, která vyšla s jiné větve, která vyšla z hlavní
      • přeskákání se nesmí provádět u revizí, které již byly odeslány do veřejného repozitáře – vede to k problémům (je to k vyčištění a práci s revizemi než se odešlou)
  • smazání sloučené větve git branch -d nova_vetev_nazev (smazání neproběhne, pokud se jedná o větev, která ještě nebyla začleněna do aktuální větve, pro smazání takové větve je potřeba parametr -D)
  • na rozdíl např. od SVN je potřeba provést manuální sloučení i v případě, že se mění různé soubory
  • aplikování změn do jiné větve

    • cherry-pick – natažená změna bude mít jiný sha1
  • konflikty při slučování (strana 70) – pokud dojde ke konfliktu, lze použít grafický nástroj  git mergetool
    • v kapitole 7 je návod na nastavení externího nástroje P4Merge
  • git merge --no-commit --squash zaclenena_vetev   příkaz vezme všechny změny z ještě nezačleněné větve a zakomprimuje je do jedné revize
  • možnosti při práci s větvemi
    • dlouhé větve – průběžné začleňování změn z různých větví do jedné hlavní (strana 73)
    • tematické větve – krátkodobá větev, založena pro konkrétní úkol
    • vzdálené větve – větve a jejich stavy na vzdálených repozitářích
      • odeslání větve   git push (server) (větev)
      • vyzvednutí větve git pull
      • vyzvednutí změn na větvi  git fetch origin
      • je možné nastavit sledování i jen jiné než hlavní větve

Protokoly pro Git

  • local – pokud je přístup ke sdíleným souborům
  • ssh
  • Git – port 9418, poskytuje podobnou službu jako SSH, ale bez ověřování; většinou používán bez možnosti odesílat revize
  • HTTP/S (přes http lze i odesílat, WebDAV)

Doplňky

  • GitWeb – jednoduchá online vizualizace
  • Gitosis – sada skriptů k usnadnění práce s authorized_keys
  • Gitolite – možnost nastavení doplňujících přístupových práv jen na určité značky a větve
  • Démon Git – pro protokol Git (pro vyšší rychlost než u HTTP)

Pracovní postupy

  • centralizovaný – společný repozitář, kam všichni nahrávají
  • integrační manažer – (GitHub) – společný repozitář jen pro čtení, přispěvatelé mají své repozitáře a z nich správce společného repozitáře provádí začlenění
    • žádost o začlenění  git request-pull – příkaz sestaví seznam změn pro požadovanou větev na základě změn u přispěvatele – lze poslat správci, aby věděl co je požadováno změnit, kde to vzít,…
    • změnu je možné zaslat např. i přes mail pomocí git format-patch -M origin/master
  • diktátor a poručíci – varianta postupu s více repozitáři, poručíci začleňují změny na úrovni konkrétních částí repozitáře a diktátor je pak jejich společný integrátor

Nástroje systému Git

  • odložení změn git stash 
    • git stash list  seznam odložených změn
    • git stash apply {konkretni_odklad_podle_seznamu}  aplikace změn (bez parametru, který určí kterou změnu aplikovat se aplikuje ta poslední), parametr –index pak aplikuje změny i na soubory připravené k zapsání
    • git stash drop {konkretni_odklad}  odstranění odkladu
    • git stash show -p stash@{0} | git apply -R  vezme zpět změny z odkladu
    • git stash branch  vezme aktuální větev a vytvoří z ní novou, do které aplikuje odloženou změnu
  • přepis historie – dokud nejsou revize sdílené s ostatními, je možné měnit pořadí revizí, zprávy, soubory v revizích, emailové adresy, …
    • git commit --amend  pro změnu poslední revize
    • git rebase -i HEAD~3  pro hlubší změnu (upravení 3 posledních revizí)
    • odstranění souboru ze všech revizí (např. soubor zapsaný omylem) git filter-branch --tree-filter 'rm -f passwords.txt' HEAD s parametrem –all se spustí na všech větvích
      • možnost odstranění souboru po sdílení je popsaná v kapitole 9.7.3
  • Anotace souboru git blame
    • lze vypsat, u všech řádků souboru, kdy byly změněny a kým
    • s parametrem -C lze navíc zjistit z jakého souboru řádky pocházejí (Git může zjistit, z jakých souborů byly části kódu přesunuty)
  • Binární vyhledávání – lze vyhledat chybu která se vyskytuje např. kdesi mezi posledními 12 revizemi
    • git bisect start|bad|good
      • zahájení hledání
      • zadání kdy již kód nefunguje
      • zadání revize, kdy byl kód ještě funkční
    • mezi dobrou a špatnou revizí se vybere prostřední revize a nechá se otestovat (vyzkoušet kód – ručně, testem,…)
      • pokud zde není problém zadá se git bisect good  a git pokračuje v hledání (rozdělí mezi aktuálně vyzkoušenou revizí a chybnou)
      • po nalezení chybné revize se vloží git bisect bad  git vrátí informace co je to za revizi a jaké jsou v ní změny
    • po ukončení hledání je vhodné se vrátit do jednoznačného stavu git bisect reset
  • Submoduly – pro řešení stavu, kdy je potřeba vložit do repozitáře knihovnu, která má svůj repozitář (a ten zachovat, aby šlo udržovat knihovnu aktuální)
    • naklonování repozitáře  git submodule add git://github.com/chneukirchen/rack.git rack
    • při klonování repozitáře, který obsahuje submoduly, je potřeba tyto submoduly po naklonování stáhnout
    • při stažení změn v submodulu je potřeba provést update git submodule update  pokud submodul obsahoval lokální neodeslané změny – můžou „zmizet“
    • ve složce submodulu se pracuje podobně jako v hlavní složce repozitáře – tj. git push/pull … v hlavní složce se pak zapíše  git fetch {submodul}  a provede zapsání, aby se změnil ukazatel na aktuální verzi revize submodulu
    • podrobněji a lépe je to popsané v knize v podkapitole „Submoduly“

Další nastavení

  • je možné nastavit strategii pro slučování, např. pro konkrétní lze nastavit, že se při kolizi vezme vždy vaše verze
  • je možné vybrané soubory označit jako binární a nastavit pro ně speciální instrukce, jak s nimi nakládat
    • vnutit jim, že se je Git nebude pokoušet konvertovat nebo opravovat chyby CRLF
    • nastavit jim jak se mají zpracovat pro nástroj diff, např.
      • jak otevřít a porovnat soubory wordu (získání textu z .doc)
      • jak otevřít a porovnat obrázkové soubory (vypsáním exif)

Zásuvné moduly

  • spouštění uživatelských skriptů při určité akci
  • zásuvné moduly se naklonováním projektu nenakopírují (pokud nejsou v něm) a automaticky se nenastaví
  • moduly jsou
    • na straně klienta – možnost kontroly odesílaného snímku, k zakázání přeskládání odeslaných revizí,…
    • na straně serveru – ověření práv odesílajícího uživatele k měněným souborům,…

 Git a Subversion

  • nástroj git svn umožňuje používat Git jako klienta pro Subversion, na straně uživatele je tak možné používat např. větvení, přeskládávání
  • git svn clone  importování svn repozitáře do lokálního git repozitáře
  • na jednom projektu by se nemělo (je nevhodné) používat serveru Subversion v kombinaci s vzdálenými repozitáři Gitu (odeslání na svn server mění kontrolní SHA-1 revizí)
  • je potřeba pamatovat rozdíl:
    • Git vyžaduje před odesláním dat začlenění práce, která ještě lokálně není stažena (nové revize, když někdo commitne dříve)
    • Svn si začlenění vyžádá jen v případě případné kolize (ne pokud byl v předchozí verzi nahrán např. nový soubor)
    • => před odesláním  git svn rebase
  • git svn show-ignore  zobrazí záznamy o ignorovaných souborech pro přidání do .gitignore (nebo git svn create-ignore  automaticky vytvoří .gitignore)
  • v knize v kapitole 8.2 je popsán postup pro přesun ze Subversion (nebo Perforce) na git
  • pro přechod na Git je možné vytvořit vlastní importér
Share
Příspěvek byl publikován v rubrice Nezařazené se štítky , . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

*