Git windows

Instalaciu systemu git.

Pre distribuciu *ubuntu/debian:

sudo apt-get install git

Na servri phoenix sa nachadzaju repozitare na ceste:

/home/git/repositories/

Repozitare cez https su pristupne na ceste

https://git.emza.inside.transdata.sk/git/nazov_repozitaru)

Zoznam repozitarov

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

Vstupne premenne pre navod:

• Git server - phoenix ( 192.168.241.14 )
• Standardna cesta pre git repozitare :

   phoenix:/home/git/repositories 

Na zaklade definovanych ciest je mozne vytvorit repozitar Vytvorenie repozitara

• Vytvorenie lokalnej identity pre pracu so systemom: Identita

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

• Ak chcete nastavit iny ako systemovy defaultny editor pre git: Prednastavenie systemoveho editoru
• Kontrola spravnosti nastavenia identity: Kontrola identity

git config --list

• Vytvorenie suboru na nastavovanie ignorovanych suborov git-kom ( pre vsetky projekty ) napr. *.o *.so, alebo si ho stiahnut z phoenixa.

cp /usr/local/emtest/DevelInstall/git/.gitignore_global ~/.gitignore_global
ALEBO
ln -s /usr/local/emtest/DevelInstall/git/.gitignore_global ~/.gitignore_global

Nasledne vykonat 'git config'. Pri update suboru prikaz nie je potrebny:

git config --global core.excludesfile ~/.gitignore_global

Emailove notifikacie pre pull requesty su implementovane pomocou rozsirenia nastroja smartgit: Server side component

Rozsirenie sa nachadza na phoenixe na ceste:

/home/git/smartgit-reviewserver

Kazdy repozitar pozadujuci emailove notifikacie musi mat v git hookoch skript post-receive nachadzajuci sa na

/home/git/.git-templates/hooks

Po dohode sa robi clone zdrojovych suborov na lokalny pocitac na cestu:

/opt/devel/src/

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 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: Nastavenie prav pri ssh pristupe ku gitu.

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: vymena a generovanie verejnych klucov

Git repozitar sa ziska zo servra prikazom:

git clone git@192.168.241.14:/pozadovany_repozitar.git

Manual pre pracu so podmodulmi: Podmoduly

V pripade, ze repozitar ma nastavenu zavislost na iny repozitar tak sa repozitar ziska aj s podmodulmi nasledovne:

git clone --recursive git@192.168.241.14:/pozadovany_repozitar.git

Realny priklad repozitaru s podmodulmi:

git clone --recursive git@192.168.241.14:/vehiclesystemapps.git VehicleSystem

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:

git clone --recursive -b develop git@192.168.241.14:/vehiclesystemapps.git VehicleSystem

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

Vykonavanie a nahravanie zmien do lokalneho a vzdialeneho repozitara zmeny v repozitaroch

Overenie zmien lokalneho repozitara so vzdialenym repozitarom porovnavanie zmien

Stiahnutie poslednych zmien v submoduloch:

git pull --recurse-submodules

Ak boli pridane nove podmoduly tak je potrebny prepinac –init:

git submodule update --init --recursive

Overenie aktualne nastaveneho branch-a/HEAD-u:

git log --oneline --decorate

Nastavenie branche-u celom repozitari aj s podmodulmi:

git submodule foreach --recursive git checkout master

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:

1. Oprava chyby - chyby su opravovane na zaklade task-u v systeme mantis (helpdesk),
2. Implementacia novej poziadavky - nove poziadavky su implementovane vyhradne na zaklade task-u v systeme redmine,
3. Refaktoring,
4. Nahravanie hash-ov podmodulov repozitaru

Format komentarov pre operacie:

BugID CISLO_CHYBY_V_SYSTEME_MANTIS - zrozumitelny popis vykonanych uprav/oprav

RedmineBug #CISLO_CHYBY_V_SYSTEME_MANTIS - zrozumitelny popis vykonanych uprav/oprav

RedmineTask #CISLO_TASKU_V_SYSTEME_REDMINE - zruzumitelny popis implementovanej vlastnosti

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

Refaktoring - preco sa kod prerabal + zrozumitelny popis vykonanych uprav

Commit NAZOV_PODMODULU hash - popis vykonanych uprav nad podmodulom od posledneho nahratia hash-u

Pridanie podmodulu je mozne vykonat prikazom:

git submodule add git@192.168.241.14:/home/git/repositories/repozitar.git nazov_priecinka_pre_podmodul

Commit a push zmien sa vykona prikazom:

git commit -m "added NAZOV_MODULU module"

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

Odstranenie podomodulu je potrebne konzultovat so spravcom repozitara

Pre odstranenie podmodulu je potrebne vykonat sadu prikazov:

git submodule deinit nazov_podmodulu    
git rm nazov_podmodulu
git rm --cached nazov_podmodulu
rm -rf .git/modules/nazov_podmodulu

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

• 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
  • 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.
• 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:

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

Pred prvou pracou s novym a prazdnym repozitarom je potrebne ho inicializovat prvym push-om do repozitara nasledovne:

$ 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

mozne problemy:

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

Online trening

Using Git with Visual Studio 2013 Jump Start

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:

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

export SWT_GTK3=0

na

export SWT_GTK3=0

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:

• Oficialna stranka Smartgit git-flow
• nastavenie a pouzitie git-flow-u
  

Pre podrobnejsi popis Support Branches v oficialnej dokumentacii

Nad repozitárom aj každým submodulom je potrebne nastaviť git flow

Postupnost opravy chyby v stable verzii (master) aplikacie:

1. Vyuziva sa gitflow system v nastroji smartgit, polozka 'Git-Flow' → 'Start Hotfix' (aj nad kazdym upravovanym submodulom)
2. 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, …)
3. Vykonanie potrebnych uprav nad hotfix branchom
4. 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: libweb)
5. Commit zmien
6. 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)

Postupnost prace z feature:

1. Vyuziva sa gitflow system v nastroji smartgit(licenciu distrubuuje spravca siete), polozka 'Git-Flow' → 'Start Feature'.
2. Nazov feature branch-u: RedmineTaskCISLO_REDMINE_TASK
3. Implementacia potrebnej novej funkcionality
4. Ukoncenie feature polozka 'Git-Flow' → 'Finish Feature'.
5. Vybrat polozku create simple commit a nasledne Finish

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

Postup vytvaranie prerelease-u:

1. Postupne povytvarat release vetvu pre kazdy podmodul hlavneho repozitaru
2. Vytvorit release vetvu pre hlavny repozitar

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:

1. Vyuziva sa gitflow system v nastroji smartgit(licenciu distrubuuje spravca siete), polozka 'Git-Flow' → 'Finish release'.
2. Nezabudnut dopisat Feature sekciu ako pri klasickom mergovani

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.

Pre zaclenenie zmien je potrebne vykonat nasledovne kroky:

1. Vykonanie uprav nad support branch-om a jeho podmodulmy
2. pushnutie zmien v support branch-y do origin-u
3. Prepnutie sa do master vetvy
4. Vytvorenie hotfix-u podla pravidiel Pravidla opravy chyb
5. 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
6. Ukoncenie hot-fixu zaclenenie zmien do master a develop vetvy

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

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)

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

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

• 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).

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

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.

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.

Po pridani noveho repozitara je potrebne pre spravnu inicializaciu repozitara zavolat

git init --bare

Sposobovalo to problemy pri stahovani:

 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.

Sposobovalo to problemy aj pri rekonfiguracii gitoliteu

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