Poznámky o migraci ze Subversion na Git mám např. v souboru /net/work/people/zeman/hamledt/README.txt (resp. v repozitáři HamleDT, který jsem také stěhoval ze Subversion na Github). Tam je navíc oproti postupu popsanému zde popsáno ještě použití čističe historie BFG (https://rtyley.github.io/bfg-repo-cleaner/). Soubor users.txt se jmény a adresy vývojářů mám dosud o patro výš (/net/work/people/zeman/users.txt). Viz též http://git-scm.com/book/es/v2/Git-and-Other-Systems-Migrating-to-Git. Následující postup předpokládá, že jsem nejdříve vytvořil na Githubu prázdný repozitář dzparser.

git svn clone https://svn.ms.mff.cuni.cz/svn/dzparser --authors-file=users.txt --no-metadata --trunk=trunk --prefix=svn/
git remote add origin https://github.com/dan-zeman/dzparser.git
git push origin master

ÚFALí server Redmine je na adrese https://redmine.ms.mff.cuni.cz/projects. Na wiki stránce s návody máme informace o nastavení osobního účtu na Redminu.

Ještě než se používání Redmine na ÚFALu dostatečně rozšířilo, objevil se nový trend vytvářet naše repozitáře pod organizací ufal na Githubu. Ve výše uvedeném návodu pro osobní účty na Redminu jsou některé rady, které jsou užitečné i pro Github, zejména pokud jde o používání klíčů SSH při přihlašování:

source keylogin.sh

git clone https://daniel.zeman@redmine.ms.mff.cuni.cz/ufal-smt-playground.git jmeno_pracovni_kopie

Dokumentace ke gitu je například tady.

• git clone <url> … naklonovat existující repozitář (dělá se na začátku podobně jako svn checkout, ale sémantika není stejná)
• git status … v jakém stavu jsou jednotlivé soubory? (untracked / committed / modified / staged)
• git add <file> … zkopírovat změněný soubor do staging oblasti nebo zahrnout do verzování dosud neverzovaný soubor (rovnou se dostane do staging oblasti)
• git reset HEAD <file> … vyřadit soubor ze staging oblasti
• git checkout – <file> … zapomenout změny v pracovní kopii a vrátit se k verzi souboru uložené v repozitáři
• git commit -m 'log' … uložit soubory ze staging oblasti do (lokálního!) repozitáře; na vzdálený server to pořád nemá vliv
• git commit -a … přeskočit stageování a uložit i soubory, které už sledujeme, změnily se, ale nejsou ve staging oblasti
• .gitignore … soubor se jmény či šablonami jmen souborů, které se nemají verzovat a nemají se ani hlásit jako neverzované
• git diff … co jsem změnil, ale ještě nezkopíroval do staging oblasti
• git diff –cached … co jsem změnil a zkopíroval do staging oblasti
• git log … historie uložených verzí
  • gitk … grafický program, který vizualizuje výstup git log
• git rm <file> … odstranit soubor z pracovní složky a říct gitu, že ho má přestat sledovat
• git rm –cached <file> … přestat sledovat soubor, ale jeho kopii v pracovní složce ponechat
• git mv <file1> <file2> … přejmenovat nebo přesunout soubor
• git remote -v … zobrazit názvy nakonfigurovaných vzdálených repozitářů včetně jejich URL. “origin” je ten, ze kterého jsme se naklonovali.
• git remote add <shortname> <url> … přidat vzdálený repozitář, se kterým se můžeme synchronizovat
  • git remote add origin git@github.com:ufal/treex.git
  • git branch –set-upstream-to=origin/master master
• git remote rm <shortname> … odebrat spojení se vzdáleným repozitářem (nikoli vzdálený repozitář jako takový, ten zůstane nedotčen)
• git fetch origin … stáhnout nové změny ze vzdáleného repozitáře origin. Stáhnou se jako nová větev a neslijí se s mou aktuální větví, dokud to neudělám ručně.
• git pull origin … stáhnout nové změny a pokusit se je automaticky slít s mými. Musíme mít nakonfigurováno automatické sledování vzdálené větve. Ale u originu to tak defaultně je.
• git push origin master … odeslat změny v mé hlavní (master) větvi zpět na server, ze kterého jsem se naklonoval (origin)
• git remote show origin … zobrazit informace o stavu vzdáleného repozitáře ve vztahu ke mně
• git branch testing … vytvořit novou větev testing (rozvětvení bude na aktuálním commitu), ale zatím do ní nepřepínat (na aktuální větev ukazuje ukazatel HEAD)
• git checkout testing … přepnout se do existující větve testing a vybalit její soubory do pracovní složky
• git checkout -b testing … zkratka: vytvořit novou větev a hned se do ní přepnout
• git checkout -b testing dfcb57a2 … vrátit se k revizi (commitu) s kódem dfcb57a2, na něm vytvořit novou větev testing a hned se do ní přepnout. Při návratu k revizi, která současně není na konci nějaké větve, se doporučuje založit novou větev, aby HEAD vždy ukazovalo na větev a ne na pouhou revizi. Předchází se tím případným problémům, ke kterým může dojít, jestliže nad touto revizí provedeme nové změny: fakticky by vznikla nová větev, ta by ale neměla název a systém by mohl usoudit, že ji smaže, protože není potřeba.
• git merge testing … slít větev testing s mou aktuální větví
• git branch -d testing … zrušit větev, kterou už nepotřebujeme, protože jsme ji slili s jinou
• git checkout -b serverfix origin/serverfix … založit větev serverfix na základě nové větve, kterou jsme získali fetchem ze serveru origin, a přepnout se do ní. Současně tím vzniká vztah mezi novou lokální a vzdálenou větví. Tento vztah se vezme v potaz při synchronizaci pomocí push a pull.
• git push origin :serverfix … smazat větev serverfix na serveru origin (“na mé straně před dvojtečkou vezmi nic a udělej z toho aktuální stav větve serverfix na straně serveru”)
• git rebase <basebranch> <topicbranch> … práce se záplatami (patches) je jiný způsob, jak slít dvě větve. Výsledek je stejný, ale historie je přímější, samostatná větev v ní nebude vidět. Rebase přehraje na větvi base změny provedené ve větvi topic. ALE: Nemají se rebaseovat commity, které už jsme odeslali do veřejného repozitáře. Rebasing vyrábí nové commity, které mají stejný obsah, ale nejsou stejné. Pokud spolupracuji s někým jiným, kdo měl v ruce ty předchozí, nyní zavržené commity, vznikne binec, který budeme obtížně dávat dohromady.

Vizualizace commitů v okenním prostředí na Linuxu:

gitk -a