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/ cd dzparser git remote add origin git@github.com:dan-zeman/dzparser.git git branch --set-upstream-to=origin/master master git pull origin master git push origin master # https://github.com/dan-zeman/dzparser.git
Ú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 git clone https://daniel.zeman@redmine.ms.mff.cuni.cz/upper-sorbian-proj/upper-sorbian.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 oblastigit checkout -- <file>
… zapomenout změny v pracovní kopii a vrátit se k verzi souboru uložené v repozitářigit checkout -f
… zapomenout všechny změny všech souborů v pracovní kopii a vrátit se k poslednímu commitu v repozitářigit commit -m 'log'
… uložit soubory ze staging oblasti do (lokálního!) repozitáře; na vzdálený server to pořád nemá vlivgit 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 oblastigit diff –cached
… co jsem změnil a zkopíroval do staging oblastigit 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 sledovatgit rm –cached <file>
… přestat sledovat soubor, ale jeho kopii v pracovní složce ponechatgit mv <file1> <file2>
… přejmenovat nebo přesunout souborgit 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 synchronizovatgit 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žkygit checkout -b testing
… zkratka: vytvořit novou větev a hned se do ní přepnoutgit 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 jinougit 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