Institute of Formal and Applied Linguistics Wiki

ÚFALí server Redmine je na adrese https://redmine.ms.mff.cuni.cz/projects. Ondra na něj v říjnu 2012 přestěhoval podstatnou část repozitáře StatMT z svn/trac (https://svn.ms.mff.cuni.cz/trac/statmt). Konkrétně jsou tu teď projekty ufal-smt-playground a eman (na něj se z playgroundu odkazuje jako na podmodul).

Pro vybalení hřiště Ondra doporučil studentům následující příkaz. Předpokládám, že studenti, neznajíce Ondrovo heslo, to museli volat bez toho ondrej.bojar@ na začátku a získali nějaký read-only přístup. A já na rozdíl od nich můžu použít daniel.zeman a získám přístup i pro zápis.

git clone https://ondrej.bojar@redmine.ms.mff.cuni.cz/ufal-smt-playground.git jmeno_pracovni_kopie
# Raději pracovat na 64bitovém stroji kvůli kompilacím.
ssh sol12
cd /net/cluster/TMP/zeman
git clone https://daniel.zeman@redmine.ms.mff.cuni.cz/ufal-smt-playground.git redplayground

Eman jako podmodul se asi neaktualizuje sám. Nějakou verzi k nějakému datu zřejmě získám automaticky s hřištěm, ale pokud chci mít jistotu, že budu mít ten aktuální, můžu/měl bych? udělat

cd redplayground
git submodule init
git submodule update

Další Ondrova doporučení (ale to druhé, vizualizace commitů, bude asi fungovat jen v ixech):

git svn crashcourse
gitk -a

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 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.