|
Next revision
|
Previous revision
|
user:zeman:git [2014/06/13 21:00]
zeman created |
user:zeman:git [2017/01/18 14:14] (current)
zeman Nový Redmine. |
| ===== Redmine a git ===== | ====== Redmine a Git ====== |
| |
| Ú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 [[https://redmine.ms.mff.cuni.cz/projects/ufal-smt-playground|ufal-smt-playground]] a [[https://redmine.ms.mff.cuni.cz/projects/eman|eman]] (na něj se z playgroundu odkazuje jako na podmodul). | 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''. |
| |
| 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. | <code bash>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</code> |
| |
| <code bash>git clone https://ondrej.bojar@redmine.ms.mff.cuni.cz/ufal-smt-playground.git jmeno_pracovni_kopie | ÚFALí server Redmine je na adrese https://redmine.ms.mff.cuni.cz/projects. Na wiki stránce s [[:navody|návody]] máme informace o [[:internal:redmine|nastavení osobního účtu na Redminu]]. |
| # 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</code> | |
| |
| 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 | 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 [[https://github.com/ufal|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í: |
| |
| <code bash>cd redplayground | <code bash>source keylogin.sh</code> |
| git submodule init | |
| git submodule update</code> | |
| |
| Další Ondrova doporučení (ale to druhé, vizualizace commitů, bude asi fungovat jen v ixech): | <code bash>git clone git clone https://daniel.zeman@redmine.ms.mff.cuni.cz/upper-sorbian-proj/upper-sorbian.git jmeno_pracovni_kopie</code> |
| | |
| <code bash>git svn crashcourse | |
| gitk -a</code> | |
| |
| Dokumentace ke gitu je například [[http://git-scm.com/documentation|tady]]. | Dokumentace ke gitu je například [[http://git-scm.com/documentation|tady]]. |
| * ''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 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 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 checkout <nowiki>--</nowiki> <file>'' ... zapomenout změny v pracovní kopii a vrátit se k verzi souboru uložené v repozitáři |
| | * ''git checkout -f'' ... zapomenout všechny změny všech souborů v pracovní kopii a vrátit se k poslednímu commitu v repozitáři |
| * ''git commit -m 'log<nowiki>'</nowiki>'' ... uložit soubory ze staging oblasti do (lokálního!) repozitáře; na vzdálený server to pořád nemá vliv | * ''git commit -m 'log<nowiki>'</nowiki>'' ... 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 | * ''git commit -a'' ... přeskočit stageování a uložit i soubory, které už sledujeme, změnily se, ale nejsou ve staging oblasti |
| * ''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 -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 <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 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 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 :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 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. | * ''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: |
| | |
| | <code bash>gitk -a</code> |
| |
