5. 
Git
Řada 2.x vanilkové příchuti Linuxu: Knihy kouzel je od 15. července 2022
do 1. března 2025 ve stavu dlouhodobé pasivní údržby;
nahlášené chyby budou opravovány, ale aktivní vývoj se již věnuje jiným
projektům. Máte-li zájem pokračovat v tvorbě Linuxu: Knihy kouzel
pro novější verze linuxových operačních systémů,
kontaktujte autora nebo rovnou vytvořte odnož.
1. Úvod
Git je široce používaný systém správy verzí. Je používán k verzování zdrojových kódů nebo jiných skupin textových souborů. Umožňuje snadný přístup do historie verzovaných souborů a slučování změn provedených odděleně, často mnoha různými uživateli.
Příklad architektury repozitářů v Gitu:
Tato verze kapitoly nepokrývá práci s podrepozitáři (submodules). Příkaz „git stash“ je pokryt částečně, příkaz „git rebase -i“ pokryt není.
2. Definice
2/1 Základní definice
- Pracovní adresář (PA) je adresář, který obsahuje soubory verzované Gitem v otevřené podobě, abyste s nimi mohli přímo pracovat. Vždy přísluší k určitému místnímu repozitáři.
- Ke každému PA příluší jedna přípravná oblast (PO, anglicky „staging area“ či „index“), což je skrytá oblast, ve které přenášením změn z PA vzniká nová revize.
- Revize je konkrétní neměnný (historický) stav verzovaných souborů v PA, označený a doplněný o další údaje (zejména datum, čas, komentář a označení přispěvatele).
- Když do repozitáře vložíte novou revizi, předchozí revize se stane rodičem nově vložené revize. Většina revizí má jednoho rodiče; výjimkou jsou kořenové revize, které nemají žádné rodiče, a revize vzniklé slučováním změn („spojováním vývojových větví“), které mají obvykle dva rodiče (vzácně i víc).
- Předkové revize X jsou její rodiče, rodiče rodičů a tak dále. Nejbližší společný předek (NSP) dvou revizí je: 1) Pokud je jedna z revizí předkem té druhé, pak je NSP ona. 2) Jinak je NSP, pokud existuje, taková revize, která je společným předkem obou revizí, ale není rodičem žádné revize, která by společným předkem obou revizí byla také.
- Větev (branch) je v Gitu proměnný odkaz na (nejnovější) revizi. Když vytvoříte novou revizi, aktivní větev se automaticky nastaví tak, aby na tuto novou revizi odkazovala. Můžete mít mnoho různých větví, každou nechat odrážet jiný směr vývoje a přepínat se mezi nimi.
- Jméno revize (tag) je trvalé a neměnné symbolické označení určité revize v repozitáři (něco jako konstanta). Obvykle se používá k označení význačných revizí, např. těch, ze kterých vznikla vydaná verze softwaru.
- Aktivní větev je pro daný PA větev, která do něj byla naposledy načtena a k níž je připojen – to znamená, že nově vzniklé revize budou do dané větve přiřazovány. Pokud je PA odpojený od větve, má místo aktivní větve pouze aktivní revizi. Aktivní větev (případně aktivní revize) se symbolicky označuje HEAD.
- Vzdálená větev není větev ve výše uvedeném významu, ale jde o kopii větve ze vzdáleného repozitáře v místním repozitáři, která je aktualizována příkazem „git fetch“ nebo „git pull“.
2/2 Druhy repozitářů
Repozitář je úložiště revizí. V Gitu se setkáte se třemi druhy repozitářů:
- Místní repozitář je nejčastější. Může spolupracovat se vzdálenými repozitáři a má k sobě vždy jeden hlavní PA; můžete k němu vytvářet také vedlejší PA. Místní repozitář může sloužit jako vzdálený repozitář jiného místního repozitáře, ale pouze ke čtení – nelze do něj odesílat.
- Holý repozitář nemá vlastní pracovní adresáře; slouží především v roli vzdáleného repozitáře pro místní repozitáře.
- Máte-li místní repozitář, jako vzdálené repozitáře se označují oddělené repozitáře, ke kterým je místní repozitář připojen a může z nich čerpat revize a větve, případně je do nich i odesílat. Vzdálené repozitáře se mohou nacházet v místním souborovém systému nebo být dostupné přes síť a samy o sobě to mohou být holé nebo (méně často) místní repozitáře.
2/3 Označení revize
V Gitu se používá několik způsobů, jak můžete v příkazech označovat jednotlivé revize:
- Úplná SHA-1 heš je vhodná pouze ve skriptech, na ruční použití je nepraktická.
- Jednoznačná předpona heše je vhodná pro ruční použití; v malých projektech obvykle stačí první tři znaky, ve velkých pět nebo šest. Pokud předpona není jednoznačná, Git ohlásí chybu.
- Symbolické označení, např. název větve, jméno revize nebo „HEAD“.
Za jakýmkoliv označením revize můžete (i opakovaně a v kombinaci) použít tyto dva operátory:
- Stříška „^“ znamená přechod na rodiče revize, takže např. „HEAD^^“ znamená rodič rodiče aktivní revize. Pro přechod na jiného než prvního rodiče zadejte za stříšku číslo, takže např. „HEAD^2“ znamená přechod na druhého rodiče aktivní revize.
- Tilda (např. „\~2“) znamená N opakování operátoru „^“. Např. „\~3“ je zkratka za „^^^“, tedy rodič rodiče rodiče revize. (Zpětné lomítko se zde používá kvůli odzvláštnění v bashi; alternativní možností je uzavření označení revize do uvozovek, např. „"HEAD~2"“.)
3. Zaklínadla: Revize, větve a změny
3/1 Informace o stavu PO a PA
@běžné informace pro člověka#1
git status [-bs] [--ignored]
@změny v PA oproti HEAD/v PA oproti PO/v PO oproti HEAD#2
git diff [--name-status] HEAD [-- soubor-nebo-adresář]
git diff [--name-status] [-- soubor-nebo-adresář]
git diff [--name-status] --cached [-- soubor-nebo-adresář]
git log [--pretty=formát] [-n maximální-počet-revizí] [revize]
@historie předků, ve kterých došlo ke změně v některém z uvedených souborů#4
git log [--pretty=formát] [-n maximální-počet-revizí] [revize] -- soubor-nebo-adresář
@historie v určitém rozsahu revizí#5
git log [--pretty=formát] ^nejstarší-revize^@ nejnovější-revize
3/2 Větve (ne vzdálené)
git checkout -b nová-větev [revize]
git branch nová-větev [revize]
@seznam větví (pro člověka/pro skript)#3
git branch
git branch --no-column --format '%(refname:lstrip=2)'
git reset --soft revize
git branch -f větev revize
@přejmenovat větev#5
git branch -m starý-název nový-název
git checkout --orphan && git rm -Rf . && git commit --allow-empty -m 'kořenová revize'
3/3 Aktivní větev/revize
git checkout větev
git checkout --detach && git reset --soft větev && git checkout větev
@název aktivní větve#2
git branch --show-current
@odpojit se od aktivní větve#3
git checkout --detach
@heš aktivní revize#4
git rev-parse --verify HEAD
@je některá větev aktivní?#5
git branch --show-current | egrep -q .
3/4 Z PA do PO a z PO do repozitáře
git commit -a[S] [-m 'komentář']
@odeslat změny PA do PO; neverzované soubory zahrnout jako přidané/ignorovat#2
git add -A
git add -u
git add [-u] [--] soubor-nebo-adresář
@vytvořit novou revizi z PO (a nastavit na ni aktivní větev)#4
git commit [-m komentář] [-a] [-S] [--allow-empty]
@smazat soubor z PO i PA/jen z PO#6
git rm [-f] [-r] [[--] soubor-či-adresář]
git rm --cached [-f] [-r] [[--] soubor-či-adresář]
@přesunout soubor/více souborů v PA i PO#7
git mv původní-cesta nová-cesta
git mv zdroj cílový-adresář
3/5 Z repozitáře do PO a PA
git checkout revize
git checkout -b nová-větev [revize]
git checkout [revize] [--] soubor-nebo-adresář
git reset [revize] [--] soubor-nebo-adresář
@zrušit všechny změny oproti HEAD v PO a PA/jen v PO#3
git reset --hard
git reset
@načíst do PO a PA revizi, která byla nejnovější k určitému datu/před 14 dny#4
git checkout $(git rev-list -n 1 --first-parent "--until=datum-YYYY-MM-DD HH:mm:ss" HEAD)
git checkout $(git rev-list -n 1 --first-parent "--until=$(date -d "14 days ago" "+%F %T")" HEAD)
3/6 Přístup k revizím z repozitáře
@získat do samostatného nového adresáře konkrétní revizi#1
[rm -Rf cílový/adresář]
mkdir -p[v] cílový/adresář && git -C "$(git rev-parse --show-toplevel)" archive revize | tar x -C cílový/adresář
git archive revize [--] cesta/k/souboru | tar xO
@zabalit konkrétní revizi jako archiv typu zip#3
git -C "$(git rev-parse --show-toplevel)" archive --format=zip [-9] revize >výstup.zip
3/7 Jména revizí
@pojmenovat revizi#1
git tag nové-jméno [revize]
@seznam jmen revizí#2
git tag
3/8 Práce se změnami
git revert [--no-edit] [-n] revize
git revert [--no-edit] [-n] starší-revize..novější-revize
@přehrát změny z uvedených revizí v aktivní větvi (seznam revizí uvést/načíst)#3
git cherry-pick [-x] [-n] revize
zdroj | git cherry-pick --stdin [-x] [-n]
@zrušit slučování (nastal-li konflikt)#6
git merge --abort
3/9 Vzdálené větve
@stáhnout všechny novinky a sloučit vzdálené změny do aktivní větve/jen sloučit změny#1
git pull
git merge FETCH_HEAD
@odeslat změny v aktuální větvi (do napojené větve/a nastavit napojení)#2
git push
git push -u vzdálený-repozitář $(git branch --show-current)
@načíst vzdálenou větev do místní a přepnout se na ni#3
git checkout vzdálený-repozitář/vzdálená-větev
@seznam vzdálených větví (pro člověka/pro skript)#4
git branch -r
git branch -r --no-column --format '%(refname:lstrip=2)'
git rev-parse --abbrev-ref "HEAD@{upstream}" 2>/dev/null⊨ origin/vzdalena-vetev
@smazat větev ve vzdáleném repozitáři#6
git push vzdálený-repozitář :vzdálená-větev [:další-vzdálená-větev]
@vytvořit místní větev napojenou na existující vzdálenou větev (obecně/příklad)#7
git branch místní-název vzdálený-repozitář/vzdálená-větev
git branch moje-stabilni origin/stabilni
@odeslat do vzdáleného repozitáře jména revizí#8
git push vzdálený-repozitář jméno-revize
@nastavit/zrušit napojení místní větve na vzdálenou#9
git branch -u vzdálený-repozitář/vzdálená-větev místní-větev
git branch --unset-upstream místní-větev
@kam je napojená určitá větev?#10
git rev-parse --abbrev-ref "místní-větev@{upstream}" ["místní-větev@{upstream}"]
3/10 Vyhledávání revizí
@NSP#1
git merge-base revize další-revize
4. Zaklínadla: Pracovní adresáře a repozitáře
4/1 Analýza stavu
@vypsat rozdíly mezi dvěma revizemi#1
git diff [--name-status] revize1 revize2 [-- soubor-nebo-adresář]
@vypsat „pro člověka“ zpětnou historii předků aktuální revize (až po kořen/jen po první revizi dosažitelnou z „omezující-revize“)#2
git log [--pretty=formát] [-n maximální-počet-revizí] [revize]
git log [--pretty=formát] [-n maximální-počet-revizí] omezující-revize..revize
@úplná cesta k pracovnímu adresáři (aktuálnímu/hlavnímu)#3
git rev-parse --show-toplevel
git worktree list --porcelain | sed -E '2,$d;s/^worktree //'
@vypsat podrobné informace o revizi#4
git show revize
@vypsat (pro skript) seznam tvořený revizí a všemi jejími předky#5
git rev-list revize
@vypsat úplnou heš dané revize#6
git rev-list -n 1 revize
4/2 Vytvoření a konverze repozitáře (místní/holý)
@vytvořit nový repozitář v aktuálním adresáři (místní/holý)#1
git init [&& git checkout -b název_výchozí_větve]
git init --bare
git clone [--branch větev] vzdálená-adresa [místní-adresář]
@konverze holého repozitáře na místní#3
git -C repozitář config core.bare false
mv repozitář repozitář-git
mkdir repozitář
mv repozitář-git repozitář/.git
git -C repozitář reset --hard
@konverze místního repozitáře na holý#4
mv repozitář/.git repozitář-git
rm -R repozitář
mv repozitář-git repozitář
git -C repozitář config core.bare true
4/3 Vzdálený repozitář
@stáhnout všechny novinky do lokální kopie (1 repozitář/všechny)#1
git fetch [--tags] [vzdálený-repozitář]
git fetch --all [--tags]
@zjistit/změnit adresu#2
git remote get-url vzdálený-repozitář
git remote set-url vzdálený-repozitář "adresa"
@seznam vzdálených repozitářů (i pro skript)#3
git remote
@vypsat informace o vzdáleném repozitáři#4
git remote show -n vzdálený-repozitář
@přidat/odebrat#5
git remote add název "adresa"
git remote remove název
@přejmenovat#6
git remote rename původní-název nový-název
4/4 Vedlejší pracovní adresáře
@vypsat seznam#2
git worktree list [--porcelain]
@smazat#3
git worktree remove /sekundární/pracovní/adresář
@smazat všechny nedostupné sekundární pracovní adresáře#4
git worktree prune
@přesunout#5
git worktree move /sekundární/pracovní/adresář /nové/umístění
@zamknout/odemknout (zamknutý adresář se nesmaže příkazem „prune“)#6
git worktree lock [--reason důvod] /sekundární/pracovní/adresář
git worktree unlock /sekundární/pracovní/adresář
4/5 Odkládání a rušení změn v PA a PO
@odložit změny v PA a PO#1
git stash push -ku [-m "Popis"]
@smazat odložené změny#3
git stash clear
@vypsat odložené změny (jen poslední odložení)#4
git stash show -p
@vypsat seznam uložených odložení#5
git stash list
4/6 Ostatní
git clean -fd[i]
git clean -fdx[i]
5. Zaklínadla: Konfigurace a ostatní
5/1 Syntaxe v souboru .gitignore
@komentář#2
# [text do konce řádky]
@ignorovat všechny soubory a adresáře#3
*
5/2 Konfigurace obecně
@vypsat současnou hodnotu určitého klíče#1
git config [--global] --get klíč
@nastavit hodnotu určitého klíče#2
git config [--global] klíč "nová hodnota"
@vypsat celou konfiguraci (lokální/globální/globální a pod ní lokální)#3
git config --local -l
git config --global -l
git config -l
@vypsat platné konfigurační dvojice klíč=hodnota#4
git config -l | tac | awk -F = '/=/ && !($1 in A) {A[$1] = 1; print $0;}' | LC_ALL=C sort
@smazat určitý klíč#5
git config [--global] --unset klíč
@najít seznam podporovaných konfiguračních klíčů#6
git help config
Zadejte:
/^\s*Variables Enter
5/3 Konfigurace konkrétně
@v logu zobrazovat datum ve formátu YYYY-MM-DD HH:MM:SS +ZZZZ (např. „1970-12-31 23:59:59 +0700“)#1
git config [--global] log.date iso
@vypisovat ne-ASCII znaky v názvech souborů tak, jak jsou#2
git config [--global] core.quotePath false
git config [--global] credential.helper "cache --timeout=počet-sekund"
git config [--global] core.editor příkaz
5/4 Zkratky
@nastavit na příkaz Gitu/vnější příkaz#1
git config [--global] alias.podpříkaz 'příkaz-gitu [parametry]'
git config [--global] alias.podpříkaz '!příkaz[ parametry]'
@seznam (globálních/místních/právě platných)#2
git config --global -l | sed -E 's/^alias\.([^=]+)=.*$/\1/;t;d'
git config --local -l | sed -E 's/^alias\.([^=]+)=.*$/\1/;t;d'
git config -l | sed -E 's/^alias\.([^=]+)=.*$/\1/;t;d' | sort -u
@zrušit#4
git config [--global] --unset alias.podpříkaz
6. Parametry příkazů
git [globální parametry] příkaz [parametry příkazu]
| -C adresář | (globální parametr) Před vykonáním příkazu vstoupí do zadaného adresáře. |
git [globální parametry] commit [parametry]
| -a | Před vytvořením revize přenese do PO všechny změny a smazání verzovaných souborů v pracovním adresáři. Neverzované soubory nepřidává. |
| -m "komentář" | Použije k revizi uvedený komentář a neotevře editor. |
| --amend | Nahradí stávající aktivní revizi, přičemž nové revizi zůstane čas, označení přispěvatele a komentář z původní revize, pokud nepoužijete v kombinaci s parametrem „--reset-author“. |
| --allow-empty | Dovolí vložit novou revizi i v případě, že PO neobsahuje žádné změny oproti HEAD. |
| --no-edit | Potlačí vyvolání editoru k zadání komentáře ke commitu. |
git [globální parametry] add [parametry]
| -u | Přenese do indexu jen změny ve verzovaných souborech a jejich smazání, nepřidává nové soubory k verzování. |
| -v | Vypisuje provedené změny. |
7. Instalace na Ubuntu
sudo apt-get install git
git config --global user.name "vaše celé jméno"
git config --global user.email "váš e-mail"
Celé jméno a e-mail se používají k označení autorství revizí. Musíte je zadat z každého uživatelského účtu, kde budete Git používat, odmítne pracovat a vyzve vás k jejich nastavení. (Nemusíte je ovšem zadat pravdivě.) Globálně zadané hodnoty můžete pro jednotlivé repozitáře změnit.
8. Ukázka
@Příprava ukázkového adresáře a souborů#1
mkdir Projekt && cd Projekt
printf %s\\n "#!""/bin/bash" "cat text" > skript
chmod 755 skript
printf %s\\n "Toto je textový soubor" > text
@Tělo příkladu#2
git init
git add skript text
git commit -m "První verze"
printf %s\\n "Druhá řádka" >> text
git status
git commit -a -m "Přidána druhá řádka"
git log
@Druhá část příkladu#3
git checkout -b nova-vetev HEAD~1
printf %s\\n "Jiný druhý řádek" >> text
git commit -a -m "Alternativní verze"
git diff master nova-vetev
9. Tipy a zkušenosti
- Soubor .gitignore může být v každém podadresáři PA; jeho deklarace platí v adresáři, kde se nachází, a ve všech jeho podadresářích.
- Vytvoříte-li v podadresáři pracovního adresáře soubor „.gitignore“ obsahující jediný řádek „*“, git bude tento adresář a veškerý jeho další obsah zcela ignorovat. To je praktické, když chcete mít v pracovním adresáři podadresář, který nikdy nebudete chtít verzovat.
- Soubor „.gitignore“ se obvykle verzuje spolu s normálními soubory.
9/1 Slučování změn a řešení konfliktů
Příkaz „git merge revize“ najde NSP aktivní větve a zadané revize a pokusí se do aktivní větve sloučit všechny změny od tohoto předka do „revize“. (To mimochodem znamená, že je-li revize předkem aktivní větve, neudělá příkaz nic, a je-li naopak potomkem, aktivní větev se jednoduše nastaví na zadanou revizi.)
Git se při slučování snaží všechny změny zanést automaticky. Pokud jsou však změny v některých souborech konfliktní, automatické slučování selže a konflikty musíte vyřešit ručně, příkazem „git mergetool“ nebo slučování zrušit příkazem „git merge --abort“.
Zde vysvětlím pouze ruční řešení konfliktů. Příkazem „git status“ identifikujte soubory, kde se konflikty nacházejí (jsou označené „both modified“). Každý takový soubor musíte otevřít v textovém editoru a najít konflikty (Git je označil příslušnými značkami). Řádky, které jsou v konfliktu, musíte nějakým rozumným způsobem sloučit, a značky Gitu odstranit. Po vyřešení všech konfliktů odešlete změny do PO a vytvořte revizi:
git add -u && git commit --no-edit
Pozor, pokud značky konfliktu někde zapomenete, zůstanou součástí příslušných souborů, což může být do budoucna problém.
10. Další zdroje informací
git help
git help příkaz-gitu
Další dobrou možností je oficiální online referenční příručka (viz sekci „Odkazy“), ale vždy budete muset zkontrolovat, zda vaše verze Gitu uváděné volby již podporuje. Přehled podporovaných konfiguračních voleb pro příkaz „git config“ najdete (v angličtině) v online referenční příručce u příkazu „git config“.
11. Odkazy
- Playlist: tutorial gitu od BambooMachine
- Stránka na Wikipedii
- Kniha „Pro Git“ (ISBN 978-80-904248-1-4, podléhá licenci Creative Commons Uveďte autora-Nevyužívejte dílo komerčně-Zachovejte licenci 3.0 United States)
- Video: Git křížem krážem
- Video: Git - rýchly úvod, prvé príkazy (slovensky)
- Learn Git Branching (anglicky) (velmi dobrý kurz, podléhá licenci MIT)
- A Step by Step Guide for How to Resolve Git Merge Conflicts (anglicky)
- Git rebase and Git rebase --onto (anglicky)
- Oficiální online referenční příručka (anglicky)
- Oficiální stránka programu (anglicky)
- Manuálová stránka (anglicky)
- Balíček Ubuntu „git“ (anglicky)
- Balíček Ubuntu „gitk“ (anglicky)
12. Zákulisí kapitoly
V této verzi kapitoly chybí:
- git for-each-ref
- git rev-list (je třeba lepší zpracování)
Tato kapitola záměrně nepokrývá:
- nic
1 Vhodné formáty jsou „medium“, „oneline“ a „reference“; vyzkoušejte, který z nich vám víc vyhovuje. Úplný popis k revizím z nich poskytuje jen „medium“.
2 Pokud nezadáte revizi, použije se HEAD.
3 Při bezpečném mazání Git odmítne smazat větev, pokud by tím přestaly být dostupné některé revize, protože nejsou odkazovány odjinud. Bezpečné mazání je tedy určeno především pro mazání větví, jejichž změny již byly sloučeny do jiných větví.
4 Po přiřazení nové revize aktivní větvi vám zdánlivě v PO vzniknou nové změny, protože PO zůstane ve stavu odpovídajícím původní revizi. Pokud se chcete veškerých odlišností PO a PA od cílové revize zbavit, místo „--soft“ použijte „--hard“.
5 Místo uvedeného tvaru příkazu „git commit“ můžete použít jakýkoliv jiný, podstatné však je, že nová větev nevznikne, dokud v ní nevytvoříte alespoň jednu revizi.
6 Pokud byly v PA a PO již nějaké změny oproti původní aktivní větvi, Git se je při načítání nové větve pokusí zachovat.
7 Poznámka: tento příkaz nepřidá do revize žádné dosud neverzované soubory, a pokud jste některý verzovaný soubor přesunuli jinak než příkazem „git mv“, Git už ho nenajde a v revizi skončí jako smazaný.
8 Příkaz „git add“ automaticky ignoruje soubory a adresáře nastavené k ignorování v souboru „.gitignore“.
9 Revizi v každém případě zůstanou rodiče. Neuvedete-li „--reset-author“, zůstane jí i autor a časová známka. Neuvedete-li „--no-edit“, zůstane jí komentář. Vždy se naopak změní obsah a heš. Pozor, ostatní odkazy na nahrazovanou revizi (např. jiná než aktivní větev) budou nadále odkazovat na původní, nezměněnou revizi!
10 Jsou-li v pracovním adresáři změny, tento příkaz se je pokusí zachovat.
11 Výchozí revize je HEAD. Pozor, bez ptaní přepíše změny v pracovním adresáři!
12 Pozor! Cesta/k/souboru nesmí opustit podstrom aktuálního adresáře. Tzn. např. cesta „../x.c“ je neplatná a skončí chybou, a to i v případě, že odkazovaný soubor je verzovaný v daném repozitáři.
13 Poznámka: Jména revizí jsou obvykle trvalá. Pokud se rozhodnete je měnit či mazat, pamatujte, že Git při načítání jmen revizí ze vzdáleného repozitáře nikdy nepřepíše již stažené údaje, takže znovupoužití téhož jména k označení jiné revize povede k tomu, že v repozitářích různých uživatelů bude totéž jméno označovat různé revize, což není dobrý nápad.
14 Příkaz „git merge“ se pokusí do aktivní větve sloučit všechny změny od NSP po uvedenou revizi. Pokud to bude potřeba, vytvoří pro to novou revizi se dvěma rodiči.
15 Příkaz „git revert“ vyžaduje, aby v PO ani PA nebyly žádné změny oproti HEAD. Příkaz vytvoří nové revize s opačným účinkem oproti zadaným revizím.
16 Tento příkaz používejte opatrně. Vyjde od zadané revize a vytvoří zcela novou sérii revizí, ve které revizi po revizi přehrává změny od NSP po aktivní větev. Nakonec nastaví aktivní větev na konec takto vytvořené sekvence revizí, takže se původní revize ztratí, ledaže na ně vedl jiný odkaz (např. jiná větev či jméno revize).
17 Pokud aktivní větev není napojená, příkaz selže s návratovým kódem 128.
18 Vzdálená adresa může být URL nebo místní cesta. Vzniklý repozitář pak bude mít automaticky nastavený vzdálený repozitář „origin“ na uvedenou adresu či cestu.
19 Poznámka: v žádných dvou pracovních adresářích jednoho repozitáře nemůže být současně aktivní tatáž větev; toto opatření platí, aby se zamezilo konfliktům při commitování.
20 Poznámka: PA a PO nemusí být při obnovování změn v přesně stejném stavu jako při odkládání, stačí když při obnovování změn nedojde ke konfliktu.
21 Poznámka: Tento příkaz smaže pouze soubory v aktuálním adresáři a jeho podadresářích; pokud chcete smazat neverzované soubory v celém PA, musíte příkaz spustit v kořeni pracovního adresáře.
22 Vzorek může obsahovat zvláštní znaky „?“, „*“, a konstrukce „[...]“ a „[^...]“.
23 Vhodný počet sekund je např. 300 (5 minut), 86400 (24 hodin), 604800 (týden). Údaje se ukládají pouze v RAM, takže se ztratí restartem systému, možná i odhlášením.
24 Vhodné jsou editory, které otevírají každý soubor v novém procesu, např. „nano“, „vim“, „emacs“, „mousepad“; předpokladem je, že daný editor musíte mít nainstalovaný.
Systém
Prohlížení textových souborů
MetapříkazyLíbí se vám tento projekt a chcete, aby byl ještě lepší? Můžete mi s tím pomoci. Zmiňte se o něm technicky zdatným přátelům, opravte překlepy a nahlašte nefunkční zaklínadla, aby mohla být opravena; poskytněte mi zpětnou vazbu nebo se zapojte do vývoje nových kapitol. Další informace na GitHubu v dokumentu Jak se zapojit.