====== Redmine a Git ======

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

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

ÚFALí server Redmine je na adrese https://redmine.ms.mff.cuni.cz/projects. Na wiki stránce s&nbsp;[[:navody|návody]] máme informace o [[:internal:redmine|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 [[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>source keylogin.sh</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]].

  * ''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&nbsp;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 <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 -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&nbsp;pracovní složky a říct gitu, že ho má přestat sledovat
  * ''git rm --cached <file>'' ... přestat sledovat soubor, ale jeho kopii v&nbsp;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 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 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 push origin master'' ... odeslat změny v&nbsp;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&nbsp;revizi (commitu) s&nbsp;kódem ''dfcb57a2'', na něm vytvořit novou větev ''testing'' a hned se do ní přepnout. Při návratu k&nbsp;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&nbsp;mou aktuální větví
  * ''git branch -d testing'' ... zrušit větev, kterou už nepotřebujeme, protože jsme ji slili s&nbsp;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&nbsp;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&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>