Git submodul

Šta su git submoduli?

Submoduli su projekti (najčešće neke biblioteke) koji su ubačeni u neki drugi projekat, nakon čega su u tom tzv. “glavnom” projektu dostupni svi fajlovi submodula. Git subdmoduli nam omogućavaju da koristimo dva ili više repozitorijuma kao da su jedno. Svaki repozitorijum održava svoju zasebnu istoriju promena pa se čak subdmoduli ažuriraju nezavisno od glavnog repozitorijuma. Kada klonirate ili povučete repozitorijum sa submodulom, glavni repozitorijum dobija samo vezu do mesta odakle će “povući” kod submodul-a.

git sumbmodul

Submoduli su korisni ako u jednom git repozitorijumu imate kod ili sadržaj koji želite da koristite u više drugih projekata kojima upravlja git, ali ipak želite da istorija promena ostane odvojena. Na primer, možda koristite biblioteku koja je u aktivnom razvoju a morate da razvijete svoj kod aplikacije zajedno sa svim promenama submodula.

Kada dodate subdmodul u Git, vi ne dodajete ceo kod subdmodula u glavni repozitorijum, već dodajete samo informacije o subdmodulu. Ove informacije opisuju na koji komit subdmodula se pokazuje. Zbog toga kod subdmodula neće doći do ažuriratanja kada se ažurira repozitorijum glavnog projekta. Ovo može da bude poželjno ponašanje, jer vaš kod možda neće raditi sa najnovijim promenama subdmodula, te se tako sprečava neočekivano pucanje aplikacije.

U ovome članku ćemo koristiti dva projekta sa github-a: jedan kao glavni (https://github.com/choslee/gitSubmodulMasterParent i drugi kao subdmodul (https://github.com/choslee/gitSubmoduleChild).

Ubacivanje submodul-a u projekat

Dok smo u našem “parent” projektu za dodavnje submodula je potrebna samo njegova url adresa i korišćenje naredbe git submodule add:

Nakon izvšavanja ove naredbe pojavljuje se dva nova fila:

  • .gitmodules
  • Novi folder u kome se nalazi ceo podprojekat (našem primeru “gitSubmoduleChild”))

Zatim je ove izmene potrebno komitovari i poslati na cloud:

Kloniranje projekta sa submodulom

Sada kad imamo projekat na cloud-u (npr. GitHub-u) koji u sebi sadrži subprojekat tj. submodul potrebno je da ga kloniramo. Pri kloniranju projekata sa submodulom postoji jedan korak više u odnosu na običan projekat. Prvo ćemo uraditi standardno kloniranje projekta:

Nakon kloniranja se u okviru projekta vidi folder sa nazivom subprojekta, medjutim on je prazan! Da bi ga popunili potrebno je inicirati a zatim ga i ažurirati sa sledećim naredbama:

Nakon ove dve naredbe će se inicirati submodul a zatim i klonirati, ove dva naredbe možemo zameniti sa jednom:

Slanje izmena na cloud

Izmene na glavnom projektu

Ako napravimo izmene u okviru našeg glavnog projekta njih ćemo jednostavno poslati standardnim naredbama:

Izmene na subprojektu

Medjutim ukoliko iz našeg projekta napravimo neke izmene na fajlovima submodula i proverimo status dobićemo sledeći izveštaj:

U izveštaju vidimo da je glavni projekat nema izmena, ali vidimo da modifikovan sadržaj submodula. Ukoliko probamo da dodamo promene na index sa naredbom git add . ništa se neće dogoditi jer nema promena na glavnom projektu. Da bi poslali promene napravljene u submodulu potrebno je uraditi komit i push iz tog foldera, što znači da prvo moramo promeniti lokaciju:

A zatim tu sve odraditi:

Nakon ovoga će biti ažuriran repozitorijum koji je ubačen kao submodul.

NAPOMENA:
Uvek je potrebno prvo povući sve promene sa submodula pre pušovanja na server (pogledajte deo “Ažuriranje submodula”)

Trebamo napomenuti da se ove poslate promene neće videti na Github-u glavnog projekta, već na GitHub-u subprojekta.

Ažuriranje submodula

Kada želimo da ažuriramo podProjekat tj. submodul onda to ne možemo da uradimo samo ažuriranjem glavnog projekta sa standardnim naredbama:

Jer standardnim pull-om neće biti ažuriran submodul, ni u lokalu ni na cloud-u. Na lokalu ćemo primetiti da nema novih ili izmenjenih fajlova dok na cloud-u (npr. GitHub-u) to uočavamo posmatrajući broj komita pored naziva foldera submodula. Taj broj komita mora da bude broj poslednjeg komita suprojekta. Pogledajte broj komita subprojekta na sledećoj slici:

glavni projekat sa submodulom

Kao što se vidi na slici poslednje ažurirani komit ima broj “e14f576”, a kada pogledamo pravo stanje komita u subprojektu vidimo da ima jedan noviji komit “41b4c54” (pogledaj sliku dole):

I način

Potrebno je prvo ući u submodul:

Pa zatim povući njegove izmene:

Kada se nakon ove naredbe vratimo u glavni projekni folder i proverimo status dobijamo sledeće:

Pa sada možemo da komitujemo i pošaljemo izmene na cloud:

Tek nakon ovoga će se na cloud-u prikazati poslednje izmene u okiviru submodula, a videće se i broj poslednjeg komita submodula “41b4c54”, vidi sliku:

II način

Ovaj način je lakši jer sve možemo da radimo dok smo u glavnom projektnom direktorijumu. Za ažuriranje submodula je potrebno koristi naredbu:

Kada nakon ove naredbe proverimo status dobijamo sledeće:

Ovde se vidi da promene postoje u okviri submodula, te je sada moguće komitovati i pušovati na claud:

Nakon čega će biti ažuriran broj pored submodula koji označava poslednji komit submodula.

Brisanje submodula iz projekta

Brisanje se vrši u par koraka:

  • Obrišemo folder u našem projektu koji predstavlja submodul
  • Ako imamo samo jedan submodul onda je dovoljno da obrišemo fajl “.gitmodules” u suprotnom je potrebno da ga editujemo i obrišemo deo vezan za naš submodul
  • U okviru “.git” foldera nadjemo “modules” folder i u okviru njega obrišemo submodul.
  • U okviru “.git” foldera potrebno naći fajl “config” i unutar njega obrisati deo vezan za naš submodul:

Nakon ovoga je neophodno ove izmene komitovati i pušovati na klaud.

NAPOMENA:
Brisanje submodula iz projkta ne utiče na sam repozitorijum tog submodula, on nastavlja da “živi” na cloud-u.


Git naredbe

.gitignore

Pre aktiviranja Git-a potrebno je sprečiti čuvanje i praćenje izmena nepotrebih fajlova. Najčešće su to fajlovi koje koristi editor ili fajlovi koji nastaju kompajliranjem i sl. Fajlove ili cele direktorijume koje ne želimo da pratimo definišemo u okviru .gitignore. .gitignore fajl se smešta u okviru projektnog foldera.
Ovaj fajl se popunjava odgovarajućim naredbama uz čiju pomoć Git saznaje koje fajlove ne treba da prati. Princip obeležavanja fajlova i foldera koje ne želimo da pratimo unutar .gitignore je sledeći:

  • Upišemo ekstenzije fajlova sa razmakom koje ne želimo da pratimo kao npr.

    .swo .swp

  • Upišemo foldere koje ne želimo da pratimo:

    ime_foldera

    U slučaju da unutar foldera postoji fajl koji ipak treba da se prati upišemo:

    !nekiFajl.txt

  • Upišemo folder i njegove podfoldere koje ne želimo da pratimo:

    ime_foldera/ime_podfoldera

    Pregled grana

  • Upišemo folder i sve njegove podfoldere koje ne želimo da pratimo:

    ime_foldera/*

  • Upišemo sve objekate i arhive koje želimo da ignorišemo:

    *.[oa]

Postoji na internetu veliki broj primera .gitignore u zavisnosti kakav je projekat u pitanju (WordPress, Android….), a odličan sajt za nalaženje adekvatnog možete naći na sledećem linku: toptal/.gitignore.

Prekid praćenja

Veoma je bitno napraviti .gitignore file pre iniciranja Git-a jer ukoliko Git već započene praćenje odredjenog fajla on neće prestati da ga prati čak i ako taj neželjeni fajl naknadno ubacimo u .gitignore. U nastavku su opisane potrebne radnje za prekid prećenja nekog fajla.

a) Prekid praćenja 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:
git rm "neki naziv fajla sa razmacima.ekstenzija"

b) Prekid praćenja 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

Lokalni repozitorijum

Kada želimo da aktiviramo Git tj. da počnemo da pratimo izmene u projektu, potrebno je da unutar projektnog folder-a iniciramo pravljenje “radnog git repozitorijuma” koji se vrši na sledeći način:

Ova naredba unutar našeg projekta 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.

pregled grana nakon kloniranja

Lokalni repozitorijum je u specifičnoj vezi sa udaljenim jer je on “svestan” postojanja udaljenog repozitorijuma. U okviru lokalnog repozitorijuma uvek postoje minimum dve grane (vidi sliku):

  1. Grana pod nazivom “origin/master” koja je lokalna verzija (kopija) udaljenog repozitorijuma. Na ovu granu se ne mogu slati naše izmene, već ona služi da sa nje uzmemo izmene (merge) jer je ona praktično posrednik tj. medjukorak za dobijanje izmena sa udaljenog repozitorijuma.
  2. Grana pod nazivom “master” je naša lokalna grana direktno povezana za projekat (u kojoj pravimo commit-e).

Continue reading…


Git osnove i instalacija

Uvod u sisteme za praćenje koda

Postoje dve vrste sistema za praćenje i kontrolu verzija:

  • Sistem sa centralizovanom verzionom kontrolom (CVCS)

    Ovde pripadaju alati kao što su SVN, Perforce i CVS. Kod CVC sistema svi podaci o verzijama se nalaze na centralnom serveru dok korisnici imaju dostupnu samo trenutnu verziju na kojoj rade. Ovaj princip rada omogućava lakše održavanje i administriranje ali je sigurnost podataka problematična ukoliko dodje do otkaza sistema gube se sve informacije.

  • Sistem sa decentralizovanom verzionom kontrolom (DVCS)

    kojoj pripadaju: Mercurial, Bazaar, Darcs i Git. Kod DVC sistema korisnici pored poslednje verzije preuzimaju i kompletnu bazu o svim verzijama na tom repozitorijumu. U slučaju otkaza sistema dovoljno je da samo jedan od klijenata postavi podatke na server.

Continue reading…


Instalacija alata za web development

Uvod

alati

Ovaj članak služi kao podsetnik jednom web programeru pri instaliranju svih neophodnih alata za rad na novom ili reinstaliranom kompjuteru. Taksativno je opisana instalacija alata koje lično koristim kao i neka njihova osnovna setovanja. Web development pokriva veliki broj različitih tehnologija i programskih jezika stoga je spisak potrebnih aplikacija takodje veliki.

Continue reading…