[ Skip to the content ]

Institute of Formal and Applied Linguistics Wiki


[ Back to the navigation ]

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
user:zeman:git [2014/06/13 21:08]
zeman
user:zeman:git [2017/01/18 14:14] (current)
zeman Nový Redmine.
Line 1: Line 1:
 ====== Redmine a Git ====== ====== Redmine a Git ======
  
-ÚFALí server Redmine je na adrese https://redmine.ms.mff.cuni.cz/projectsNa wiki stránce s [[:navody|návody]] máme informace o [[:internal:redmine|nastavení osobního účtu na Redminu]].+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í překladového hřiště Ondra doporučil studentům následující příkazPř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řístupA 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/projectsNa wiki stránce s&nbsp;[[: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>+
  
-Další Ondrova doporučení (ale to druhévizualizace commitůbude asi fungovat jen v ixech):+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é radykteré jsou užitečné i pro Githubzejména pokud jde o používání klíčů SSH při přihlašování:
  
-<code bash>git svn crashcourse +<code bash>source keylogin.sh</code> 
-gitk -a</code>+ 
 +<code bash>git clone git clone https://daniel.zeman@redmine.ms.mff.cuni.cz/upper-sorbian-proj/upper-sorbian.git jmeno_pracovni_kopie</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]].
Line 22: Line 25:
   * ''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&nbsp;pracovní kopii a vrátit se k&nbsp;verzi souboru uložené v&nbsp;repozitáři+  * ''git checkout <nowiki>--</nowiki> <file>'' ... zapomenout změny v&nbsp;pracovní kopii a vrátit se k&nbsp;verzi souboru uložené v&nbsp;repozitáři 
 +    * ''git checkout -f'' ... zapomenout všechny změny všech souborů v&nbsp;pracovní kopii a vrátit se k&nbsp;poslednímu commitu v&nbsp;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
Line 35: Line 39:
   * ''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&nbsp;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&nbsp;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&nbsp;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&nbsp;mými. Musíme mít nakonfigurováno automatické sledování vzdálené větve. Ale u originu to tak defaultně je.
Line 48: Line 55:
   * ''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&nbsp;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&nbsp;někým jiným, kdo měl v&nbsp;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&nbsp;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&nbsp;někým jiným, kdo měl v&nbsp;ruce ty předchozí, nyní zavržené commity, vznikne binec, který budeme obtížně dávat dohromady.
 +
 +Vizualizace commitů v&nbsp;okenním prostředí na Linuxu:
 +
 +<code bash>gitk -a</code>
  

[ Back to the navigation ] [ Back to the content ]