Tento článek patří do seriálu Jak na git. Ostatní články seriálu:
- Jak na git díl 0 - Co, proč, jak?
- Jak na git - díl 1. - git init, remote, config, clone, add, commit, push
- Jak na git - díl 2. - git status, log, checkout, reset
- Jak na git - díl 3. - git revert, stash, diff, clean
- Jak na git - díl 4. - git pull, git fetch, git branch, git merge
- Jak na git - díl 5. - git tag, git cherry-pick a opravy rozbitého gitu
- Jak na git - díl 6. - git rebase a interaktivní rebase
- Git - přidávání částí souborů do commitu
- Git - tutoriály a návody
Oficiální dokumentace k dnešním příkazům: git revert, git stash, git diff a git clean
Sledování rozdílů v souborech
Sledování rozdílů mezi soubory je velmi důležitou součástí gitu. Osobně tento nástroj používám minimálně, protože v SublimeText mám plugin, který u souborů ukáže změny. Pokud je ale potřeba prohlédnout rozdíly mezi dvěma commity, větvemi apod. bude tento příkaz potřeba.
# Bez parametrů vypíše rozdíly mezi HEAD a aktuálními změnami # pro všechny soubory. Lze ale vypsat pouze pro některé soubory git diff <path> # Lze specifikovat commit vůči kterému se porovnává git diff <commit> <path> # Parametr --cached porovnává HEAD/commit vůči souborům přidaným # do staging area. Opět lze specifikovat soubory git diff ---cached <commit> <path> # Porovnává soubor/y mezi dvěma commity git diff <commit> <commit> <path>
Jiné možné výpisy včetně rozdílů v souborech
git status -vv # Vypíše kompletní informace o commitu včetně změn git show <commit> # Vypíše commity obsahující změny souboru + změny git log -p <path>
Vrácení změn daného commitu
Zákazník chce upravit jeho systém, ale jen dočasně. Celá změna se nahraje na git jako jeden commit, a až zákazník chce vrátit změnu zpět, lze to provést jediným příkazem. I když soubory mohly být mezitím upraveny, git si s tím poradí a vrátí opravdu jen to, co předchozí commit změnil. Vrácené změny budou vytvořené jako nový commit.
# Vrátí všechny změny provedené commitem a4f2bb8 git revert a4f2bb8 # Umožní upravit zprávu nového commitu git revert -e a4f2bb8
Dočasné uschování
Dočasné uschování se dá provést pomocí git stash
. K čemu to ale je? Stačí si představit situaci, že je rozdělaná práce a najednou se objeví chyba, která musí být urychleně opravena. Buď se všechny změny zahodí, zkopírují soubory, nebo něco jiného ne-gitovského a poté vrátí zpět. Správné řešení však je použít git stash.
Stash funguje podobně jako commit. Změny se ale schovají mimo log, a soubory vrátí do stavu HEAD (provede se git reset --hard). Po provedení úprav se změny ze stashe mohou opět vyzvednout zpět do staging area a v práci lze pokračovat. Stash většinou funguje jako zásobník, a lze do něj uschovat více úprav. Při použití apply nebo pop bez specifikace stashe se vybere ten nahoře zásobníku, neboli ten poslední.
# Uschování všech změněných souborů do stash. Oba příkazy jsou # ekvivalentní, ale u druhého lze přidat vlastní zprávu git stash git stash save "message" # Výpis všech uschovaných stashů git stash list # Výpis detailů stashů git stash show # Vrátí změny dříve uložené do stashe git stash apply # Vrátí změny a vymaže je ze stash git stash pop # Odstraní poslední stash, nebo specifikovaný git stash drop <stash> # Odstraní úplně všechny stashe git stash clear
Konflikty
Při vyzvednutí změn ze stashe může dojít ke konfliktu. Jak řešit konflikty bude v příštím díle, v rámci návodu jak spolupracovat s gitem ve více lidech.
Smazání netrackovaných souborů
Příkaz git clean
je velmi jednoduchý. Smaže soubory, které nejsou gitem trackované a které nejsou v .gitignore. Lze samozřejmě vypsat soubory pomocí git status
a poté je smazat ručně, tento příkaz ale tuto práci odvede automaticky. Může se hodit například po provedení git reset
.
# Nesmaže nic, jen ukáže co by smazal v aktuální složce # nebo ve složce path, pokud je zadána git clean -n <path> # Provede smazání, v aktuální složce nebo v path git clean -f <path> # Smaže také soubory i složky git clean -f -d # Smaže soubory a složky, které ignoruje (jsou v .gitignore) git clean -f -d -x
Připomínky a tipy můžete psát do komentářů
K tomuto článku již není možné přidávat další komentáře
Komentáře
Přidal bych ještě poznámku k tomu stashi, že je mnohem efektivnější pro tu případnou náhlou rychlou změnu, pracovat v jiné větvi než stashovat.
V běžném případě ano, ale může se stát, že děláš úpravu, která ti zabere 4h a jeden commit. Pak je trochu zbytečné dělat novou větev. Ale jinak ano :)
A větve ještě nebyly popsány :P