Instanciranje repozitorijuma

Kada želimo da pratimo fajlove u nekom folderu, potrebno je unutar njega da iniciramo pravljenje “git repozitorijuma”. Pravljenje repozitorijuma se vrši sa naredbom u komandnoj liniji:

Ova naredba unutar našeg foldera kreira novi folder .git (tzv. “repozitorijum”) i u njemu će se nalaziti celokupna baza o našem projektu. Od tog trenutka Git prati projekat i radi snapshot-ove stanja kad uradimo commit. Ukoliko želimo da Git više ne prati naš projekat dovoljno je da obrišemo ovaj folder.

Napomena:
Neophodno je da pre izvršavanja naredbe, u komandnoj liniji namestimo putanju koja ukazuje na folder koji želimo da pratimo.

Git status

Kontrola da li imamo promene na fajlovima u odnosu na zadnji commit, se vrši sa naredbom:

Ako je stanje na radnoj verziji našeg projekta potpuno isto kao i u zadnjoj verziji git repozitorijuma, onda će nas git obavestiti da nemamo ništa za commit-ovanje. U suprotnom, će istaći koji fajlovi su izmenjeni.

Pregled promena koda

Ispisivanje svih razlika izmedju trenutnog stanja projekta na lokalu i zadnje verzije projekta snimljene u repozitorijumu, se dobija sa naredbom:

Razlika izmedju commit-a na istoj grani

Na sledećem primeru dobijamo razliku izmedju prethodnog commita i commita tri koraka unazad.

Razlika izmedju commit-a na dve grane

Kada želimo ispis svih razlika u projektu izmedju dva odredjena snimka stanja na različitim granama, koristimo naredbu sa argumentima nazivi grana:

Na prethodnom primeru se naredbom dobija razlika izmedju master grane i sekundarne_grane. Obratite pažnju da je redosled pri pisanju grana bitan. Pa bi se za nepravilan redosled desilo da neki fajl koji je dodan u sekundarnoj grani bude prikazan kao da je obrisan.

Slanje promena u pripremni prostor

Da bi poslali snapshot promenjene verzije nekog fajla (npr. proba.txt), u repozitorijum, moramo prvo da pošaljemo snapshot u pripremni prostor (tzv. index). Tek fajlovi koji se nalaze u ovom prostoru se mogu commit-ovati tj. poslati u repozitorijum.

Slanje odredjenog fajla

Slanje samo odredjenog fajla u pripremni prostor sa naredbom:

Slanje odredjenog direktorijuma

Sledeća naredba šalje odredjeni direktorijum u pripremi prostor:

Slanje snapshot-a svih promenjenih fajlova odredjene ekstenzije iz root-a radnog foldera

Sledeća naredba će prebaciti u pripremni direktorijum sve fajlove koje nadje u glavnom radnom direktorijumu sa .txt ekstenzijom, ali bez fajlova iz podfoldera.

Slanje snapshot-a svih promenjenih fajlova odredjene ekstenzije uključujući i iz podfoldera

Ukoliko treba da se nadju svi fajlovi sa istom ekstenzijom uključujući fajlove u podfoderima onda se koristi naredba sa navodnicima:

Slanje svih fajlova

Sledeća naredba će napraviti snapshot svih promenjenih fajlove iz radnog direktorijuma u pripremni direktorijum.

Obratiti pažnju kod ove naredbe postoji razmak (space) izmedju add i tačke!

Commit-ovanje

Sa commit-ovanjem mi pravimo snimak promena stanja fajlova, koje smo prethodno izabrali i prebacili u pripremni prostor.

NAPOMENA:
Nikad se ne commit-uje u udaljeni repozitorijum, nego snimke promena uvek commit-ujemo samo u svoj lokalni repozitorijum na računaru.

Prepravljanje zadnjeg commit-a

Može da se javi slučaj da smo nakon zadnjeg commit-a shvatili da imamo još neku promenu na fajlu koja je trebala da bude uradjena a nije. Ovaj problem možemo rešiti na dva načina. Prvi lošiji način je da nakon prepravke fajla ponovimo ceo postupak (dodavanja u pripremni prostor i commit-ovanje). U ovom slučaju nam ostaje prethodni commit i samim tim snapshot koji nije validan i ne koristi ničemu!

Bolje rešenje (sa kojim izbegavamo pravljenje nepotrebnog commit-a) je da nakon izmene u radnom direktorijumu prebacimo u pripremni prostor samo taj fajl, kao da se spremamo za standardni commit, ali zatim umesto standardnog commit-a koristimo naredbu:

Ovaj argument –amend proizvodi akciju koja “popravi” tj. zameni (replace) commit sa novim, koji je u svemu isti kao prethodni osim u delu gde je u pitanju dati fajl. Sa ovom naredbom može da se promeni i ceo komentar tako da izgleda kao da smo pregazili ceo commit.

Prekid praćenja promena

Prekid bez fizičkog brisanja

Ukoliko su greškom commit-ovani neki nebitni fajlovi za projekat, čije promene ne želimo da čuvamo, ali ne želimo ni da ih fizički obrišemo iz radnog direktorijuma, potrebno je da naredimo git-u da prestane da ih prati (tj. da ih izbaci iz repozitorijuma) sa naredbom:

Naredba za prestanak praćenja direktorijuma je:

gde -r govori Git-u da stane da prati sve podirektorijume i fajlove unutar njega.

Nakon naredbe za prekid praćenja, fajl se nalazi u prostoru pripreme (index). Da bi sprečili da fajlovi na sledećem commit-u ponovo ne udju u repozitorijum, potrebno je te fajlove pre commit-ovanja, ubaciti u .gitignore fajl.

NAPOMENA:
Obratiti pažnju da ukoliko naziv fajla sadrži razmak izmedju reči, neophodno je staviti ga u znake navoda, kao na sledećem primeru:

Prekid sa fizičkim brisanjem

Ukoliko postoji potreba da se fajl pored izbacivanja iz repozitorijuma i obriše iz radnog direktorijuma koristimo naredbu:

Ukoliko je u pitanju direktorijum koristimo naredbu:

gde -r govori Git-u da stane da prati sve podirektorijume i fajlove unutar njega. Nakon naredbe za brisanja fajlova je takodje neophodno uraditi commit (bez prethodnog slanja u index).

Više o ovoj naredbi pogledajte na oficijelnoj stranici

Rad sa udaljenjim repozitorijumom

Definicija udaljenog repozitorijuma – Bare repo

Udaljeni repozitorijum je specijalna vrsta repozitorijuma koji sadrži samo .git direktorijum i naziva se “bare repozitorijum”. Takav repozitorijum nema radnu verziju projekta tj. radni direktorijum. Ovaj repozitorijum je zamišljen da se na njemu ne radi direktan commit, već da se sa lokalnih repozitorijuma odradi push. Na udaljeni repozitorijum vlasnik (i svi sa ovlašćenjima) mogu “push-ovati” svoje izmene dok “obični” saradnici mogu samo slati pull request.

Lokalni repozitorijum je u specifičnoj vezi sa udaljenim repozitorijumom, on je “svestan” postojanja udaljenog repozitorijuma. Sa tačke gledišta lokalnog repozitorijuma, “udaljeni bare repozitorijum” sa kojim je povezan se zove “origin, a njegova master grana se zove remote/origin/master.

pregled grana nakon kloniranja

U okviru lokalnog repozitorijuma koji je povezan na udaljeni bare repozitorijum ima uvek bar dve grane:

  • origin/master – lokalna verzija udaljenog repozitorijuma koja mora “ručno” da se ažurira, a služi kao lokalna kopija udaljenog repozitorijuma i na nju se ne može commit-ovati ali su dostupni svi njeni fajlovi.
  • master je naša lokalna grana u kojoj radimo i pravimo nove commit-e

Razlozi za postojanje udaljenog repozitorijuma su:

  • Pravljenje sigurnosne kopije na udaljeni računar
  • Saradnja sa više učesnika na istom projektu

Povezivanje lokalnog i udaljenog repozitorijuma

I slučaj: imamo lokalni a pravimo udaljeni repozitorijum

Pravljenje novog udaljenog repozitorijuma (koji će da postane bare repozitorijum) se izvodi sa naredbom:

NAPOMENA:
Ovo nije potrebno ukoliko se koristi neki od online servisa kao što je GitHub ili BitBucket, jer se to uradi servis pri kreiranju praznog repozitorijuma.

Nakon čega je potrebno da lokalnom repozitorijumu damo do znanja koji je udaljeni repo njegov, to radimo sa naredbom:

Ova naredba bi za GitHub izgledala ovako:

Dok bi naredba za povezivanje na udaljeni repozitorijum na BitBucket-u izgledala ovako:

Na BitBucket-u ovu naredbu dobijate čim se napravi novi repo ukoliko se izabere opcija “imam postojeći projekat”

Kontrolu dobro obavljenog posla možemo izvršiti sa naredbom:

Nakon čega bi trebalo da izadje poruka :

Ukoliko smo dobro povezali lokal sa udaljenim repom a imamo uradjen bar prvi commit, možemo da pošaljemo sve fajlove sa lokala na prazan udaljeni repozitorijum sa naredbom:

Prekid veze sa udaljenim repo

Ukoliko želimo da raskinemo vezu lokalnog repozitorijuma sa nekim udaljenim (“origin”), koristimo naredbu:

Nakon ove naredbe naredba > git remote -v ne daje nikakve podatke.

II slučaj: Kloniranje udaljenog repozitorijuma

Kloniranje repo sa jednom granom

Ako želimo da napravimo lokalnu verziju nekog projekta koji već ima aktiviranu kontrolu verzija tj. ima bare repozitorijum, potrebno je da kloniramo udaljeni repozitorijum. Kloniranje je kopiranje udaljenog repozitoriuma, ali tako da novi (lokalni) repozitorijum ostaje “svestan” da je on kopija nekog udaljenog repozitorijuma. Kopirani repozitorijum čuva informaciju o repozitorijumu iz kojeg je nastao. Kloniranje se vrši naredbom:

Primer

U komandnoj liniju stavimo putanju na folder unutar koga će git pri kloniranju napraviti novi folder sa imenom repozitorijuma koji kloniramo.

Ova naredba će unutar foldera “folder_sa_git_projaktima” napraviti novi folder sa nazivom “naziv-udaljenog-repozitorijuma” i u njega smsetiti sve fajlove tog projekta.

Napomena:
Ukoliko želimo da promenimo originalni naziv repozitorijuma pri kloniranju, potrebno je samo nadovezati novi naziv foldera na naredbu iz prethodnog primera.
> git clone https://github.com/username_git_korisnika/naziv-udaljenog-repozitorijuma.git novi_naziv_foldera

pregled grana nakon kloniranja

Master grana udaljenog repozitorijuma koju smo klonirali sa tačke gledišta novog lokalnog repozitorijuma zove remote/origin/master. A nove grane u lokalnom repozitorijumu nakon kloniranja su:

  • origin/master – kopija udaljenog repozitorijuma u trenutku kloniranja
  • master – grana na kojoj nastavljamo rad i na koju pravimo nove commit-e.
Kloniranje repo sa više grana

Ovo je teži slučaj za kloniranje jer se nakon standardnog kloniranja dobija lokalna master grana koja se ne račva, kao na slededećim dijagramima:

kloniranje grana1

Da bi se dobila račva i na master grani u okviru našeg lokalnog repozitorijuma potrebno je izvršiti par naredbi. Prva naredba prebacuje HEAD na kraj origin/grane:

Zatim sledeća naredba pravi novu granu na masteru pod nazivom “grana”

Prebacujemo glavu na kraj nove grane sa naredbom:

Nakon čega je sve klonirano u potpunosti:

kloniranje grana2

Delimično kloniranje

Git repozitorijum sadrži celu istoriju projekta, i ukoliko projekat dugo traje može biti prilično veliki. Zato ako želimo skinuti projekat samo zato da bi pogledali njegov kod, a da nas ne zanima nas cela istorija, moguće je klonirati samo nekoliko zadnjih commitova sa naredbom:

Kloniranje repo sa GitHub-a

button for clone repo

Za jednostavno kloniranje sa GitHub-a je potrebno imati instaliranu aplikaciju GitHub Desktop. Na GitHub serveru izaberemo repozitorijum koji želimo da kloniramo i kliknemo na dugme “save username/ime_repozitorijuma to your computer and use it in GitHub Desktop”, nakon čega se iskače prozor u kome treba da izaberemo aplikaciju sa kojom ćemo da radimo u lokalu. Izaberemo aplikaciju GitHub, nakon čega će se startovati lokalna aplikacija Github Desktop i automatski prozor za izbor lokacije unutar koje će se smestiti folder projekta kloniranog repozitorijuma. Nakon toga se vrši download fajlova.

Ažuriranje lokalnih fajlova

Fetch – ažuriranje lokalne origin/master grane

Dok mi radimo u lokalu, paralelno neše kolege rade u svojim loklnim repozitorijumima. Ukoliko push-uju svoje promene na udaljeni repoitorijum, pojaviće se razlika izmedju remote origin/ Grana origin/master je kopija master grane sa udaljenog repozitorijuma i trabala bi da se ažurira da bi pratila promene koje čini vlasnik na udaljenom repozitorijumu..

grane nakon nekog vremena posle kloniranja

Kada je situacija na projektu slična situaciji na prethodnoj slici, ažuriranje origin/master grane se vrši naredbom:

Pa novo stanje nakon ažuriranja izgleda ovako:

grane nakon fetcha

Merge – ažuriranje lokalne master grane

Zatim koristimo naredbu koja će u našu master granu dodati sve nove commite sa udaljenog repozitorijumom preko novo ažurirane grane orgin/master :

nakon čega grafik izgleda ovako:

push4

Pull

Zbog čestog korišćenja naredbi iz prethodnog slučaja uvek u istom redosledu:

koristi se naredba koja ih zamenjuje:

Slanje izmena na udaljeni repozitorijum

Običnim commit-ovanjem se promene ne šalju u udaljeni repozitorijum kao kad je slučaj sa lokalnim repozitorijumom, nego se koristi posebna naredba za to “push”. Praksa je da u lokalu napravimo više commit-a, pa tek onda kada završimo neku celinu pošaljemo promene na udaljeni repozitorijum. Za ovu radnju postoji dve opcije:

  1. push – kada imamo ovlašćenja
  2. pull request – kada nemamo ovlašćenja

Push

Kada na jednom projektu radi više saradnika na različitim problemima situacija tokom vremena postaje komplikovanija. U slučaju da vlasnik repozitorijuma radi na svom repozitorijumu i commit-ovao je svoja dva commita x i y, dok istovremeno saradnik radi u lokalu na drugom problemu i commitovao je e i f čvorove, dijagram grana izgleda ovako:

push3

Ukoliko koristimo kao u prethodnom primeru naredbu push, git je neće prihvatiti, jer moramo prethodno da “sredimo” naš lokalni repozitorijum i ažuriramo našu lokalnu origin/master granu sa naredbom git pull.

push4

Nakon “sredjivanja” lokalnog repozitorijuma možemo poslati naše commit-e na udaljeni repozitorijum sa push naredbom:

kada i dobijamo definitivni grafik:

push5

Pull request

Pull request nije ništa drugo nego kratka poruka vlasniku nekog udaljenog repozitorijuma koja sadrži adresu našeg repozitorijuma, opis izmena koje smo napravili i predlog da on te izmene preuzme u svoj repozitorijum.

Uz email vlasniku repozitorijuma s porukom, koristimo i sledeću naredba:

koja priprema sve detalje izmena koje ste napravili za tu poruku.

GitHub Pull request

Ukoliko koristite Github za svoje projekte tamo postoji više potpuno automatizovanih načina da se pošalju promene iz našeg repozitorijuma na GitHub-u na repozitorijum sa koga smo “fork-ovali”. Najjednostavniji način je direktno preko dugmeta New pull request.

pull request button

Nakon izbora grane sa koje želimo da pošaljemo promene i aktiviranja dugmeta se otvara nova stranica Comparing changes gde se pregledno vidi šta su promene i na kojim fajlovima. Kada nakon pregleda utvrdite da su to te promene koje želite da pošaljete, izberete dugme Create pull request. Otvara se nova stranica gde treba da upišemo naslov i opcioni prateći komentar, nakon čega definitivno šaljemo naše promene sa aktiviranjem dugmeta Create pull request.

sending pull request

Checkout

Pregled commit-a u istoj grani

Sa naredbom checkout možemo se prebaciti (“teleportovati”) na drugu granu ili na stariji commit u istoj grani. Takvo stanje se zove “detached HEAD” tj. stanje kada HEAD pointer pokazuje na neki commit koji nije poslednji u grani.

Primer

Ukoliko je potrebno da se vratimo za 10 commit-a (koraka) unazad koristimo naredbu:

Nakon prebacivanjana na drugi commit, u radnom direktorijumu vidimo fajlove u verziji za taj commit. Ukoliko pravimo izmene na tim fajlovima, da bi ih sačuvali potrebno je da napravimo novu granu i da commit-ujemo promene. Nakon ovoga će HEAD pointer pokazivati na commit na kraj nove grane, pa repozitorijum više neće biti u “detached HEAD” stanju.

Pregled commit-a na različitim granama

Naredbu checkout takodje možemo koristiti za kretanje po granama:

Kada smo promenili granu, unutar našeg radnog direktorijuma će se sada nalaziti fajlovi sačuvani pri zadnjem commit-u u toj grani. Kod prebacivanja s grane na granu mogu nastati manji problemi ako imamo nekomitovanih izmena. Takodje postoji nekoliko situacija u kojima nam git neće dopustiti prebacivanje. Najčešći problem se javlja kada u dve grane imamo dve različite verzije istog fajla, pri čemu na jednom mestu nisu commit-ovane poslednje izmene.

Savet:
Najbolje je prvo commit-ovati sve izmene, pa tek onda se prebacivati se s grane na granu.

Da bi se ponovo vratili na krajnji commit u glavnoj grani koristimo naredbu:

Poništavanje promena

Poništavanje nekomitovanih promena

Brisanje “staging area”

Ukoliko smo greškom poslali fajlove na “staging area” tj. “index”, uklanjanje svih fajlova iz “staging area” je sa naredbom:

Povratak na poslednji komit

Ukoliko još nismo commit-ovali izmene u fajlu a želimo da vratimo prethodnu verziju, dovoljno je koristiti “checkout” naredbu

Povratak stanja jednog fajla

Ako se dogodilo da smo izmenili fajl ali nismo ga još commit-ovali, možemo da vratimo verziju tog fajla jednostavnim pregledom fajla sa naredbom:

Naredba vraća stanje datog fajla iz poslednjeg commit-a, dok HEAD pokazivač nije pomeren (pokazuje na poslednji commit).

Primer

Za vraćanje fajla proba.txt se vrši sa naredbom:

U slučaju da se fajl nalazi unutar nekog foldera, moramo podesiti da u komandnoj liniji putanja pokazuje na taj folder, inače git neće naći traženi fajl.

Povratak svih fajlova

Povratak stanja svih fajlova, koji još nisu komitovani, vraćamo sa naredbom:

Ova naredba poništava sve promene učinjene posle posledenjeg komita.

OBJAŠNJENJE:
Oznaka znači da se sve iza nje tretira kao filename (čak i da postoji neka naredba, neće se izvršiti nego će se tretirati kao filename).

Poništavnje komitovanih promena

a) Revert

Revert je prilično siguran mehanizam (sigurniji od od naredbe reset), jer ne briše commit nego dodaje novi commit čvor u kome su sklonjenje sve izmene napravljene u commit-u koji želimo obrisati. Revert naredba pravi novi commit kojim poništava izmene snimljene u nekom prethodnom commitu. Ova naredba može bit korisna u slučaju rada na istom projektu više ljudi.

revert naredba

Primer

Dakle ukoliko je poslednji commit u čvoru “f” i želimo da izbacimo promene nastale u njemu, koristimo naredbu revert koja ga neće obrisati iz istorije commit-a, nego će napraviti novi commit u čvoru “g” koji će biti isti kao u čvoru “e”.

b) Resetovanje

Soft reset

Ukoliko želimo da stanje naših fajlova u working direktorijumu ostane nepromenjeno ali samo da “zaboravimo” sve commitove od tog trenutka pa na dalje onda koristimo naredbu:

soft reset

Mixed reset

Mixed reset vraća HEAD na staru verziju ali takodje vraća i fajl u pripremni prostor (index) bez promene fajla u working direktorijumu.

soft reset

Hard reset

Ukoliko želimo da vratimo stanje naših fajlova u working direktorijumu od par commit-a unazad ali i da se “zaborave” svi commitovi koji su uradjeni od tog trenutka pa na dalje, koristimo naredbu:

soft reset

NAPOMENA:
Ukoliko smo greškom poslali fajlove na “staging area” tj. “index”, uklanjanje svih fajlova iz “staging area” je sa naredbom:

Rad sa granama

Popis grana

Ova naredba pravi spisak svih grana koje se koriste u repozitorijumu:

Pri izlistavanju u CMD-u sa * (zvezdicom) je obeležena grana u kojoj se trenutno nalazimo.

Pravljenje nove grane

Pravljenje grane se vrši sa naredbom:

Kada se napravi grana u njoj nema ni jednog čvora jer nismo uradili ni jedan commit, a mi se i dalje nalazimo u glavnoj (master) grani, što može lako da se proveri sa naredbom git branch. Da bi smo u novoj grani napravili prvi čvor neophodno je da izvršimo naredbu commit.

Prebacivanje sa grane na granu

Da i se prebacili sa grane na granu koristio naredbu checkout

Kada smo promenili granu, unutar našeg radnog direktorijuma će se sada nalaziti fajlovi sačuvani pri zadnjem commit-u u toj grani.

Kod prebacivanja s grane na granu mogu nastati manji problemi ako imamo nekomitovanih izmena. Takodje postoji nekoliko situacija u kojima nam git neće dopustiti prebacivanje. Najčešći problem se javlja kada u dve grane imamo dve različite verzije istog fajla, pri čemu na jednom mestu nisu commit-ovane poslednje izmene.

Savet:
Najbolje je prvo commit-ovati sve izmene, pa tek onda se prebacivati se s grane na granu.

Brisanje grane

Ukoliko želimo obrisati granu koristimo naredbu:

NAPOMENA:
Biti prilično obazriv sa brisanjem grane jer u suprotnom mogu nastati ozbiljni problemi.

Preuzimanje fajla iz druge grane

Relativno česta situacija je da želimo preuzeti samo jednu ili više datoteka iz druge grane, bez prelaska na drugu granu. Tada koristimo naredbu:

Moguće je istovremeno preuzeti više fajlova:

Spajanje grana

Za preuzimanje izmena iz jedne grane u drugu potrebno je biti u grani u kojoj želimo dodati izmene a zatim koristimo naredbu:

Iako se “merge branch” prevodi kao “spajanje grana” to nije ispravan smisao ove naredbe, jer standardno značenje rečenice “spajanje grane” bi napravilo samo jednu granu, što ovde nije slučaj jer grane nastavljaju svoj život odvojeno. Jedino što se od tog trenutka sve izmene nastale u jednoj grani preuzimaju u drugu granu.

merge branches

Nakon izvršenog pripajanja nije potrebno raditi commit jer je sama naredba napravila novi čvor “h”. Za razliku od ostalih čvorova (commit-a) samo ovaj ima dva “roditelja” tj. dve strelice vode do njega.

Uz sledeće slučajeve ćemo bolje shvatiti kako funkcioniše naredba:

Slučaj Rezultat naredbe
Fajl je izmenjen u pripojenoj grani a u glavnoj nije Dodaće se izmene u fajlu
Fajl je dodat u pripojenoj grani Biće dodat fajl
Fajl je obrisan u pripojenoj grani a u glavnoj nije Fajl će biti obrisan
U pripojenoj grani smo izmenili i preimenovali fajl, a u glavnoj smo samo izmenili fajl Ako izmene na kodu nisu bile konfliktne, onda će se u glavnoj fajl preimenovati i sadržaće izmene iz obe grane.
U pripojenoj grani smo obrisali fajl, a u glavnoj smo ga samo izmenili. KONFLIKT
Konflikti pri spajanju grana

U slučaju konflikta problematični fajl se neće commit-ovati, već je ostavljeno da korisnik sam edituje fajl i izabere verziju koja mu odgovara. Postoje programi (merge tool) za vizuelni prikaz konflikta i lakše rešavanje konflikata.

Spisak nekih od programa za rešavanje konflikta:

  • araxis
  • bc3
  • codecompare
  • deltawalker
  • diffuse
  • ecmerge
  • emerge
  • gvimdiff
  • gvimdiff2
  • kdiff3
  • meld
  • opendiff
  • p4merge
  • tkdiff
  • tortoisemerge
  • vimdiff
  • vimdiff2
  • xxdiff

Mogu da se aktiviraju nakon instalacije sa naredbom:

Cherry-pick

Cherry-pick je specijalna vrsta spajanje dve grane, kada želimo da prebacimo samo jednan commit iz jedne grane u drugu. Ne želimo da koristimo merge jer bi prebacio sve izmene koje smo napravili u celoj grani.

Postupak

Za prebacivanje poslednjeg commit-a sa sporedne grane u master granu je postupak sledeći:

  1. git log sporedna_grana – proučimo istoriju sporedne grane
  2. izaberemo jedinstveni broj commita
  3. git cherry-pick jedinstveni_broj_commita – naredba koja aktivira cherry-pick

U slučaju konflikta postupak je isti kao kada se javi konflikt pri korišćenju naredbe marge.

Rebase

Naredba je slična naredbi merge, ali ih ne spaja u jedan novi krajnji čvor (kao merge commit), nego dodaje celu istoriju svih commit-a. Najlakše se shvata preko primera.

Primer

Na sledaćoj slici je prikazno stanje projekta, gde pored master grane postoji i sporedna grana, a u okviru nje par commit čvorova. Zadatak je da spojimo podatke iz master grane (plavi krugovi) u sporednu.

merge diagram

Ukoliko koristimo naredbu merge, napravili bi smo novi commit (zeleni sa zvezdom) kojim bi se dodale sve promene iz master grane, pa bi dijagram izgledao kao na sledećoj slici:

merge diagram

A ako to isto uradimo sa naredbom rebase, dijagram bi izgledao ovako:

merge diagram

Najveća prednost je jasnija istorija projekta čiji dijagram je linearan kao i eliminisanje dodatnih čvorova koji se pravi pri korišćenju merge naredbe.

Ova naredba se najčešće koristi za ažuriranje origin/master grane koja je lokalna kopija master grane udaljenog repozitorijuma.

Pretraga

Pretraga komentara

Ukoliko vršimo pretragu komentara pri commit-ovanju koristimo:

Pretraga reči unutar fajlova

Ukoliko vršimo pretragu neke reči (string) unutar fajlova koristimo naredbu:

Ukoliko rečenica koja se pretražuje ima razmake potrebno ju je staviti izmedju navodnika.

Primer

Na sledećem primeru se traži tekst “strava program”:

Pretraga nam nalazi commit u kome se nalazi traženi fajl u obliku 76cf802d23834bc74473370ca81993c5b07c2e35. Naziv commit-a čine prvi pet cifara 76cf8. Dati commit možemo pregledati sa naredbom:

Čišćenje radnog direktorijuma

Kada želimo obrisati samo privremene fajlove koje su rezultat kompajliranja ili privremene direktorije koji nisu deo trenutne verzije repozitorijuma, git ih može sam pronaći. Za ovu opciju koristimo naredbu clean.

Sa sledećom naredbom dobijamo spisak stvari koje git nudi da obrišemo:

Ako nam spisak odgovara sve sa spiska brišemo sa:

Ukoliko želimo da obrišem samo neki direktorijum onda koristimo:

Sa sledećom naredbom ćemo obrisati čak i sve fajlove koje su popisane u .gitignore:

Forkovanje

Naredba fork ne postoji u okviru git-a, već je vezana za servis GitHub. Ova naredba nam omogućava da neki postojeći projekat drugog korisnika GitHub-a kopiramo u naš Github nalog, stim da naša kopija bude “svesna” da postoji roditeljski repozitorijum.

Nakon forkovanja projekta na naš gitHub nalog potrebno je da se napravi lokalna verzija repozitorijuma kloniranjem. Ovaj lokalni repozitorijum je u vezi sa oba repozitorijuma na GitHub-u. U komandnoj liniji namestimo putanju na naš lokalni repozitorijum a naredba kojom lokalnom repozitorijumu dajemo do znanja da postoji početni repozitorijum na osnovu koga je forkovan repozitorijum na naš giohub nalog je sledeća:

upstream dijagram

Nakon naredbe > git remote -v povezanost našeg lokalnog repa sa udaljenim bare repozitorijumima bi izgledao ovako:

Gledano sa lokala, roditeljski repozitorijum kod standardnog kloniranja se zove “origin”, a originalni GitHub repozitorijum koji je forkovan se naziva “upstream”

Veza izmedju lokalnog repozitorijuma i upstream repozitorijuma je bitna jer preko nje ažuriramo lokalnu granu upstream/master koja je kopija upstream grane sa naredbom:

nakon čega radimo spajanje promena sa naredbom:

ili ako upstrem ima jednostavan set commit-a

Po završetku rada na fajlovima u lokalu, možemo standardno poslati sve promene na naš udaljeni repozitorijum origin sa naredbom push, nakon čega možemo na više načina da pošaljemo na upstream pull request.

Po završetku rada na fajlovima u lokalu, možemo standardno poslati sve promene na naš udaljeni repozitorijum origin sa naredbom push, nakon čega možemo na više načina da pošaljemo na upstream pull request, ali više o ovome na delu GitHub Pull request.

Pogledajte slične članke...

Podelite:

Ostavite komentar