[ 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
Last revision Both sides next revision
user:zeman:git [2014/06/13 21:08]
zeman
user:zeman:git [2015/12/01 12:56]
zeman git checkout -f
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 https://daniel.zeman@redmine.ms.mff.cuni.cz/ufal-smt-playground.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 ]