Navod na pracu so systemom git






===== Git windows =====

[[howto:git_windows|Git windows]]


===== Instalacia systemu =====

Instalaciu systemu git. 

Pre distribuciu *ubuntu/debian:
<code>
sudo apt-get install git
</code>




































===== Zoznam repozitarov - server =====

Na servri phoenix sa nachadzaju repozitare na ceste:
<code>
/home/git/repositories/
</code>
Repozitare cez https su pristupne na ceste 
<code>
https://git.emza.inside.transdata.sk/git/nazov_repozitaru)
</code>
[[howto:list_of_git_repositories|Zoznam repozitarov]]


===== Pridanie noveho repozitara =====

Pridavanie noveho repozitara vykonava spraca git repozitarov M.Chyla.
Kazdy novy repozitar je POTREBNE zdokumentovat na tejto wiki stranky, minimalne kratkym popisom na co dany repozitar sluzi.

**Nazvoslovie pridavaneho repozitaru:**
  * Vsetky pismena malym pismom - standardne zauzivane pravidlo pre spravu git repozitarov
  * Pouzivaju sa len pismena a cislice, ziadne ine znaky nie su povolene





===== Prvotne nastavenie - server =====

Vstupne premenne pre navod:
  * Git server - phoenix ( 192.168.241.14 )
  * Standardna cesta pre git repozitare : <code> phoenix:/home/git/repositories </code>

Na zaklade definovanych ciest je mozne vytvorit repozitar [[http://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server|Vytvorenie repozitara ]]






===== Prvotne nastavenie - klient =====
  * Vytvorenie lokalnej identity pre pracu so systemom: [[http://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup#Your-Identity|Identita]]
<code>
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
</code>
  * Ak chcete nastavit iny ako systemovy defaultny editor pre git: [[http://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup#Your-Editor|Prednastavenie systemoveho editoru]]
  * Kontrola spravnosti nastavenia identity: [[http://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup#Checking-Your-Settings|Kontrola identity]]
<code>
git config --list
</code>
  * Vytvorenie suboru na nastavovanie ignorovanych suborov git-kom ( pre vsetky projekty ) napr. *.o *.so, alebo si ho stiahnut z phoenixa.
<code>
cp /usr/local/emtest/DevelInstall/git/.gitignore_global ~/.gitignore_global
ALEBO
ln -s /usr/local/emtest/DevelInstall/git/.gitignore_global ~/.gitignore_global
</code>

Nasledne vykonat 'git config'. Pri update suboru prikaz nie je potrebny:
<code>
git config --global core.excludesfile ~/.gitignore_global
</code>




===== Emailove notifikacie pull requestov =====

Emailove notifikacie pre pull requesty su implementovane pomocou rozsirenia nastroja smartgit: [[https://www.syntevo.com/doc/display/SG/Server-side+component|Server side component]]

Rozsirenie sa nachadza na phoenixe na ceste: <code>/home/git/smartgit-reviewserver</code>
Kazdy repozitar pozadujuci emailove notifikacie musi mat v git hookoch skript post-receive nachadzajuci sa na <code>/home/git/.git-templates/hooks</code>





===== Pristup k repozitarom =====

Po dohode sa robi clone zdrojovych suborov na lokalny pocitac na cestu:
<code>
/opt/devel/src/
</code>












==== Zoznam git uzivatelov a pristup k repozitarom ====

^ Uzivatel ^ Dostupne repozitare                        ^ typ SSH pristupu ^ Prava ^
| prosoft  | vendingmachine.git \\ vendingmachineui.git | git-shell        | R+W   |
| git      | vsetky repozitare                          | git-shell        | R+W   |

Pristup ku git repozitarom je rieseny na zaklade vymeny SSH klucov medzi klientom a servrom. Pri prihlaseni sa cez ssh pod spominanymi uzivatelmi je 'Git shell' nastaveny z bezpecnostneho dovodu, vid [[http://git-scm.com/docs/git-shell|Nastavenie git-shell]]. Git shell umoznuje pracu len s repozitarom a neumoznuje pracu so servrom.

Prava su riesene na systemovej urovni pomocou uzivatelov a group: [[https://wincent.com/wiki/git_repository_access_control|Nastavenie prav pri ssh pristupe ku gitu]].



==== Clone repozitaru ====

Pre pristup k repozitarom pomocou uzivatela git je potrebne, aby spravca repozitara pridal vase verejne kluce do authorized_keys na serveri phoenix. Ak este nemate vygenerovane verejne kluce, navstivte sekciu: [[http://192.168.241.14/wiki/doku.php?id=coding:rules_phoenix#prihlasovanie_vymena_klucov|vymena a generovanie verejnych klucov]]

Git repozitar sa ziska zo servra prikazom:
<code>
git clone git@192.168.241.14:/pozadovany_repozitar.git
</code>











==== Clone repozitaru s podmodulmi ====

Manual pre pracu so podmodulmi: [[http://git-scm.com/book/en/v2/Git-Tools-Submodules|Podmoduly]]

V pripade, ze repozitar ma nastavenu zavislost na iny repozitar tak sa repozitar ziska aj s podmodulmi nasledovne:
<code>
git clone --recursive git@192.168.241.14:/pozadovany_repozitar.git
</code>

Realny priklad repozitaru s podmodulmi:
<code>
git clone --recursive git@192.168.241.14:/vehiclesystemapps.git VehicleSystem
</code>
Repozitar VehicleSystem obsahuje zdrojove subory pre citacku a palubny pocitac. Okrem aplikacii su do repozitara dolinkovane aj repozitare: **Core**, **DataIO**, **AppCore**, **ApplicationTexts**, **CommonDevices**, **OBCDevices**, **OBCUI**, **SlaveUI**, **Dispatching**.

Stiahnutie repozitaru s podmodulmi konkretny branch:
<code>
git clone --recursive -b develop git@192.168.241.14:/vehiclesystemapps.git VehicleSystem
</code>



Priznak '--recursive' stahuje aj podmoduly. Ked sa '--recursive' nepouzije, podmoduly sa nestiahnu ale budu reprezentovane prazdnymi priecinkami.




===== Praca s repozitarom =====

Vykonavanie a nahravanie zmien do lokalneho a vzdialeneho repozitara [[http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository|zmeny v repozitaroch]]

Overenie zmien lokalneho repozitara so vzdialenym repozitarom [[http://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes#Fetching-and-Pulling-from-Your-Remotes|porovnavanie zmien]]

Stiahnutie poslednych zmien v submoduloch: <code>git pull --recurse-submodules</code>
Ak boli pridane nove podmoduly tak je potrebny prepinac --init: <code>git submodule update --init --recursive</code>

Overenie aktualne nastaveneho branch-a/HEAD-u: <code>git log --oneline --decorate</code>

Nastavenie branche-u celom repozitari aj s podmodulmi: <code>git submodule foreach --recursive git checkout master</code>






==== Dokumentovanie a tvorba komentarov zmien do git-u ====

Velmi dolezitu sucast prace so systemom git predstavuje pisanie poznamok pri nahravni zmien do repozitara. Z komentarov v repozitari sa generuje vyvojarsky changelog, ktory dokumentuje vyvoj produktu.

Nahravanie zmien do repozitaru rozdelujeme do styroch zakladnych operacii:
  - Oprava chyby - chyby su opravovane na zaklade task-u v systeme mantis (helpdesk),
  - Implementacia novej poziadavky - nove poziadavky su implementovane vyhradne na zaklade task-u v systeme redmine,
  - Refaktoring,
  - Nahravanie hash-ov podmodulov repozitaru

Format komentarov pre operacie:
=== Oprava chyby - system Mantis/Helpdesk===
<code>
BugID CISLO_CHYBY_V_SYSTEME_MANTIS - zrozumitelny popis vykonanych uprav/oprav
</code>

=== Oprava chyby - system Redmine===
<code>
RedmineBug #CISLO_CHYBY_V_SYSTEME_MANTIS - zrozumitelny popis vykonanych uprav/oprav
</code>

=== Implementacia novej poziadavky ===
<code>
RedmineTask #CISLO_TASKU_V_SYSTEME_REDMINE - zruzumitelny popis implementovanej vlastnosti
</code>

**#** - Mriezka pred cislom je dolzeita pretoze redmine si vie nasledovne na zaklade tohto sparovat repozitar a redmine task.

=== Refaktoring ===
<code>
Refaktoring - preco sa kod prerabal + zrozumitelny popis vykonanych uprav
</code>

=== Nahravanie hash-ov podmodulov repozitaru ===
<code>
Commit NAZOV_PODMODULU hash - popis vykonanych uprav nad podmodulom od posledneho nahratia hash-u
</code>

 




==== Pridanie podmodulu ====

Pridanie podmodulu je mozne vykonat prikazom:
<code>
git submodule add git@192.168.241.14:/home/git/repositories/repozitar.git nazov_priecinka_pre_podmodul
</code>

Commit a push zmien sa vykona prikazom:
<code>
git commit -m "added NAZOV_MODULU module"
</code>

http://git-scm.com/book/en/v2/Git-Tools-Submodules




==== Odstranenie podmodulu ====

Odstranenie podomodulu je potrebne konzultovat so spravcom repozitara

Pre odstranenie podmodulu je potrebne vykonat sadu prikazov:
<code>
git submodule deinit nazov_podmodulu    
git rm nazov_podmodulu
git rm --cached nazov_podmodulu
rm -rf .git/modules/nazov_podmodulu
</code>









===== Merge v nastroji smartgit =====

  * Nastavime sa do branche-u, do ktoreho chceme zmeny merge-nut. Priklad merge-u release branche-u 'release/1501' do develop branche-u 'develop'
  * V nastroji SmartGIT zvolime branche, ktory si zelame merge-nut. Na obrazku, je zvoleny branche 'origin/release/1501'
{{howto:merge_select_branche_to_merge.png|Merge release/1501 do brnache-u develop}}
  * zvolime operaciu 'Merge'. Nastroj SmartGIT umoznuje dva scenare merge-u:
     * **Create merge-commit** - nastroj smartgit zluci/mergne zmeny zvoleneho branche-u do cieloveho branche-u a vytvori automaticku merge spravu 'Merge branch 'nazov branche-u'. V pripade, ze merge obsahuje konflikt, smartgit sa automaticky prepne do druheho stavu 'merge to working tree'
     * **Merge to working tree** - nastroj smartgit zluci/mergne zmeny zvoleneho branche-u do cieloveho branche-u ale oproti predchadzajucej moznosti necha commit a riesenie konfliktov na uzivatela. Uzivatel musi rucne commit-nut a pushnut zmeny {{howto:question_merge_type.png|}}
     * **Fast-Forward** - v pripade ze sa nad aktualnym brancheom, do ktoreho sa chystate mergovat nevykonala ziadna zmena, tak nie je potrebny merge. Tento specialny pripad merge-u nastavi len hlavicku a nevytvara sa ziadny merge commit. {{howto:merge_fast_forward1.png|}}
  * Po merge rucne prejdeme a overime vsetky zmeny v zdrojovych kodoch
  * V pripade ze merge-ujeme kniznicu, zdvihneme verziu v .pro subore
  * Nahranie zmien do repozitara s formatom spravy:
<code>
Merge remote-tracking branch 'BRANCHE_Z' into BRANCH_DO ( riadok generovnay smartGIT-om)

Resolved conflicts: ( riadok generovnay smartGIT-om)
	NAZVY SUBOROV - v ktorych boli vyriesene konflikty. Potencionalne problemy, preto je spravne ich dat do logu ( riadok generovnay smartGIT-om)

Features: ( rucne pisana sekcia )
	popis zmien
</code>






===== Import zdrojovych suborov do repozitara =====

Pred prvou pracou s novym a prazdnym repozitarom je potrebne ho inicializovat prvym push-om do repozitara nasledovne: [[http://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository|]]
<code>
$ cd myproject
$ git init
$ git add .
$ git commit -m 'initial commit' 
$ git remote add origin git@192.168.241.14:/project.git
$ git push origin master
</code>

mozne problemy:
<code>
- v pripade windows musia byt dvojite apostrofy: git commit -m "initial commit"

- ak je pri vytvarani repozitara adresar prazdny moze vratit chybu:
error: src refspec master does not match any.
  v tom pripade treba pridat do adresara nieco na comitnutie a opakovat kroky od kroku $ git add .
</code>





===== Online trening =====
[[https://try.github.io|Online trening]]

[[http://www.microsoftvirtualacademy.com/training-courses/using-git-with-visual-studio-2013-jump-start|Using Git with Visual Studio 2013 Jump Start]]






















===== Praca s programom SmartGit =====

V pripade prace s repozitarom, kde su nastavene aj podmoduly je potrebne/ziaduce, zapnut nasledovne nastavenie, aby pri fetch-y tahalo zmeny aj zo submodulov:

{{howto:repositorysettings.png|}}

{{howto:git-ssh.png|}}

{{howto:git-hosting-provider.png|}}

{{howto:smartgit-pull.png|}}

=== Pad programu SmartGit ===
Ak sa Vam stava, ze vam obcas padne smartgit pri prepinani medzi review komentarmi skuste zmenit v subore smartgit.sh nasledovne:

<code>
export SWT_GTK3=0

na

export SWT_GTK3=0
</code>

===== Git flow system =====

Git flow predstavuje system prace, system release-ovania, branche-ovania a system implementacie novych vlastnosti nad verzionovacim systemom git.

Pracu s git flow priblizuju clanky:
  * [[http://www.syntevo.com/smartgit/documentation/6.5/show?page=git-flow|Oficialna stranka Smartgit git-flow]]
  * [[https://blogs.endjin.com/2015/01/using-smartgit-to-follow-the-gitflow-branching-and-workflow-model/|nastavenie a pouzitie git-flow-u]] \\



==== Vizualizacia systemu prace s gitflow ====

Pre podrobnejsi popis //Support Branches// v oficialnej dokumentacii

{{howto:gitflow.png|}}

==== Nastavenie git flow - system releasovania a podpory ====
Nad repozitárom aj každým submodulom je potrebne nastaviť git flow

{{howto:nastaveniegitflow.png|}}











==== Oprava chyby (hotfix) do stable verzie (master) ====

Postupnost opravy chyby v stable verzii (master) aplikacie:
  - Vyuziva sa gitflow system v nastroji smartgit, polozka 'Git-Flow' -> 'Start Hotfix' (aj nad kazdym upravovanym submodulom)
  - Nazov Hotfix branchov vo formate BugIDXXXXXX/RedmineBugXXXXXX ( hotfix/BugIDXXXXXX alebo hotfix/RedmineBugXXXXXX predpona hotfix sa pridava automaticky, v pripade opravy viacerych chyb naraz hotfix/BugIDXXXXXX_BugIDXXXXXX ... ), pricom XXXXXX prestavuje cislo bugu. Ku kazdemu hotfixu **MUSI** existovat chyba v systeme helpdesk alebo redmine(ak sa opravuje uz existujuci hofix tak XXXXXX_1, _2, ...)
  - Vykonanie potrebnych uprav nad hotfix branchom
  - Pri upravach submodulov / libiek pozor na to, ze treba aj zdvihnut verziu kniznice v .pro a projlibs.in (aj palubak aj citacku ak treba), ako aj v zavislych submoduloch (pozri: [[coding:libweb]])
  - Commit zmien
  - Spojenie zmien branchu a stable verzie pomocou 'Git-flow' -> 'Finish hotfix'. Zmeny sa spoja do vetvy 'master' a 'develop' (pozor! stava sa, ze smartgit prepne repoztar nad submodulom do developu, co moze potom robit problemy pri finishovani hotfixu nad hlavnym repozitarom)








==== Implementacia feature do develop verzie ====
Postupnost prace z feature: 
  -  Vyuziva sa gitflow system v nastroji smartgit(licenciu distrubuuje spravca siete), polozka 'Git-Flow' -> 'Start Feature'.
  - Nazov feature branch-u: RedmineTaskCISLO_REDMINE_TASK
  - Implementacia potrebnej novej funkcionality
  - Ukoncenie feature polozka 'Git-Flow' -> 'Finish Feature'.
  - Vybrat polozku create simple commit a nasledne Finish


{{howto:finishfeature1.png|}}









==== Prerelease - Vytvaranie zastabilizovanej verzie develop vetvy ====

Zastabilizovanie zmien sluzi na posledne doladenie funkcnosti nadchadzajuceho release-u. Do prerelease vetvy sa nedorabaju ziadne nove poziadavky ani refactoring.

Postup vytvaranie prerelease-u:
  - Postupne povytvarat release vetvu pre kazdy podmodul hlavneho repozitaru
  - Vytvorit release vetvu pre hlavny repozitar










==== Ukoncenie prace na prerelease a zaclenenie zmien do master a develop vetvy ====

Po odladeni prerelease vetvy 'release/cislo_release-u' je potrebne zmeny zaclenit do master vetvy pre vytanie stable verzie.

Postupnost zaclenenia zmien prerelease verzie 'release/cislo_release-u' do stable 'master' vetvy:
  - Vyuziva sa gitflow system v nastroji smartgit(licenciu distrubuuje spravca siete), polozka 'Git-Flow' -> 'Finish release'.
  - Nezabudnut dopisat Feature sekciu ako pri klasickom mergovani










==== Support release - podpora neaktualnych verzii produktu ====

Pred mergom //prerelase// vetvy do //master// vetvy sa vytvori //support// branch z hlavneho repozitara aj vsetkych podmodulov. Do //support// branch-u sa opravuju **LEN** kriticke chyby a to priamo a **NIE** pomocou hotfix tlacidla v git-flow-e.
Po vykonani opravy nad //support// branch-om je potrebne zaclenit zmeny do //master// a //develop// vetvy, aby sa zabezpecilo, ze sa zmeny/opravy dostanu aj do najnovsej verzie.

=== Zaclenenie zmien zo support do master vetvy ===

Pre zaclenenie zmien je potrebne vykonat nasledovne kroky:
  - Vykonanie uprav nad //support// branch-om a jeho podmodulmy
  - pushnutie zmien v //support// branch-y do origin-u
  - Prepnutie sa do //master// vetvy
  - Vytvorenie hotfix-u podla pravidiel [[howto:git#oprava_chyby_hotfix_do_stable_verzie_master|Pravidla opravy chyb]]
  - Aplikacia zmien zo //support// branch-u pomocou //cherry-pick//( aplikovanie urcitej zmeny do specifickeho commit-u, v nasom pripade HEAD master-a ) do //master// vetvy
  - Ukoncenie hot-fixu  zaclenenie zmien do master a develop vetvy






==== Ulozenie zmien nad aktualnym branch-om do stash-u ====

V pripade, ze mate rozrobene zmeny nad urcitym branch-om a potrebujete sa prepnut na iny( napriklad pre vytvorenie hotfixu ) je to mozne pomocou stash-nutia zmien pomocou tlacidla v smartgit 'local' -> 'save'. Musite byt nastaveny v navigacnom menu na podpomodule, ktory pozadujete ulozit









==== Integracia pull request-u ====

Ak mame pull request, ktory bol schvaleny, potrebujeme ho integrovat, teda zmeny vykonane v zdrojom branch-i pushnut do cieloveho branch-u. Pri integracii postupujeme nasledovne:


  * 1. Pullneme najnovsie zmeny v cielovom branch-i, aby bol cielovy branch aktualny
  * 2. Klikneme pravym tlacidlom na pull request, ktory chceme integrovat, a vyberieme moznost Integrate (integrovat)

{{howto:integrate_01.png|}}

  * 3. Vyplnime commit message a zvolime "Create merge commit", zaskrtneme "Delete source branch ..." a "Push pull request and remote branch deletion" pre zmazanie zdrojoveho branch-u a pull requestu z origin. Klikneme na tlacidlo Integrate.

{{howto:integrate_02.png|}}

  * 4. V pripade, ze pri mergovani dojde ku konfliktom, vyriesime ich pomocou Conflict Solver-a.

{{howto:integrate_03.png|}}

  * 5. Po vyrieseni konfliktov staci uz len commitnut a pushnut zmeny do cieloveho branch-u. **Po pushnuti sa vsak zdrojovy branch ani pull request nezmazu, pretoze nastali konflikty.** Preto ich je potrebne manualne zmazat (staci znova integrovat pull request - vid krok 2 a 3).

{{howto:integrate_04.png|}}

Hotovo, zdrojovy branch bol mergnuty do cieloveho branch-u, o com sa mozno presvedcit v logu.

===== Zmena aktualnej hlavy podmodulu na hash z hlavneho repozitára v SmartGit =====

V prípade že podmodul je ručne nastavený na nejaký commit a chceme aby trackoval commity podľa hlavného repozitára (napríklad podmodul ApplicationTexts na globálny repozitár develop) stačí odstrániť zmenu hashu (discard ako na obrázku) v hlavnom repozitári a SmartGit prehodí aktuálny commit podmodulu na hash ktorý je uložený v hlavnom repozitári.

{{howto:smartgitchangetracking.png|}}








===== Problemy pri praci s gitom =====

==== Pridanie uzivatela do gitolite-u ====

Problem: Po pridani uzivatelo do gitolite-admin-u pytalo heslo pri pokuse o clone repozitaru.admin-u pytalo heslo pri pokuse o clone repozitaru.

Problem sa mi podarilo vyriesit pomocou stranky:
http://gitolite.com/gitolite/sts.html

Sekcia:
ssh deamon asks for a password

Problem bol v tom ze nepridaval public key do authorized_keys. Prikazom 
'gitolite setup' konfiguraky obnovil a pridal tam vsetky zname public key z 
repozitaru gitolite-admin. Nasledne uz vsetko fungovalo. Mozno sa vam to hodi 
ak budete riesit podobny problem.


==== Problem pri pridavani repozitara ==== 

Po pridani noveho repozitara je potrebne pre spravnu inicializaciu repozitara zavolat <code>git init --bare</code>

**Sposobovalo to problemy pri stahovani:** 
<code> user@user-PC:/tmp$ git clone git@192.168.241.14:/repo.git
Cloning into 'repo'...
FATAL: R any kernel sipikal DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.
</code>

**Sposobovalo to problemy aj pri rekonfiguracii gitoliteu** 
<code>
git@Phoenix:~/gitolite/src$ ./gitolite setup
FATAL: could not symlink /home/git/.gitolite/hooks/common/update to repo.git/hooks
 at /home/git/gitolite/src/lib/Gitolite/Conf/Store.pm line 371
</code>