Navodila za uporabo git

Tukaj bomo zbirali navodila za vzpostavitev in uporabo git repozitorija. Ker ne moremo zajeti vseh možnih scenarijev, ste dobrodošli, da tudi sami dodaste napotke, ki bodo prišli prav vam in ostalim.

Ustvarjanje repozitorija

Ta korak ste naredili na vajah, zato vam ga ni treba ponoviti. Če vas na vajah ni bilo, pa začnete tukaj.

Ker boste delali v skupinah bo eden od članov skupine naredil glavni repozitorij in dodelil pravice za dostop ostalim članom. Ta korak naj torej naredi samo en član skupine. Preostali člani bodo lahko potem naredili svoje kopije glavnega repozitorija.

GitHub

Svetujem, da repozitorij naredite na spletni strani http://github.com - najprej se boste morali seveda tja prijaviti. Po prijavi tako v zgornji vrstci desno kliknite na + in izberite New repository.

Pod Repository name sedaj vpišite ime repozitorija. Svetujem, da je to ime vašega projekta, ali pa vsaj vaše skupine, in ne npr. opb. Pod Description lahko na kratko opišete, kaj boste delali. Izberete lahko še, ali bo repozitorij javen oziroma zaseben. Ker zastonjski zasebni repozitoriji omogočajo le tri sodelavce, svetujem, da se odločite za javen repozitorij. Svetujem, da obkljukate možnost Initialize this repository with a README, saj bo tako repozitorij že pripravljen. Izberete lahko še licenco, ki bo veljala za vaš program. Za .gitignore bomo poskrbeli kasneje.

Sedaj ste na glavni strani vašega repozitorija. Da bi svojim sodelavcem podelili pravico do pisanja, v zgornji vrstici izberite možnost Settings, nato pa v levem stolpcu na Collaborators. GitHub vas bo najprej vprašal za vaše geslo, nato pa boste prišli na stran, kamor lahko vpišete uporabniško ime vašega sodelavca. S klikom na Add collaborator bo dobil pravico pisanja v vaš repozitorij.

Sodelavci (pravzaprav kdorkoli) si lahko tudi naredijo svoje kopije repozitorija - to storijo tako, da na glavni strani repozitorija zgoraj desno kliknejo na Fork. Kasneje boste videli, kako lahko svoje spremembe poleg v svoj repozitorij (ob ustreznem pooblastilu) dodajajo še v glavnega.

Bitbucket

Če želite, imate lahko svoj repozitorij namesto na GitHub-u na spletni strani http://bitbucket.org, ki ima zelo podobno funkcionalnost. Če se odločite uporabljati Bitbucket, se najprej prijavite, nato pa v zgornji vrstici kliknite na Repositories ter izberite Create repository.

Pod Name sedaj vpišite ime repozitorija. Svetujem, da je to ime vašega projekta, ali pa vsaj vaše skupine, in ne npr. opb. Pod Description lahko na kratko opišete, kaj boste delali. Izberete lahko še, ali bo repozitorij javen oziroma zaseben. Pod Repository type naj bo izbrana možnost Git, obkljukajte pa tudi možnost Issue tracking. Pod Language lahko izberete programski jezik, v katerem boste delali.

Po kliku na Create repository boste dobili navodila, kako v ukazni vrstici inicializirati repozitorij. Natančnejša navodila so v nadaljevanju.

Da bi svojim sodelavcem podelili pravico do pisanja, v levem stolpcu izberite Settings, nato pa pod "General" izberite možnost User and group access. V okence pod User vpišite uporabniško ime uporabnika, ki mu želite dati dostop, izberete pravice dostopa (samo branje, branje in pisanje, ali administracija), in kliknite na Add. Če ste se odločili, da bi imeli zaseben repozitorij, boste morali dostop omogočiti profesorju in asistentu (Alen Orbanić: alenFMF, Janoš Vidali: jaanos).

Tudi na Bitbucketu si lahko sodelavci (oziroma tisti, ki jim dovolimo) lahko naredijo svoje kopije repozitorija - to storijo tako, da na glavni strani repozitorija v levem stolpcu kliknejo na Fork. Odpre se stran, kjer lahko nastavimo lastnosti repozitorija (podobno kot pri ustvarjanju). Po kliku na Fork repository se ustvari kopija repozitorija. Kasneje boste videli, kako lahko svoje spremembe poleg v svoj repozitorij (ob ustreznem pooblastilu) dodajajo še v glavnega.

GitLab

Podobno funkcionalnost ponuja tudi GitLab na naslovu https://gitlab.com. Če se odločite zanj, se najprej prijavite, nato pa v zgornji vrstici kliknite na + zraven iskalnika in kliknite na New Project.

Pod Project name sedaj vpišite ime repozitorija. Svetujem, da je to ime vašega projekta, ali pa vsaj vaše skupine, in ne npr. opb. Pod Project description lahko na kratko opišete, kaj boste delali. Izberete lahko še, ali bo repozitorij javen oziroma zaseben. Svetujem, da obkljukate možnost Initialize repository with a README, saj bo tako repozitorij že pripravljen.

Po kliku na Create project boste dobili navodila, kako v ukazni vrstici inicializirati repozitorij. Natančnejša navodila so v nadaljevanju.

Da bi svojim sodelavcem podelili pravico do pisanja, v levem stolpcu izberite Settings, nato pa še "Members". V okence Select members to invite vpišite uporabniško ime uporabnika, ki mu želite dati dostop, izberete pravice dostopa (Guest vidi samo osnovne podatke o repozitoriju; Reporter lahko vidi datoteke, ne more pa pisati v repozitorij; Developer lahko tudi piše v repozitorij; Maintainer ima polne pravice administracije repozitorija), in kliknite na Add to project. Če ste se odločili, da bi imeli zaseben repozitorij, boste morali dostop omogočiti asistentu (Janoš Vidali: jaanos).

Tudi na GitLabu si lahko sodelavci (oziroma tisti, ki jim dovolimo) lahko naredijo svoje kopije repozitorija - to storijo tako, da na glavni strani repozitorija zgoraj desno kliknejo na Fork. Ustvari se kopija repozitorija, kamor lahko dodajajo svoje spremembe - seveda jih lahko ob ustreznem pooblastilu dodajajo tudi v glavnega.

V nadaljevanju bomo privzeli, da uporabljate GitHub. Vse opisano je možno tudi na Bitbucketu in GitLabu.

Vzpostavitev delovnega okolja

Na svojem računalniku boste morali namestiti odjemalec za git. Če boste delali v R-ju, bo koristil tudi RStudio. Na računalnikih v računalniških učilnicah je to že urejeno, a so potrebne dodatne nastavitve.

Windows

Poberite in namestite program TortoiseGit, ki ga dobite na naslovu

https://tortoisegit.org/

Če ne boste delali v R-ju, lahko nadaljujete s kloniranjem repozitorija. V nasprotnem primeru si namestite še RStudio (če ga še nimate) - dobite ga na naslovu.

http://www.rstudio.com/

Sledeče korake bo nujno narediti za delo v računalniških učilnicah na FMF. Doma najverjetneje ne bodo potrebni, lahko pa vseeno preverite, če je vse že nastavljeno, kot mora biti.

Po namestitvi zaženite program RStudio. V meniju Tools izberite Global options..., nato pa v levem stolpcu izberite Git/SVN. Če je okence Git executable prazno, bo potrebno s kllkom na gumb Browse... najti program git.exe'. Ta se najverjetneje nahaja na

C:\Program Files\Git\bin\git.exe

ali (če uporabljate 64-bitni sistem)

C:\Program Files (x86)\Git\bin\git.exe.

Če ste to naredili, bo potrebno RStudio pred uvozom projekta ugasniti in znova zagnati.

Mac OS X

Poberite in namestite paket git s spletne strani

http://git-scm.com/download/mac

Če ju boste potrebovali, namestite tudi programa R in RStudio, ki ju dobite na

http://stat.ethz.ch/CRAN/

http://www.rstudio.com/

Nadaljevali bomo s prvim zagonom programa.

Linux

Potrebno je namestiti programa git in RStudio (če boste delali v R-ju). V distribucijah, ki slonijo na Debianu (npr. Ubuntu in Mint), to storite tako, da v ukazni vrstici napišete ukaz

sudo apt-get install git rstudio

(pri čemer lahko rstudio izpustite, če ga ne potrebujete) ter vpišete svoje geslo.

R in RStudio lahko sicer dobite tudi na

http://stat.ethz.ch/CRAN/

http://www.rstudio.com/

Prvi zagon RStudia (Mac OS, Linux)

Ko imate oba programa nameščena, najprej zaženite program RStudio. V meniju Tools izberite Global options... (pri starejših različicah RStudia imate Options...), nato pa v levem stolpcu izberite Git/SVN. Če je okence Git executable prazno, bo potrebno s kllkom na gumb Browse... najti program git. Ta se najverjetneje nahaja na

/usr/bin/git

Če ga tam ni, ga lahko najdete tako, da v ukazni vrstici napišete ukaz

which git

in vam bo nato izpisalo, kje se nahaja git. Če ne izpiše nič, git najverjetneje ni nameščen.

Če ste to naredili, bo potrebno RStudio pred uvozom projekta ugasniti in znova zagnati.

Uporabniška nastavitev za git

V ukazni vrstici (če uporabljate RStudio, uporabite ukazno vrstico znotraj RStudia) napišite naslednja dva ukaza:

git config --global user.email "e.postni@naslov"

git config --global user.name "Ime Priimek"

Tukaj seveda vpišite svoj e-poštni naslov (tistega, s katerim ste se prijavili na GitHub) ter svoje ime in priimek. Tako bo git na vašem računalniku vedel, kdo z njim dela, ter te podatke ob sinhronizaciji objavil na vašem repozitoriju na GitHubu.

Če ste se pri katerem od zgornjih ukazov zatipkali pri imenu oziroma e-poštnem naslovu, lahko ustrezni ukaz ponovite - tokrat seveda popravite svojo napako.

Delo s TortoiseGit

Orodje TortoiseGit teče pod okoljem Windows in ste si ga namestili, da bi sploh pridobili funkcionalnost git. Ko ste ga namestili, ste dobili program Git Bash - to je ukazna vrstica, ki si jo bomo ogledali v naslednjem razdelku. Delo z datotekami poteka kar v Raziskovalcu in si ga bomo pogledali tukaj.

Kloniranje repozitorija

Vsak repozitorij, ki ga lahko berete, lahko prenesete k sebi. S to kopijo repozitorija lahko naprej delate. Če imate tudi pravico pisanja, lahko spremembe potem pošljete nazaj na repozitorij. Vedno pa boste lahko pridobili posodobitve vsebine repozitorija, ki se bodo upoštevale poleg vaših lastnih sprememb. Postopek kloniranja je torej enak tako za vaše repozitorije kot tudi za repozitorije drugih. Vse, kar potrebujete, je naslov repozitorija, ki ga klonirate.

Na GitHubu na strani repozitorija (npr. vašega, če je že inicializiran) s klikom na gumb Clone or download dobite njegov naslov. Vi potrebujete naslov za HTTPS, tako da po potrebi kliknite na Use HTTPS v vrstici z naslovom, da se kot naslov izpiše Clone with HTTPS. Sedaj lahko skopirate prikazani naslov na odložišče s klikom na ikono na desni.

Repozitorije in mape znotraj njih v Raziskovalcu prepoznate tako, da imajo v ikoni še zeleno kljukico. Če želite repozitorij prenesti k sebi, se premaknite v mapo, kjer ga želite imeti, kliknite z desno ter izberite Git Clone.... V zgornje okence vnesete naslov HTTPS, ki ste ga skopirali z GitHuba, v spodnjem pa se izpiše lokacija, kjer se bo nahajala vaša kopija (lahko jo seveda tudi spremenite).

Sedaj lahko delate na svojem projektu. Preden prvič shranite spremembe, velja preveriti, ali ste že nastavili svoj e-poštni naslov in svoje ime (to ste sicer naredili že prej z ukazoma v ukazni vrstici). Po desnem kliku pod TortoiseGit izberite Settings in v levem oknu izberite Git (če še ni izbran). Tam sta okenci, kjer morata biti vaša ime in priimek ter e-poštni naslov - če ju tam ni, ju je potrebno vpisati in nastavitve shraniti s klikom na gumb OK. Ko je to urejeno, lahko shranite trenutno stanje - po desnem kliku izberite Git Commit -> "master" - zadnje je trenutno aktivna veja (več o tem spodaj). Izpisal se bo povzetek sprememb, tako da lahko izberete želene datoteke ter napišete sporočilo. Stanje shranite s klikom na Commit. V spustnem meniju zraven gumba lahko izberete tudi možnost Commit & Push, ki obenem pošlje spremembe na GitHub. Tudi če tega ne naredite, imate pa izpisu stanja možnost klika na gumb Push....

Ko želite shranjena stanja prenesti na GitHub (in tega niste še naredili), kliknite z desno znotraj repozitorija ter izberite Git Sync.... Odpre se vam okno s povzetkom lokalnih (še ne poslanih) commitov, poleg tega pa lahko izberete, kaj natančno želite kam prenesti. Navadno bodo privzete nastavitve zadostovale, tako da lahko kliknete na Push. Stanje sinhronizacije se vam bo izpisalo v novem oknu. Pri prvem prenosu boste še pozvani za uporabniško ime in geslo za GitHub. Da bi pridobili spremembe iz repozitorija v vašo lokalno kopijo ("pull"), lahko v istem oknu kliknete na Pull.

Poleg svojega repozitorija bo koristno, če si klonirate tudi vzorčna repozitorija, ki se nahajata na naslovih

https://github.com/jaanos/OPB-bottle.git in

https://github.com/jaanos/OPB-shiny.git

Ta dva repozitorija vsebujeta datoteke, ki jih bomo uporabili pri inicializaciji repozitorija, seveda pa jih lahko dodate tudi v že inicializiran repozitorij.

Inicializacija repozitorija

Če ste svoj repozitorij naredili na BitBucketu, ali pa pri ustvarjanju repozitorija na GitHub-u ali GitLab-u niste izbrali inicializacije z README oziroma datoteke .gitignore ali licence, bo potrebno repozitorij še inicializirati. Po desnem kliku znotraj nove prazne mape, kjer boste imeli svojo kopijo repozitorija, izberite Git Create repository here.... Ustvarjanje repozitorija potrdite s klikom na OK.

Da bi inicializirali repozitorij, bo potrebno vanj dodati kakšno datoteko. Dodali boste datoteko .gitignore iz imenika projekt iz repozitorija z gradivi. V tej datoteki so našteti vzorci imen datotek, za katere želite, da jih git ignorira - torej vam niti ne ponudi, da bi jih dodali na repozitorij (za vas bo pomembno, da datoteke z gesli pomotoma ne daste na repozitorij). Datoteko enostavno skopirajte v mapo, kjer se nahaja vaša kopija repozitorija. Tako kot zgoraj po desnem kliku izberite Git Commit -> "master", da naredite prvi commit.

Tako ste shranili začetno stanje (ali pa še katero več), git-u pa morate še dopovedati, s katerim repozitorijem naj sinhronizira. Po desnem kliku izberite Git Sync..., nato pa zgoraj desno kliknite na gumb Manage. Odprlo se bo okno, kjer lahko nastavljate repozitorije, s katerimi bo mogoče sinhronizirati. Pod Remote sedaj vpišite origin (kakor se navadno imenuje repozitorij, s katerim sinhronizirate). Pod URL skopirajte naslov repozitorija z GitHuba. Po kliku na Add New/Save se bo repozitorij pojavil v seznamu. Sedaj lahko z OK zaprete okno, s klikom na gumb Push pa stanje prenesete na GitHub. Vprašalo vas bo, ali naj se veja master sinhronizira z istoimensko vejo na GitHubu, na kar odgovorite z Yes. Vaš commit se bo sedaj prenesel na GitHub.

Delo z git iz ukazne vrstice

Git lahko vedno uporabljate tudi iz ukazne vrstice. V Mac OS X in Linux je to kar sistemska ukazna vrstice, v Windows pa uporabite Git Bash. Kadarkoli boste hoteli kaj postoriti iz ukazne vrstice, se boste morali najprej z ukazom cd postaviti v mapo znotraj vaše kopije repozitorija (lahko greste v vrhnjo mapo, lahko pa tudi v katero od podmap).

Kloniranje repozitorija

Če želite pridobiti kopijo repozitorija, to sotrite z ukazom git clone:

git clone https://naslov/repozitorija.git

Pri tem seveda uporabite HTTPS naslov z GitHuba. Ustvaril se bo imenik z istim imenom kot vaš repozitorij. Pred nadaljnjim delom se je potrebno vanj premakniti z ukazom cd.

Inicializacija repozitorija

Da bi inicializirali repozitorij, bo potrebno ustvariti prazno mapo in znotraj nje narediti inicializacijo. Z ukazom cd se postavite na mesto, kjer hočete imeti repozitorij, nato pa naredite prazno mapo:

mkdir projekt cd projekt git init

Namesto projekt seveda podajte želeno ime mape. Sedaj je repozitorij inicializiran, tako da lahko dodaste vanj želene datoteke (za začetek lahko dodaste .gitignore iz repozitorija z gradivi). Seznam spremenjenih datotek lahko dobite z ukazom

git status

Spremembe si lahko ogledate z ukazom

git diff

Da bi katero datoteko označili za shranjevanje, uporabite ukaz git add:

git add datoteka

Če namesto imena datoteke napišete ime imenika, bodo dodane vse spremenjene datoteke znotraj imenika. Če želite katero datoteko odstraniti od shranjevanja, to dosežete z

git reset datoteka

Če ukazu git reset ne podamo imena datoteke, bo odznačil vse datoteke.

Če želite datoteko izbrisati iz repozitorija, to storite z

git rm --cached datoteka

Možnost --cached pove, naj datoteke ne izbriše iz lokalne kopije (ob sinhronizaciji pa se bo izbrisala iz repozitorija). Če bi to možnost izpustili, bi jo izbrisalo in označilo za izbris pri naslednjem shranjevanju. Če želimo izbrisati celoten imenik (skupaj z njegovo vsebino), uporabimo še možnost -r:

git rm -r imenik

Praznih imenikov ni mogoče imeti na repozitoriju. Če iz nekega imenika odstranimo vse datoteke, ga v repozitoriju več ne bomo imeli.

Ko želite shraniti stanje, napišete

git commit

Odprl se bo urejevalnik besedil, kamor napišete opis sprememb. Spodaj je tudi povzetek sprememb, ki bodo shranjene. Med njimi so samo tiste datoteke, ki ste jih dodali z git add. Če želite preklicati shranjevanje, zaprite urejevalnik brez pisanja opisa.

Če bi želite vključiti vse spremembe, potem namesto dodajanja posameznih datotek raje napišite

git commit -a

Opis sprememb lahko vključite tudi v sam ukaz s pomočjo možnosti -m. Tako lahko napišete

git commit -m "opis sprememb"

ali

git commit -a -m "opis sprememb"

Tako bodo vključene vse spremembe na obstoječih datotekah. Nove datoteke je še vedno potrebno dodati z git add.

Če bi želeli izničiti vse neshranjene spremembe in se vrniti na zadnje shranjeno stanje, lahko to storite z ukazom

git reset --hard

Po inicializaciji bo potrebno git-u povedati še, kje je repozitorij, s katerim naj sinhronizira. To storite z ukazom

git remote add origin https://naslov/repozitorija.git

Pri tem seveda uporabite HTTPS naslov z GitHuba. Sedaj lahko pošljete svoje spremembe na repozitorij z ukazom

git push

Isti ukaz lahko uporabite vsakič, ko želite na repozitorij poslati svoje shranjene spremembe.

Ko pa želite dobiti zadnje spremembe z repozitorija, napišite

git pull

Delo z git v RStudiu

RStudio omogoča osnovno delo z git repozitoriji. Nekaterih naprednih možnosti ne podpira - če vaš repozitorij še ni inicializiran, boste to morali storiti v Git GUI-ju ali ukazni vrstici.

Uvoz projekta

V RStudiu kliknite zgoraj desno, kjer piše Project: (None) (ali pa ime trenutnega projekta, če ga imate odprtega) in izberite Create project.... Nato izberite Version Control in Git. Odpre se vam okno, kamor bo potrebno vpisati naslov repozitorija.

Na GitHubu na strani z vašim repozitorijem je njegov naslov napisan v okencu pod desnim stolpcem. Vi potrebujete naslov za HTTPS, tako da po potrebi kliknite na Use HTTPS v vrstici z naslovom, da se kot naslov izpiše Clone with HTTPS. Sedaj kopirajte prikazani naslov (to lahko storite s klikom na ikono na desni) in ga prilepite v okence Repository URL v RStudiu. Pod Project directory name napišite ime imenika, kjer naj bo vaš projekt (ta se bo na novo ustvaril), v spodnjem okencu pa izberite pot, kjer se bo ta imenik nahajal.

Na računalnikih v učilnicah na FMF pazite, da se bo vaš projekt nahajal na disku U:\. Če niste bili pazljivi in ste projekt naredili na namizju, se lahko pojavijo problemi, ki jih pa bomo kasneje rešili.

Sedaj kliknite na Create project in začelo se bo pobiranje vsebine repozitorija. Če se prvič povezujete, vas bo vprašalo po pristnosti strežnika - odgovorite yes (z malimi črkami). Če ste podali geslo pri ustvarjanju ključa, ga bo sedaj potrebno vpisati. Če je vse šlo v redu, imate sedaj pri sebi kopijo repozitorija in lahko začnete z delom na projektu. V zgornjem desnem kotu je sedaj napisano ime projekta, desno spodaj pa je prikazana vsebina repozitorija.

Sinhronizacija z repozitorijem

Sedaj lahko začnete z delom na svojem projektu. Ko ste nekaj uspešno naredili in bi želeli shraniti trenutno stanje, v menuju Tools v RStudiu pod Version Control izberite Commit....

Če te možnosti nimate, je to verjetno zato, ker imate projekt na namizju računalnika v računalniški učilnici. V tem primeru kliknite desno zgoraj na ime projekta in izberite Close Project, nato pa spet iz istega menija izberite Open Project.... Pojdite na U:\_System\Desktop\ in od tam poiščite svoj projekt ter odprite datoteko s končnico .Rproj.

Odpre se vam okno, kjer lahko pregledate vaše spremembe. Levo zgoraj so naštete spremenjene in nove datoteke. Če na katero kliknete, vam bo spodaj prikazalo spremembe, ki ste jih naredili (z rdečo so označene izbrisane vrstice, z zeleno pa dodane). Datoteke, katerih stanje bi radi shranili (in jih boste kasneje poslali na repozitorij), označite s kljukico (navadno boste označili kar vse datoteke, a morda česa še niste dokončali in še ne bi radi shranili). V desno zgornje okence na kratko opišite, kaj ste naredili. Če mislite, da bo koristil nekoliko podrobnejši opis, naj bo prva vrstica kratek povzetek, natančnejši opis pa naj bo v sledečih vrsticah. Ko ste izbrali datoteke in napisali opis, kliknite na Commit.

Če je vse šlo v redu, boste v oknu videli izpisano prvo vrstico vašega opisa in povzetek sprememb (število spremenjenih datotek ter izbrisanih in dodanih vrstic). Lahko se zgodi, da vas git opozori, da niste nastavili e-poštnega naslova in imena - v tem primeru sledite navodilom iz razdelka Uporabniška nastavitev za git. Če git ni mogel uganiti nekakšnega e-poštnega naslova, potem shranjevanje ne bo uspelo in bodo prej obkljukane datoteke ostale na seznamu.

Uspešno shranjevanje pomeni, da se je stanje shranilo na vaš računalnik in se še ni preneslo na repozitorij. Tega tudi ni potrebno takoj storiti, pač pa lahko nadaljujete z delom in še večkrat shranite trenutno stanje. Ko pa želite prenesti spremembe na repozitorij (npr. ob koncu dela, ali pa če ste uspeli narediti kaj pomembnejšega), to storite tako, da v zgornjem desnem kotu kliknete na Push. Tako vam bo preneslo vsa vaša shranjena stanja na repozitorij.

Vsakič, ko boste začeli z delom, s klikom na Pull potegnete zadnjo verzijo (in v resnici tudi vse vmesne) z repozitorija k sebi, da lahko nadaljujete z delom. To možnost lahko dobite tudi neposredno iz menija, in sicer v meniju Tools pod Version Control izberete Pull branches.

Vedno si lahko ogledate tudi zgodovino vaših sprememb. To dobite tako, da v oknu levo zgoraj izberete History (vrnete s s klikom na Changes), ali pa da v meniju Tools pod Version Control izberete History.

Kaj gre lahko narobe

Do sedaj smo predvidevali, da bo šlo vse kot po maslu. Seveda pa vedno ne bo tako, a ker je git prvenstveno orodje za sodelovanje, so predvidene različne situacije, kjer gre kaj narobe, in načini, kako te nevšečnosti odpraviti.

Shranjevanje stanja ("commit")

Shranjevanje poteka lokalno, zato do večjih nevšečnosti tukaj ne bo prihajalo. Praktično edina stvar, ki gre lahko narobe, je ta, da nimamo nastavljenega imena in e-poštnega naslova. Kako to rešiti, smo videli v razdelku Uporabniška nastavitev za git, pa tudi v razdelku o TortoiseGit-u.

Kljub temu, da se commit ob pomanjkanju te nastavitve pritoži, pa včasih lahko vseeno "ugane" neke vrste e-naslov, ki je sestavljen iz vašega uporabniškega imena in domene, kjer se nahaja računalnik. Posledica tega je, da vas GitHub ne zna identificirati, in bo povedal, da je spremembe naredil neznanec ("unknown"). Žal tega za že poslane spremembe več ne morete popraviti (preden ste prvič poslali spremembe na GitHub, bi sicer lahko še popravili lastnika commita). Če pa ste v nastavitvah podali veljaven e-poštni naslov, ki pa je različen od tistega, s katerim ste se prijavili, lahko v GitHubu desno zgoraj kliknete na kolešček (Settings) in v levem stolpcu izberete Emails. Tam lahko dodate svoj e-poštni naslov, kamor boste dobili sporočilo. Po potrditvi bo GitHub tudi ta naslov identificiral kot vašega.

Pošiljanje sprememb ("push")

Ko shranite kakšno stanje, lahko vsa nova shranjena stanja pošljete na strežnik. Problem se pojavi, če so na strežniku že stanja, ki jih pri sebi nimate - to se bo zgodilo, če je npr. kdo drug poslal spremembe na repozitorij, pa si jih še niste potegnili k sebi. Tedaj bo strežnik zavrnil vaš zahtevek in vam naročil, naj si potegnete zadnje spremembe.

Temu se boste najlažje izognili tako, da vsakič pred delom potegnete zadnje spremembe z repozitorija - seveda pa to ni zagotovilo, da ni med vašim delom kdo drug poslal svoje spremembe na repozitorij.

Prejemanje sprememb ("pull")

Kot smo omenili v razdelku msysgit, je prejemanje sprememb sestavljeno iz samega prejemanja ("fetch") in združevanja z vašo kopijo. Pri prvi operaciji ne bo nikoli problemov, druga pa lahko spodleti na dva načina.

Združevanje ne bo uspelo, če se je katerakoli datoteka v vaši kopiji spremenila. V tem primeru lahko pred združevanjem poskrbite, da so vse spremembe shranjene. Lahko pa se odločite zavreči spremembe od zadnjega shranjevanja. To lahko storite v ukazni vrstici z ukazom

git reset --hard

Naj še enkrat opozorimo, da se bodo neshranjene spremembe s tem izgubile.

Drugi način, kako se lahko kaj zalomi, je ta, da je prišlo do sprememb na istih datotekah. Git zna združevati spremembe na istih datotekah, a mu vedno ne uspe. V tem primeru pride ko konflikta in vas obvesti, v katerih datotekah se je to zgodilo. Če pogledate v katero od takih datotek, boste našli nekaj takega na mestih, kjer je prišlo do konflikta:

<<<<<<< HEAD

vsebina iz vaše kopije

=======

vsebina z repozitorija

>>>>>>> origin/HEAD

Take konflikte morate ročno razrešiti. Ko jih razrešite, lahko stanje shranite in ga pošljete na strežnik, ali pa pred tem postorite še kaj drugega (če pri projektu sodeluje več ljudi, je seveda pametno čim prej razrešiti take konfikte).

Kaj ne sodi na git

Ko neko datoteko spremenite in spremembe shranite, se pri tem ne prepiše celotna datoteka, pač pa se shrani le informacija o tem, katere vrstice so se spremenile. Tako zna git učinkovito delati z besedilnimi datotekami, nekaj težav pa ima z binarnimi datotekami - še vedno jih bo znal shranjevati, mogoče bo dostopati tudi do starejših različic, a si bo vsakič shranil (skoraj) celo datoteko. Tako se velja izogibati shranjevanju binarnih datotek na git, sploh če so velike ali se pogosto spreminjajo. Sicer pa ni nič narobe, če imate na repozitoriju kakšne manjše slike, za katere ne pričakujete, da jih boste dosti spreminjali.

Pravzaprav lahko to nekoliko posplošimo: na git ne sodijo datoteke, ki jih lahko avtomatsko pridelamo iz izvorne kode. Nekaj primerov datotek, ki ne sodijo na git:

prevedeni programi in dokumenti (*.exe, *.pdf pri prevajanju iz LaTeXa, ...), vključno s samodejno prevedenimi datotekami (*.pyc, mapa __pycache__ pri Pythonu)
uporabniški podatki in nastavitve (.RData, .Rhistory, .Rproj.user pri delu v R-ju)
podatkovne baze (npr. SQLite)
stranski produkti prevajanja in poganjanja programov (*.aux, *.log itd. pri prevajanju z LaTeXom)
sistemske datoteke (Thumbs.db v Windows, .DS_Store v Mac OS)
začasne datoteke (*.tmp, *~)
datoteke z občutljivimi podatki (gesla, številke bančnih kartic, ...)

To ne pomeni, da teh datotek ne smete imeti v mapi z vašim projektom - le pri commitih jih ne smete vključiti. Da ne bi tega storili po nesreči, lahko te datoteke navedete v datoteki .gitignore, ki jo dodaste v repozitorij. Tako bo git vedel, katere datoteke naj ignorira in vam ne ponudi, da bi jih dodali. Obenem pa lahko uporabljate lastne kopije teh datotek (da ne bo potrebno vsakič vsega prevajati).

Ker pa so nekatere od zgoraj omenjenih datotek vendarle lahko bistven del vašega projekta, pa boste v repozitoriju seveda želeli imeti izvorno kodo programov in dokumentov, da jih boste lahko prevedli. Namesto baze v datoteki boste imeli program, ki jo generira in uvozi podatke (na repozitoriju v tekstovni obliki, ali pa z interneta) - še bolje bo, če podatkovna baza teče na strežniku (npr. PostgreSQL). Morebitne datoteke z občutljivimi podatki si boste sodelavci izmenjali po kakem bolj varnem kanalu.

Napredna uporaba git

Git podpira še mnogo drugih načinov uporabe. Pogledali si bomo nekaj takih funkcionalnosti v msysgit-u in ukazni vrstici.

Veje

Git omogoča, da imate v vašem projektu več vej ("branch"). Vsaka veja predstavlja določeno zaporedje sprememb. Če želite npr. dodati vašemu programu novo funkcijo, a niste prepričani, če vam bo uspelo, lahko zanjo tako naredite svojo vejo. Sedaj lahko razvijate, kar želite, prejšnje stanje programa pa imate lahko dosegljivo v svoji veji. Med vejami lahko namreč preklapljate in delate spremembe na vsaki veji posebej, ne da bi pri tem vplivali na druge veje. Če ste npr. uspeli dodati novo funkcijo v svoji veji in bi jo želeli dodati tudi osnovnemu programu (ki ste ga medtem morda tudi že spreminjali), lahko potem veje tudi združujete.

Privzeto je glavni veji ime master. Seznam vej lahko vidite tako, da v ukazni vrstici napišete

git branch

Izpiše se seznam vej, pri čemer je trenutno izbrana označena z zvezdico. Če vej niste sami dodajali, bo izpisana le veja master. Recimo, da želite narediti novo vejo. S TortoiseGit-om po desnem kliku znotraj repozitorija pod TortoiseGit izberete Create Branch... in pod Branch vpišete ime veje. Spodaj lahko izberete vejo, ki naj služi kot osnova za novo vejo (privzeto je to trenutno izbrana veja). Po kliku na OK bo ustvarilo novo vejo in hkrati preklopilo nanjo (pri desnem kliku bo sedaj ime veje navedeno pri Git Commit).

Sedaj lahko delate na svoji veji. Med vejami preklapljate tako, da po desnem kliku znotraj repozitorija pod TortoiseGit izberete Switch/Checkout..., potem pa izberete ustrezno vejo. Pri tem se stanje povrne na stanje, kakršno je bilo nazadnje na izbrani veji - ohranijo se pa spremembe, ki še niso bile shranjene (če združevanje ne uspe, potem tudi preklop ne uspe in bo treba spremembe bodisi shraniti, ali pa jih zavreči). Ko končate z delom, spremembe shranite ("commit"). Pri pošiljanju sprememb na repozitorij ("push") lahko potem izbirate, katere veje želite poslati na strežnik. Če želite združiti dve veji, najprej preklopite na vejo, kamor želite pridruževati (navadno bo to master), nato pa po desnem kliku znotraj repozitorija pod TortoiseGit izberete Merge.... V oknu boste sedaj lahko izbrali vejo, ki jo želite pridružiti k trenutni.

Enako lahko dosežete tudi v ukazni vrstici. Novo vejo naredimo z ukazom

git branch ime_veje

Pri tem se nova veja z navedenim imenom ustvari iz trenutno izbrane veje. Nanjo morate še preklopiti z ukazom git checkout:

git checkout ime_veje

Sedaj lahko delate na svoji veji kot običajno. Če želite svojo vejo poslati na repozitorij, je potrebno nastaviti, naj se tudi ta veja sinhronizira:

git push --set-upstream origin ime_veje

Pri tem je origin ime oddaljene točke, kamor naj se pošiljajo spremembe (več o tem v naslednjem razdelku). V nadaljnje je potem mogoče spremembe pošiljati kot običajno:

git push

Če želite združiti vejo k trenutni veji, to storite z ukazom git merge:

git merge ime_veje

Ko poberete spremembe od repozitorija k sebi ("merge" ali "pull"), vam ob tem posodobi vse veje, ki ste jih imeli že pri sebi. Seznam vseh vej (lokalnih in oddaljenih) dobite z ukazom

git branch -a

Če je med oddaljenimi vejami (začnejo se z imenom oddaljene točke - privzeto origin) kakšna, ki bi jo radi imeli pri sebi, potem nanjo preklopite z ukazom

git checkout ime_veje

- pri čemer podate samo ime veje, brez imena oddaljene točke. Tako boste naredili lokalno vejo (ta bo že imela nastavljeno oddaljeno točko za sinhronizacijo), ki bo sedaj vidna tudi v TortoiseGit-u.

Med že ustvarjenimi vejami lahko preklapljate tudi v RStudiu. V oknu, kjer delate z git-om, lahko zgoraj levo (zraven izbir Changes in History) izbirate tudi trenutno vejo. Tukaj so naštete tudi oddaljene veje.

Sinhronizacija z več repozitoriji

Git omogoča sinhronizacijo z več kot enim repozitorijem. Tako lahko imamo svoj projekt na več mestih (npr. na GitHubu in Bitbucketu), lahko pa tudi dobivamo spremembe iz repozitorija, ki smo ga prvotno skopirali v svojega. Tako si bomo pogledali, kako si lahko sinhronizirate spremembe iz vzorčnega projekta.

Ko si klonirate projekt k sebi, se vam nastavi ena oddaljena točka ("remote"), ki ji git privzeto pravi origin - to je ravno vaš repozitorij na GitHubu. Seznam oddaljenih točk lahko vidite s TortoiseGit-om, če po desnem kliku znotraj repozitorija pod TortoiseGit izberete Settings, nato pa na levi pod Git izberete Remote. Bolj natančne podatke lahko dobite, če v ukazni vrstici napišete

git remote -v

Dodajanje nove oddaljene točke je opisano pri inicializaciji repozitorija. To lahko storite tudi v ukazni vrstici. Repozitorij tako dodaste z ukazom

git remote add upstream https://naslov/repozitorija.git

Če želite prenesti spremembe k sebi, to storite z ukazom

git pull upstream master

Tukaj je master ime veje na dodanem repozitoriju, od koder dobivate spremembe.

Če je bila pobrana kakšna sprememba, vam jo bo sedaj združilo z delovno kopijo. V resnici se naredi commit, tako da se odpre urejevalnik besedil, kjer lahko vpišete primeren opis sprememb. Privzeti opis pove, da je prišlo do združitve, in ga lahko pustite v taki obliki. Sedaj lahko, tako kot običajno, spremembe pošljete na repozitorij:

git push

Če imate ustrezne pravice, lahko na tako dodane oddaljene točke tudi pošiljate spremembe. Tako lahko v TortoiseGit-u po izbiri Git Sync... izberete, na katere točko želite poslati spremembe. V ukazni vrstici pa lahko podaste ime oddaljene točke, npr.

git push upstream

Uporaba issue trackerja in pull requestov

Tako na GitHubu kot tudi na Bitbucketu in GitLabu imate na voljo issue tracker (sledilec zadev) in t.i. "pull requeste" (zahtevke po združitvi - na GitLabu pod imenom merge request). Čeprav noben od njiju ni del samega sistema git, pa sta nepogrešljiva pri skupinskem delu.

Issue tracker

Issue tracker vam omogoča, da si beležite probleme in naloge, na katere ste naleteli med razvojem svojega programa. Če je javen, obenem služi kot kanal, po katerem vam lahko kdorkoli sporoči, na kakšne težave je naletel med uporabo vašega programa. Sodelavci na projektu lahko za vsak odprt problem določite, kdo naj problem reši, lahko pa tudi določate tip težave in si postavite mejnike, ki jih boste dosegli z reševanjem teh problemov. Pri vsakem problemu je mogoče dodajati nove komentarje - tako se lahko razvije debata, ki bo morda vodila do rešitve. Komentarje lahko oblikujete z Markdownom (glej npr. https://guides.github.com/features/mastering-markdown/ ).

Ko problem razrešite, lahko issue zaprete. To lahko storite tako, da na strani z issuejem kliknete na Close Issue/Close and comment (na GitHubu in GitLabu) oziroma Resolve (na Bitbucketu). Pri tem se v komentarju spodobi podati šifro commita, ki je razrešil problem (oziroma vsaj njen začetek - vsaj prvih 7 znakov). Druga možnost je, da issue zaprete kar s commitom. To storite tako, da v sporočilu pri commitu vključite eno od besed close, closes, fix ali fixes, ki ji sledi zaporedna številka issueja (npr. closes #42). Ko spremembe pošljete na repozitorij, se issue samodejno zapre.

Med issue trackerjema na GitHubu in Bitbucketu je nekaj razlik. GitHubov issue tracker je nekoliko enostavnejši, saj je vsak issue lahko le odprt ali zaprt. Vsakemu issueju lahko dodelite eno osebo, ki naj ga razreši, ter poljubno število oznak. Oznake lahko tudi sami dodajate. Na Bitbucketu lahko prav tako vsakemu issueju dodelite eno osebo, poleg tega pa mu lahko nastavite tip ter komponento projekta in njegovo različico (vrednosti slednjih dveh polj lahko sami upravljate). Poleg tega pa ima vsak issue lahko več možnih stanj - poleg odprtega in razrešenega pozna še npr. neveljavno, na čakanju, itd.

Pull requesti

Pull requesti so zahtevki po sprejetju sprememb, ki ste jih sami naredili, v drug repozitorij ali drugo vejo. Lahko jih uporabite, če želite prispevati k repozitoriju, za katerega nimate pravice pisanja. V tem primeru bi naredili svojo kopijo repozitorija ("fork"), na njem naredili nekaj sprememb, nato pa prvotnemu avtorju s pull requestom predlagali, naj sprejme vaše spremembe. Podobno kot pri issuejih se lahko tukaj razvije debata - morda bo treba še kaj popraviti, tako da lahko naredite nove commite na ustrezno vejo; ko bo prvotni avtor zadovoljen z vašimi spremembami, bo lahko vaše commite pridružil v svoj repozitorij.

V osnovi je pull request zahtevek za prenos commitov na neki veji prvega repozitorija v določeno vejo drugega repozitorija. Tako je mogoče v izbrano vejo prvega repozitorija dodajati nove commite, ki se bodo pojavili v pull requestu, če ta še ni združen. Pull requeste lahko uporabljate tudi, če lahko pišete v repozitorij, kamor bi radi dodali svojo kodo, a bi želeli pred združitvijo doseči soglasje. Ko je soglasje doseženo, lahko potem s klikom pridružite nove commite v ciljni repozitorij - seveda le, če te spremembe niso v konfliktu z obstoječimi spremembami v ciljnem repozitoriju. V nasprotnem primeru vam GitHub in Bitbucket ponudita navodila, kako v ukazni vrstici opraviti združitev - konflikte bo potem seveda potrebno ročno odpraviti.

Na Bitbucketu velja, da lahko odprete pull request iz repozitorija, kamor lahko pišete, v isti repozitorij ali v katerega od nadrejenih repozitorijev (po forkih). GitHub nima take omejitve - dovolj je namreč, da oba repozitorija izhajata iz istega izvirnega repozitorija. Tako sploh ni nujno, da s pull requestom predlagate svoje spremembe - lahko jih namreč uporabljate tudi, če želite na enostaven način prenesti spremembe med dvema repozitorijema, ki izhajata (preko forkov) iz skupnega izvirnega repozitorija.

Na GitHubu in GitLabu se pull requesti obnašajo podobno kot issueji - lahko jim dodelite osebo, ki naj zanje poskrbi, lahko dodajate oznake itd. Edina večja razlika (razen možnosti združitve) je ta, da ima vsak pull request lahko tri stanja - odprt, združen in zaprt (zavrnjen). GitHub uporablja skupen števec za issueje in pull requeste, tako da se nobena številka ne more hkrati nanašati na issue in pull request. Nasprotno imajo issueji in pull requesti na Bitbucketu in GitLabu ločene števce - na slednjem se na merge requeste sklicujemo s klicajem (!) namesto lojtro (#) pred številko. Vsakemu pull requestu na Bitbucketu lahko dodelimo enega ali več uporabnikov, ki ga bodo pregledali. Tudi tukaj je vsak pull request lahko v enem od prej omenjenih stanj.