Rješavanje konflikata

Ukoliko sami radite na projektu, konflikti vam se vjerojatno neće događati (osim ukoliko ne pazite). No, ukoliko radite na projektu sa više ljudi, može vam se zadesiti da se nađete u situaciji gdje ćete morati riješiti konflikt.

Recimo da je naš helloworld projekt dobio na važnosti i sada na njemu rade dva developera, Mirko i Slavko. Mirko i Slavko u stvarnom životu radit će na svojim granama u svojim klonovima repozitorija, ali da si ovdje pojednostavnimo priču, svaki će imati po jednu granu u našem zajedničkom repozitoriju.

Kreirajmo obje grane, bez prebacivanja u njih:

> git checkout master
Switched to branch 'master'

> git branch mirko
> git branch slavko
> git branch -l
  helloworld-0
* master
  mirko
  slavko

Dolazi Mirko, vidi problem u načinu kako je definirana funkcija main i popravlja ga u svojoj grani:

> git checkout mirko
Switched to branch 'mirko'

[...promjene hello.c...]

> git diff
diff --git a/hello.c b/hello.c
index 0bb4941..8b08068 100644
--- a/hello.c
+++ b/hello.c
@@ -1,6 +1,7 @@
 #include <stdio.h>

-int main(void)
+int
+main(int argc, char *argv[])
 {
   printf("Hello world\n");
   return 0;

> git commit -a -m "popravio main prototip"
[mirko 4e5f904] popravio main prototip
 1 files changed, 2 insertions(+), 1 deletions(-)

U međuvremenu, dolazi Slavko, vidi isti problem, ne zna da je Mirko radio na istoj stvari pa ga rješava kod sebe:

> git checkout slavko
Switched to branch 'slavko'

[...promjene hello.c...]

> git diff
diff --git a/hello.c b/hello.c
index 0bb4941..38586b0 100644
--- a/hello.c
+++ b/hello.c
@@ -1,6 +1,6 @@
 #include <stdio.h>

-int main(void)
+int main(int argc, char **argv)
 {
   printf("Hello world\n");
   return 0;

> git commit -a -m "prepravio definiciju funkcije main"
[slavko 4bb59be] prepravio definiciju funkcije main
 1 files changed, 1 insertions(+), 1 deletions(-)

Sve je dobro dok su promjene u zasebnim granama. No u jednom trenu ćemo željeti sve Mirkove i Slavkove promjene spojiti u master. Prva promjena će proći dobro, no na drugoj će nam se dogoditi konflikt.

> git checkout master
Switched to branch 'master'

> git merge mirko
git merge mirko
Updating 302ef80..4e5f904
Fast-forward
 hello.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

> git merge slavko
git merge slavko
Auto-merging hello.c
CONFLICT (content): Merge conflict in hello.c
Automatic merge failed; fix conflicts and then commit the result.

Uh, huh… obojica su mijenjala isto mjesto u istoj datoteci, i git ne zna kako riješiti problem. Zbog toga je merge pauziran i dana nam je prilika da riješimo konflikt. Pogledajmo što se dogodilo:

git diff
diff --cc hello.c
index 8b08068,38586b0..0000000
--- a/hello.c
+++ b/hello.c
@@@ -1,7 -1,6 +1,11 @@@
  #include <stdio.h>

++<<<<<<< HEAD
 +int
 +main(int argc, char *argv[])
++=======
+ int main(int argc, char **argv)
++>>>>>>> slavko
  {
    printf("Hello world\n");
    return 0;

> cat hello.c
#include <stdio.h>

<<<<<<< HEAD
int
main(int argc, char *argv[])
=======
int main(int argc, char **argv)
>>>>>>> slavko
{
  printf("Hello world\n");
  return 0;
}

Diff prikazuje obje nekompatibilne promjene. Prva je iz trenutne grane (odnosno to je ona Mirkova promjena koju smo uspješno preuzeli spajanjem Mirkove grane), dok je druga iz grane slavko. Rješimo konflikt modificiranjem tog dijela datoteke da izgleda onako kako mi želimo:

[...promjene hello.c...]
cat hello.c
#include <stdio.h>

int
main(int argc, char **argv)
{
  printf("Hello world\n");
  return 0;
}

> git diff
diff --cc hello.c
index 8b08068,38586b0..0000000
--- a/hello.c
+++ b/hello.c
@@@ -1,7 -1,6 +1,7 @@@
  #include <<tdio.h>

 -int main(int argc, char **argv)
 +int
- main(int argc, char *argv[])
++main(int argc, char **argv)
  {
    printf("Hello world\n");
    return 0;

> git add hello.c
> git commit
[master fd96bab] Merge branch 'slavko'

Diff prikaz u slučaju konflikata je pomalo zbunjujuć, no snalaženje u samoj datoteci koju treba popraviti je relativno jednostavno - konflikt je između <<<<<<< i >>>>>>>, a ======= razdvaja konfliktne promjene.

Konflikt prilikom rebaziranja

Kao što smo već prije vidjeli, obično želimo grane održavati tako da u svakom trenu njihove promjene budu primjenjive na master (odnosno na baznu granu gdje ih na kraju želimo spojiti), a jedan od razloga je upravo izbjegavanje konflikata kod spajanja.

Jedan od razloga zbog kojih je konflikt kod spajanja nezgodan je i činjenica da problem praktički “prebacujemo” onom tko radi merge, a kod većih projekata to je obično osoba koja održava projekt (tj. glavni developer). Ukoliko od nje tražite da granu sa vašim promjenama spaja sa masterom, a to izaziva konflikte kod mergea, zapravo ste prilično nepristojni.

Zato je bolje prije nego zatražite (ili krenete raditi) spajanje rebazirati svoju granu tako da samo spajanje bude čisto. To znači da ćete eventualne konflikte morati sami rješiti prilikom rebaziranja.

Vratimo se malo u prošlost i zaboravimo da smo radili merge Mirkove i Slavkove grane:

> git reset --hard 302ef80039bd55fbbc680d84e37e5ebcf7f63a5c
HEAD is now at 302ef80 dodan README

Mirko odluči spojiti svoju granu s masterom. Njegovu granu nije potrebno rebazirati jer se nastavlja na master (tj master nema nikakvih novih promjena):

> git merge mirko
Updating 302ef80..4e5f904
Fast-forward
 hello.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Slavko odluči spojiti svoju granu. Njegovu granu je potrebno rebazirati jer
master ima novih comittova:

> git checkout slavko
Switched to branch 'slavko'

> git rebase master
First, rewinding head to replay your work on top of it...
Applying: prepravio definiciju funkcije main
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging hello.c
CONFLICT (content): Merge conflict in hello.c
Failed to merge in the changes.
Patch failed at 0001 prepravio definiciju funkcije main

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

Ovo izgleda mnogo strašnije nego poruka kod mergea! Ali problem je isti, u što se možemo uvjeriti pomoću git diff (s tim da će umjesto imena naše grane biti naziv commita u našoj grani s kojim ima problema). Nakon što napravimo ispravke u datoteci, trebamo nastaviti proces rebaziranja:

[...promjene hello.c...]
> git add hello.c
> git rebase --continue
Applying: prepravio definiciju funkcije main

Ovdje nismo ručno radili git commit, nego smo nakon popravka nastavili proces rebaziranja. Kako rebaziranje ide commit po commit, ukoliko ima još konflikata u narednim commitovima, rebase bi se opet zaustavio i zatražio da popravimo stvari.

Ukoliko zaključimo da je commit nepotreban (npr. zato što je u drugoj grani taj problem već riješen), možemo ga odbaciti. Ako se radi o ozbiljnom problemu za kojeg ne znamo kako ga riješiti, možemo prekinuti rebase, a grana će nam se vratiti u prvobitno stanje. U tom slučaju ćemo vjerojatno morati rješavati merge konflikte prilikom spajanja i napraviti merge a ne rebase.

Do you pine for the nice days of linux 2.4, when men were men and wrote
their own device drivers? Are you without a nice project and just dying
to cut your teeth on a OS you can try to modify for your needs? Are you
finding it frustrating when everything works on linux? No more all-
nighters to get a nifty program working? Then this post might be just
for you :-)

As I tweeted a month(?) ago, I’m working on a free version of a
linux-lookalike for x86-64 computers. It has finally reached the stage
where it’s even usable (though may not be depending on what you want),
and I am willing to put out the sources for wider distribution. It is
just version 0.02 (+1 (very small) patch already), but I’ve successfully
run bash/gcc/gnu-make/gnu-sed/compress etc under it.

Sources for this pet project of mine can be found on github. The repo also
contains some README-file and a couple of binaries to work under it
(bash, update and gcc, what more can you ask for :-). Full kernel
source is provided, as no linux code has been used. Library sources are
only partially free, so that cannot be distributed currently. The
system is able to compile “as-is” and has been known to work. Heh.
Sources to the binaries (bash and gcc) can be found at the same place.

ALERT! WARNING! NOTE! These sources still need linux to be compiled
(and gcc, possibly gcc4, haven’t tested), and you need linux to
set it up if you want to run it, so it is not yet a standalone system
for those of you without linux. I’m working on it. You also need to be
something of a hacker to set it up (?), so for those hoping for an
alternative to linux, please ignore me. It is currently meant for
hackers interested in operating systems and x86-64’s with access to linux.

The system needs an IDE harddisk (sorry) and any VGA card. If
you are still interested, please read my blog post about it, and/or ask me
on Twitter for additinal info.

I can (well, almost) hear you asking yourselves “why?”. Next year (or the
one after it who knows) will be The Year Of Linux Desktop, and I’ve already got
Ubuntu. This is a program for hackers by a hacker. I’ve enjouyed doing
it, and somebody might enjoy looking at it and even modifying it for
their own needs. It is still small enough to understand, use and
modify, and I’m looking forward to any comments you might have.

Does this sound familiar to you? If you know your Linux history, is should - it’s a ripoff of the original Linux announcement post that Linus posted to the comp.os.minix newsgroup.

A few points to consider:

• look what a crazy (in a positive way) guy’s hobby did to the computer industry
• is kernel programming still fun? should it be? is it serious work now?
• is there still fun to be had in non-web related stuff?

Interaktivno dodavanje promjena

Prilikom rada na projektu, često ćemo da bi stvar uopće natjerali da radi morati napraviti nekoliko nezavisnih promjena, a tek onda biti sigurni da smo dobili dobar rezultat. Obično tek tada želimo napraviti commit, ali bismo htjeli da nezavisne promjene idu u nezavisne commitove. Ako se te promjene nalaze u istoj datoteci, običan git add nam ne pomaže jer bi on označio cijelu datoteku za commit.

U tom slučaju možemo koristiti interaktivno dodavanje. Ono nam pruža veću kontrolu nad time što dodajemo u commit, a i preglednije je (i pruža nam priliku za review napravljenoga prije commitanja), pa preporučam da ga uvijek koristite, čak i kad želite dodati sve promjene.

Recimo da smo napravili dvije nezavisne izmjene u hello.c. datoteci i želimo ih committati odvojeno (primjer radim u novoj test grani koju ću kasnije obrisati):

> git checkout -b test
Switched to a new branch 'test'

> git diff
diff --git a/hello.c b/hello.c
index 0bb4941..d560074 100644
--- a/hello.c
+++ b/hello.c
@@ -1,3 +1,4 @@
+#include <stdlib.h>
 #include <stdio.h>

 int main(void)
@@ -5,3 +6,9 @@ int main(void)
   printf("Hello world\n");
   return 0;
 }
+
+void unused(void)
+{
+  puts("I'm never used");
+}
+

> git add -p
diff --git a/hello.c b/hello.c
index 0bb4941..d560074 100644
--- a/hello.c
+++ b/hello.c
@@ -1,3 +1,4 @@
+#include 
 #include 

 int main(void)
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? y
@@ -5,3 +6,9 @@ int main(void)
   printf("Hello world\n");
   return 0;
 }
+
+void unused(void)
+{
+  puts("I'm never used");
+}
+
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? n

Ovo će označiti (tj. spremiti u index) samo prvu promjenu u datoteci za committanje. To možemo provjeriti sa git diff --cached:

git diff --cached
diff --git a/hello.c b/hello.c
index 0bb4941..c6efc61 100644
--- a/hello.c
+++ b/hello.c
@@ -1,3 +1,4 @@
+#include <stdlib.h>
 #include <stdio.h>

 int main(void)

Pregled promjena u datotekama

Nakon što neko vrijeme radite na projektu, većina datoteka unutar projekta
vjerojatno će biti mijenjana mnogo puta. Kako bi vidjeli koje promjene smo radili
nad jednom datotekom (ili direktorijem), možemo koristiti još jedan oblik
već poznate git log naredbe:

> git log hello.c
commit 5e547517e1a29a08b3594f6b8c8c0a289070376d
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:31:05 2010 +0100
popravljen kod

commit 04f3667425705d29f2c3a10bb45e79f5cc6b7d7d
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 05:49:59 2010 +0100
malo uljepsano

commit 6e70237aaa84a0c8ff74bd0fad6cccb4d118b695
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 05:49:03 2010 +0100
prva verzija

Ovaj ispis dobar je ako želimo kronološki pregled promjena. No često je slučaj
da nas zanima zašto je baš neki dio (trenutne) datoteke napisan tako je, tj. koji
je razlog za dodavanje (ili promjenu) pojedine linije unutar koda.

Pregled promjena po pojedinim linijama datoteke omogućuje nam git blame,
tako nazvan jer nam govori tko je odgovoran za pojedinu liniju datoteke i zašto:

> git blame hello.c
5e547517 (Senko Rasic 2010-01-23 06:31:05 +0100 1) #include <stdio.h>
5e547517 (Senko Rasic 2010-01-23 06:31:05 +0100 2)
5e547517 (Senko Rasic 2010-01-23 06:31:05 +0100 3) int main(void)
04f36674 (Senko Rasic 2010-01-23 05:49:59 +0100 4) {
04f36674 (Senko Rasic 2010-01-23 05:49:59 +0100 5)   printf("Hello world\n");
5e547517 (Senko Rasic 2010-01-23 06:31:05 +0100 6)   return 0;
04f36674 (Senko Rasic 2010-01-23 05:49:59 +0100 7) }

Popis za svaku liniju sadrži skraćeni ID commita, autora te datum promjene.
Nakon što identificiramo promjenu koja nas zanima, pomoću već poznate
git show naredbe možemo vidjeti i ostale detalje te promjene.

Označavanje (tagiranje) commitova

Naš “Hello World” projekt već ima praktički svu funkcionalnost koju želimo,
stoga je pravo vrijeme da napravimo naš prvi release. Osim što možemo napraviti
arhivu izvornog koda (kao tar.gz ili u nekom drugom formatu) i poslati je korisnicima
svog programa, korisno je i u samom repozitoriju označiti da smo napravili
release.

Kako bismo “zapamtili” da smo napravili release, možemo dodati oznaku (tag) na
trenutni commit. Kako svaki commit zna za sve koji su se dogodili prije njega,
ta oznaka poslužit će nam da bi na jednostavan način dolazili do stanja projekta
u raznim fazama razvoja, bez da pamtimo IDeve comittova.

Oznaka (tj. tag) je (pojednostavljeno) najobičniji “alias” na ID commita.
Postavljenu oznaku možemo koristiti praktički svugdje gdje moramo navoditi ID
commita. Možemo ga koristiti kako god želimo - najčešća praksa je obilježavanje
kad se dogodilo nešto značajno u projektu, kao što je release.

Tagirajmo release 0.1 našeg projekta. Kako release radimo iz master
grane, pripazit ćemo ne tagiramo commit u krivoj grani:

> git checkout master
> git tag -m "postavljamo tag" "helloworld-0.1"

tagove možemo pregledavati pomoću git tag -l, a brisati pomoću
git tag -d <ime_taga>.

Prilikom postavljanja oznake, možemo je i kriptografski potpisati (gpg-om,
uz korištenje gpg privatnog ključa za mail adresu koju koristimo kod rada
s repozitorijem), korištenjem opcije -s.

Sretni sa napravljenim releasom, krećemo dalje sa razvojem projekta. Verzija
0.1 je potpun program, ali mu nedostaje build sustav, zbog čega svaki put moramo
ručno pozivati kompilator. Namjera nam je to riješiti korištenjem make
alata.

Kreirajmo konfiguracijsku datoteku za make zvanu Makefile
(napomena: make je izbirljiv glede sintakse, stoga je bitno na određenim mjestima
koristiti tab umjesto razmaka, što je posebno naznačeno u ovom listingu):

CC = gcc
OBJS = hello.o
CFLAGS = -Wall -Werror -O3 -g

.PHONY: all clean

all: hello

hello: $(OBJS)
<tab>$(CC) $(OBJS) -o $@

%.o: %.c
<tab>$(CC) $(CFLAGS) -c $< -o $@

clean:
<tab>rm -f hello $(OBJS)

Dodajmo novostvorenu datoteku u projekt, repozicionirajmo doc granu
(pošto imamo novosti u masteru) i spojimo je natrag u master granu.
Pošto smo završili sa doc granom, na kraju je možemo i obrisati.

> git add Makefile
> git commit -m "dodan Makefile"
master b23a04b] dodan Makefile
 1 files changed, 17 insertions(+), 0 deletions(-)
 create mode 100644 Makefile

> git checkout doc
Switched to branch 'doc'

> git rebase master
First, rewinding head to replay your work on top of it...
Applying: dodan README

> git checkout master
Switched to branch 'master'

> git merge doc
Updating b23a04b..302ef80
Fast-forward
 README.txt |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README.txt

> git branch -d doc
Deleted branch doc (was 302ef80).

Pregršt novih promjena! Pogledajmo što smo sve izmjenili od zadnjeg releasea:

< git log helloworld-0.1..HEAD
commit 302ef80039bd55fbbc680d84e37e5ebcf7f63a5c
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:06:26 2010 +0100
dodan README

commit b23a04b47dbc1044d44d94ee0a5df967f8f1b26d
Author: Senko Rasic <senko@localhost>
Date:   Fri Feb 5 16:02:54 2010 +0100
dodan Makefile

Poput grana, tagove je moguće checkout-ati, čime se vraćamo u prošlost,
u stanje projekta kakvo je bilo u trenutku tagiranja. Vratimo se malo u prošlost
do naše verzije 0.1:

> git checkout helloworld-0.1
Note: moving to 'helloworld-0.1' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b 
HEAD is now at 5e54751... popravljen kod

Git nas upozorava da smo došli na commit koji nije zadnji u nekoj grani. Ukoliko
želimo raditi bilo kakve modifikacije na projektu od ove točke, moramo kreirati novu
granu u koju će one biti spremljene.

Razvojne i stabilne grane

Ovo nam daje dobru ideju - možemo kreirati novu granu s početkom u helloworld-0.1,
koja služi samo za “održavanje” postojećeg koda i ispravljanje pogrešaka, dok ćemo sav
novi razvoj na projektu raditi kao i do sada na masteru. Ovime se želimo
osigurati da imamo “stabilnu verziju” projekta u koju nam neće slučajno upadati i
nove stvari koje razvijamo na “razvojnoj verziji” projekta na master grani.

> git checkout -b helloworld-0 helloworld-0.1
Switched to a new branch 'helloworld-0'

Grana helloworld-0 sadrži commit tagiran sa ‘helloworld-0.1′ i
sve njegove prethodnike i predstavlja stanje projekta kakvo je bilo u trenutku
kada smo tagirali taj commit. Granu potom možemo koristiti samo za promjene na
stabilnoj/releasanoj verziji, dok nam master ostaje za novi razvoj.

Cherry-picking

Ponekad prilikom rada na novoj verziji uočimo i ispravimo pogrešku koja postoji
i u već releasanoj verziji. Iako bismo ispravke mogli napraviti posebno na obje
grane, jednostavnije je ispravak napraviti na jednoj (obično razvojnoj, tj.
masteru) i nakon toga istu zakrpu primjeniti i na drugu. Ukoliko ispravku radimo
na masteru, primjenjivanje zakrpe i na starije release grane se zove
backporting.

Da bismo napravili backport commita koji ispravlja neku grešku, ne možemo
koristiti niti merge niti rebase, jer oni preuzimaju sve commitove iz mastera.
U slučaju kada želimo izabrati samo jedan commit (ili nekoliko njih, ali ne
cijelu granu) iz jedne grane i primjeniti ga na drugu, možemo koristiti
git cherry-pick.

Korisnici verzije 0.1 našeg softvera su ogorčeni jer ručno moraju pokretati
gcc. Smatraju da je to bug, a kako mi već imamo rješenje u obliku Makefilea
u master grani, rješenje je jednostavno - backportati commit koji je dodao
Makefile i napraviti novi release na 0.* grani.

> git cherry-pick b23a04b47dbc1044d44d94ee0a5df967f8f1b26d
Finished one cherry-pick.
[helloworld-0 f60bcbd] dodan Makefile
 1 files changed, 17 insertions(+), 0 deletions(-)
 create mode 100644 Makefile

Traženi commit je preuzet u trenutnu granu. Preciznije, promjene
koje je traženi commit napravio su napravljene i spremljene i za trenutnu granu.
Ovo je bitno zbog toga što se ID commita mijenja - kao i kod rebasea, originalni
i cherry-pickani commitovi nisu isti. Ovisno o daljnjim promjenama koje radimo
na grani, možemo se naći u situaciji da granu više nije moguće rebazirati ili
spojiti sa masterom, odnosno trebali bi rješavati konflikte. Stoga bi trebalo
izbjegavati cherry-picking iz grane koju u budućnosti želimo spojiti sa trenutnom
granom.

Više o konfliktima te što napraviti kad vam se oni dogode pročitajte u slijedećem postu u ovom serijalu, za par dana…

Ovaj vikend se u Bruxellesu održava tradicionalna FOSDEM konferencija. Broj zanimljivih predavanja i prezentacija je ogroman (samo popis stvari koje bih želio poslušati zahtjeva da se kloniram par puta :), a osim toga bit će velik broj zanimljivih ljudi koji se bave različitim stvarima, štandova, … a ne smijemo zaboraviti niti belgijsku pivu :) Tako da mi je drago da ću i ove godine prisustvovati ovoj konferenciji.

Računajte na #fosdem tweetove (po uvjetom da gomile geekova ne preopterete wireless, što je obično slučaj :) te kasnije i blog post o stvarima koje su se meni osobno isticale na konfi.

IT Showoff

Slijedeći petak će se u prostoru FERa u Zagrebu održati prvi jubilarni IT Showoff, na kojem ću održati prezentaciju i demo o tome kako i zašto koristiti git. Sa sobom ću imati i N900 i laptop sa složenom razvojnom okolinom za Maemo, pa mi se slobodno javite ukoliko želite popričati o Maemu, N900 te razvoju softvera za ovaj sustav.

N900 na eHrvatska TV

Kad smo već kod N900, nedavno je ekipa iz eHrvatska TV napravila reportažu o ovom uređaju, Maemou i Linuxu u sklopu koje su i mene priupitali za par pitanja. Snimku reportaže možete pogledati na eHrvatska kanalu na YouTube-u.

Ovi pojmovi koriste se u većini (svim?) distribuiranim SCM sustavima, ali se ovdje situacija već dovoljno komplicira da različiti sustavi na ne posve identične načine pristupaju istom problemu. Zbog toga je ovaj post posve specifičan i priča o git-u. Ukoliko koristite neki drugi SCM, imajte na umu da je stvar slična, ali se pojedinosti vjerojatno podosta razlikuju.

Grananje (branch)

U našem hello world projektu zasad imamo samo jednu granu, master, na kojoj smo radili sve promjene. To nam je odgovaralo jer smo točno znali što želimo napraviti slijedeće i nismo imali potrebe raditi više stvari paralelno (ili eksperimentirati u više različitih smjerova odjednom).

No, sada bismo željeli početi pisati i dokumentaciju za projekt. Kako nam se promjene vezane uz dokumentaciju ne bi mješale sa eventualnim nevezanim promjenama koda koje ćemo možda htjeti raditi, dokumentaciju ćemo dodavati u posebnoj grani projekta koju ćemo na kraju spojiti u glavnu. Kreirajmo novu granu doc iz postojeće master grane i odmah se prebacimo u nju:

> git checkout -b doc master
Switched to a new branch 'doc'

Za početak ćemo samo kreirati datoteku README.txt i u nju staviti osnovnu informaciju o programu:

Ovo je tipični "Hello World" program pisan u C-u.

Dodajmo datoteku u repozitorij, napravimo commit, i pogledajmo što smo dobili:

> git add README.txt
> git commit -m "dodan README"
[doc 7bb37b0] dodan README
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README.txt
> git log
commit 7bb37b04d7eeb36dc91e60ef1d01e2648bb2e813
Author: Senko Rasic 
Date:   Sat Jan 23 06:06:26 2010 +0100
dodan README

commit 459b8bd04f3667425705d29f2c3a10bb45e79f5c
Author: Senko Rasic <senko@localhost>
Date:   Fri Dec 11 00:53:32 2009 +0100
malo uljepsano

commit ac3a48559de3b7f225ffa96c504a8586057fb4b9
Author: Senko Rasic <senko@localhost>
Date:   Fri Dec 11 00:38:16 2009 +0100
prva verzija

Kako smo granu doc stvorili iz grane master, ona je uključuje sve dosadašnje promjene. Ovaj prikaz nam nije previše koristan ukoliko želimo vidjeti samo razliku između trenutne grane i mastera. To možemo napraviti ovako:

> git log master..HEAD
commit 7bb37b04d7eeb36dc91e60ef1d01e2648bb2e813
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:06:26 2010 +0100
dodan README

Argumentom master..HEAD zatražili smo log svih promjena do zadnjeg commita u trenutnoj grani (HEAD) koje se ne nalaze u master grani. Osim od-do, parametar može biti i samo jedna oznaka, čime se traži log svih promjena od početka do te oznake. Tako će git log master prikazati log svih promjena na grani master bez obzira u kojoj smo grani trenutno. Oznaka HEAD uvijek pokazuje na posljednji commit u trenutnoj grani, pa je git log HEAD isto što i samo git log.

Dokumentiranje našeg programa dobro napreduje, ali paralelno s tim sjetili smo se da bi htjeli napraviti još neke kozmetičke promjene na programu. Na njima želimo raditi nezavisno o procesu dokumentiranja pa ćemo kreirati novu granu. Kako ne bi imali poluzavršenu dokumentaciju u novoj grani, novu granu beauty ćemo opet kreirati iz master grane:

> git checkout -b beauty master
Switched to a new branch 'beauty'

Trenutna inačica programa nije posve legalan C program, stoga ćemo je opet malo doraditi, tj. preraditi u nešto pristojnije:

#include <stdio.h>

int main(void)
{
  printf("Hello world\n");
  return 0;
}

Sada smo već napravili nekoliko grana i u svakoj po nekoliko commitova i sve je teže pratiti gdje se nalazi što. Podsjetimo se koje grane imamo i što one sadrže:

> git branch
* beauty
  doc
  master
> git log master..beauty
commit 5e547517e1a29a08b3594f6b8c8c0a289070376d
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:31:05 2010 +0100
popravljen kod

> git log master..doc
...
> git log master
...

Spajanje grana (merge)

Nakon što smo napravili sve što smo htjeli i sve committali te nakon što smo zaključili da smo zadovoljni promjenama na ovoj grani, željeli bismo je spojiti nazad u master.

Napomena: radi jednostavnosti primjera, ovdje nam se grana sastoji od samo jednog commita te ćemo je odmah spojiti nazad, što izgleda kao puno kompliciranja nizašto. No u stvarnom radu promjene obično nisu ovako trivijalne i grane se sastoje od nekoliko (možda desetke) committova, kod čega branch/merge ima smisla.

> git checkout master
Switched to branch 'master'
> git merge beauty
Updating 459b8bd..5e54751
Fast-forward
 hello.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Prilikom ovog mergea, master nije imao nikakvih dodatnih commitova kojih nema u beauty grani pa se git nije morao mnogo mučiti sa spajanjem - samo je napravio fast-forward odnosno zalijepio sve nove commitove iz beauty grane u master granu. Pomoću git log možemo se uvjeriti da se uistinu radi o istim committovima (jedinstveni ID im je jednak).

Spajanjem grana beauty nije nestala. Ona još uvijek postoji, iako sad kad su svi njeni commitovi i u masteru, nema razlike između nje i mastera - jednako kao da smo je tek sad kreirali. U daljnjem radu opet možemo koristiti istu granu i dodavati nove committove koje periodički spajamo nazad u master. Stvar je izbora (i specifične organizacije projekta na kojem radite) želite li imati dugotrajnije grane koje periodički spajate s masterom ili za nove promjene radite nove grane.

Ukoliko odlučimo da nam grana više ne treba, možemo je obrisati:

> git branch -d beauty
Deleted branch beauty (was 5e54751).

Repozicioniranje grana (rebase)

Sretni sa dosadašnjim napretkom na master grani, vraćamo se nazad na doc. No sada master ima neke comitove koje doc nema. Zasad nema problema, git bi comittove pametno spojio, no ukoliko i ubuduće mijenjamo master (tj. dodajemo nove comitove), razlika će se sve više povećavati i sve će veća biti vjerojatnost da (slučajno ili namjerno) negdje modificiramo istu stvar i uzrokujemo konflikt.

Kako bi to minimizirali, dugovječne grane možemo repozicionirati, tj. rebazirati (rebase). Rebaziranjem pomičemo točku u kojoj se grana “odvojila” od grane iz koje smo je stvorili (ovdje, mastera), tako da izgleda kao da smo je tek sada stvorili.

> git checkout doc
Switched to branch 'doc'
> git rebase master
First, rewinding head to replay your work on top of it...
Applying: dodan README

> git log
commit 6c0516dbe782173b57997039576e3b38bc20997c
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:06:26 2010 +0100
dodan README

commit 5e547517e1a29a08b3594f6b8c8c0a289070376d
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:31:05 2010 +0100
popravljen kod

Primjetite da je nakon rebaziranja “dodan README” comit ispao zadnji, iako je zadnja promjena koju smo mi stvarno na cijelom projektu napravili bio “popravljen kod” u beauty grani. Također, primjetite da se ID zadnjeg comitta promjenio - to zapravo više nije isti commit. Radi se o tome da je git doslovno pospremio patcheve, obrisao comittove, a kasnije ih vraćao jedan po jedan i automatski radio nove comittove.

repozicioniranje grane

Kao rezultat toga, grana doc više uopće ne izgleda isto. Ako solo radite na projektu, to za vas ne igra nikakvu ulogu. Ali ukoliko nekoliko ljudi radi na istom projektu, potreban je oprez - ukoliko je netko kod sebe povukao vašu granu, a vi ju naknadno rebazirate, stanje comittova u toj grani u vašem repozitoriju više se neće slagati sa stanjem u njihovom repozitoriju. Kod takvih situacija osnovno pravilo je - nikad ne modificirajte povijest grane koju je netko drugi već povukao od vas.

Merge ili rebase?

Nije odmah očito zašto bi radili rebase ako već imamo spajanje grana, no postoji razlika. Kod spajanja promjene iz druge grane “naljepe” se na trenutnu granu. Ukoliko dođe do konflikta, nemamo informaciju koji od comitova iz trenutne grane je uzrokovao konflikt. Stoga ga nećemo moći niti prepraviti, nego ćemo rješenje konflikta samo zalijepiti kao još jedan novi commit.

Spajanje logički znači “sav dosadašnji rad na grani koja se spaja sa trenutnom granom od sada se nalazi i u ovoj grani”. Ukoliko bismo koristili merge za povlačenje novih promjena mastera u doc, efekt bi bio kao da smo rekli “ok, od sada će nam doc biti glavna grana u projektu”.

Za razliku od toga, repozicioniranje znači “promjeni trenutnu granu tako da izgleda da sam sve promjene radio nad sadašnjim sadržajem mastera (odnosno granom nad kojom radim rebase - baznu granu)”, odnosno svojevrsno “osvježavanje patcheva” koje imamo u odnosu na master. Konkretno, rebase radi slijedeće:

1. privremeno miče sve comittove iz trenutne grane koji nisu u baznoj grani i sprema ih na sigurno
2. povlači sve nove comittove iz bazne grane koji nisu u trenutnoj (fast-forward), nakon čega bazna grana i trenutna grana imaju isti sadržaj
3. jedan po jedan vraća nazad comittove koji su spremljeni na sigurno

Ukoliko u nekom trenu dođe do konflikta, rebase će se zaustaviti i imat ćemo priliku prepraviti commit koji uzrokuje konflikt. Na taj način praktički “osvježavamo” trenutnu granu, tako da promjene koja ona predstavlja budu primjenjive na trenutno stanje bazne grane. Ovo nam omogućuje da imamo dugovječne grane sa relativno velikim promjenama u odnosu na baznu granu, a da te promjene uvjek budu ažurne.

Kada koristiti rebase ili merge možete pročitati i u Linusovom mailu o toj temi na LKML - “Some git best practices” post na LWN sadrži malo šire objašnjenje za nas koji ne pratimo LKML.

Join us next time…

Rukovanje granama je vjerojatno najbitniji i najkompliciraniji dio git-a. Nakon što smo to apsolvirali, možemo se opet baciti na laganije, a opet korisne stvari koje korisnicima gita život čine ugodnijim i lakšim. Pridružite mi se slijedeći put dok istražujem interaktivno dodavanje promjena, pretraživanje povijesti, tagiranje, cherry-picking, …

Since I got a great Christmas gift from Collabora I’ve been poking at a small toy application that could store and read Wikipedia articles offline. Since Wikipedia hosts a huge number of articles, and device capabilities are limited compared to a desktop PC, this posed an interesting (but not unsolvable) challenge for the weekend hack sessions.

The result is Mawire (Maemo Wikipedia Reader):

Mawire 0.1 - home screen

Mawire 0.1 - search results

Mawire 0.1 - Article view

The application

Having worked on bits and pieces in Maemo 5, I knew my way around the Maemo 5 SDK and some of the APIs, but nevertheless the Developer’s Guide was of great help. I’ve also perused examples, code (such as browser launcher) and packaging from marnanel’s raeddit application.

The application is a lightweight reader, so the aim is not to display complete article, but rather to show enough information for a quick check, and provide convenient way for the user to find more on the Wikipedia itself.

At the moment you can download the application from here, or browse or download the source code from github. I hope to upload it to maemo-extras soon. If you’re reading this from your N900, you can install mawire automatically by clicking on the install icon. Warning: It’s an early development (alpha) version, only tested on my device so far, so proceed with caution and only if you know what you’re doing.

Since writing this blog post (but before I hit the Publish button), I’ve played around with portrait mode functionality, and released version 0.2 which has portrait mode support. If your keyboard is closed, mawire will switch to portrait mode. When you slide it open at any time (e.g. for typing search queries, or when you want to copy/paste part of the article), mawire will switch to landscape mode.

Data handling

Since Wikipedia (especially the English edition) has a huge number of articles, amount of text for a complete and comprehensive copy is just too large to conveniently use on the device. Recent enwiki dump contains more than 3 million articles and is almost 6GB of bzip2′d XML.

To minimise database size, and since I wasn’t trying to replicate complete Wikipedia functionality, I decided to strip the articles as much as possible, not only of markup (so only bold and emphasis are preserved), but also to only include content of a few first paragraphs - up to the first heading. The idea is that topic overview is probably outlined first, and then each paragraph expands the coverage (often also having a complete article of its own).

So, the reader only includes the overview and provides “Read more…” button that connects to Wikipedia proper. So the app can be used not only as offline reader, but as quick Wikipedia launcher by itself.

The other problem is number of articles and search performance. If database contains up to a few million articles, sequential searching through the database is extremely slow. Unfortunately, the version of SQlite3 shipped on N900 (and indeed in many Linux distros ATM) doesn’t support fast fulltext search (FTS3), which is ideal for mawire.

So, the application currently ships with its own copy of SQLite library with enabled FTS3 module. It’s installed in a private lib directory so it doesn’t clash with the OS version (similar to what Firefox on Linux distros does), and is only ever used by mawire.

The data itself was prepared by a Python program that:

1. parses the XML dump (using expat),
2. extracts, parses and strips Wikipedia markup (using a bunch of hacked regexps, as I haven’t found a suitable wikimedia markup parser - this is the weakest part of the program and I hope to improve it in the future),
3. filters articles we want to exclude (special pages, lists of things, too short articles),
4. compresses the article text (using zlib) and finally stores them to a SQlite3 database (using SQLalchemy).

The final step is manual, building of FTS3 index, and consists of two SQL statements. This is so it could be done separately, on a machine having SQLite with FTS3.

The program is included in mawire source code, so you can use it to create custom Wikimedia databases (or, indeed, database for any MediaWiki powered wiki).

A database of selected articles (3000 most visited + featured + good + vital; about 14 thousand articles in total) from English Wikipedia (13.6MB). Database is installed in /opt so it doesn’t fill up your rootfs.

Complete English edition, as well as several other major language editions are also available, but I haven’t created Maemo packages for them. You can download them directly, put them on your device or MMC card and select from the application menu.

• English edition, complete (1.4GB)
• French edition, complete (313MB)
• German edition, complete (479MB)
• Russian edition, complete (289MB)
• Spanish edition, complete (288MB)
• Croatian edition, complete (31MB)

Jedno jednostavno rješenje je nadodati naše dijakritike na kombinacije Fn + kursorske tipke, na kojima po defaultu nema nikakvih drugih simbola. Kako naših dijakritika ima 5, osim kursorskih tipki možemo se poslužiti i BackSpace tipkom.

Kako bi layout bio što sličniji onom na normalnim tipkovnicama, na svojoj Nokii postavio sam ga tako da mi Fn+Up bude Š, Fn+BackSpace Đ (malo poetske pravde je u tome da je davno prije BackSlash bio Đ :), Fn+Left Č, Fn+Down Ć, Fn+Right Ž.

Kako biste to napraivli i kod sebe, morate biti u shellu i imati root privilegije, za što vam pomoći programčić zvan gainroot. Napomena: ovim lako možete dovesti svoju N900 u stanje da se ne može bootati, stoga budite pažljivi, ne radite ovo ako niste sigurni šta radite; ne odgovaram za bilo kakve nastale probleme.

Remapiranje tipkovnice radite editiranjem datoteke /usr/share/X11/xkb/symbols/nokia_vndr/rx-51. Prije editiranja datoteke, svakako napravite backup kopiju. Napomena: Backup kopiju nemojte spremati u isti direktorij, jer će vam se N900 odbiti bootati slijedeći put!

U datoteci pronađite liniju koja spominje <BKSP> (BackSpace tipka), i promijenite je u:

key <BKSP>   { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ BackSpace, dstroke ] };

Nakon toga na samom dnu datoteke pronađite blok xkb_symbols "arrows_4btns" i promijenite ga u (odlazak u novi red nakon znaka “=” je tu samo zbog čitljivosti u blog postu - u datoteci možete svaku definiciju staviti u svoj red):

xkb_symbols "arrows_4btns" {
    key <UP>   { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ Up, scaron ] };
    key <LEFT> { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ Left, ccaron ] };
    key <DOWN> { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ Down, cacute ] };
    key <RIGHT> { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ Right, zcaron ] };
};

(Update: popravio nazive simbola, originalno sam krivo postavio uglate zagrade).

Spremite datoteku i isprobajte odmah novi layout naredbom setxkbmap. Ukoliko vam naredba vrati grešku, popravite datoteku ili vratite backup - nemojte niti slučajno ostaviti nepravilnu datoteku, jer će vam se kod slijedećeg boota N900 odbiti podići.

Update: ispravio pogrešno napisan naziv komande, hvala Saši na dojavi.

Nakon uspješnog učitavanja novog layouta, naši dijakritici odmah su vam dostupni u svim aplikacijama, koristeći kombinaciju Fn+kursorske tipke ili backspace, za mala slova, odnosno Shift+Fn+tipke za velika slova.

Inspiraciju i sve potrebne informacije za post našao sam na Maemo wikiju, gdje možete pronaći još informacija o ovome i mnogim drugim hackovima za vašu N900.

Update: pripremljenu datoteku možete preuzeti ovdje. Datoteku skopirajte na gorenavedenu i svakako provjerite na goreopisan način (meni provjereno radi, ali ne garantiram da će i vama i ne snosim posljedice ako bude problema).

Editor - (G)VIM

Uza sve moje pokušaje i isprobavanja drugih editora, uvijek se vraćam VIM-u (odnosno njegovom grafičkom pandanu GVIM-u). Većina piskaranja koje radim je zapravo programiranje, za što je ovaj editor upravo idealan. Još uvijek sam na newb razini, ali svake godine upamtim par zgodnih shortcutova .. za jedno 20tak godina ću biti guru :) Mali demo što sve VIM može (otprilike polovicu ovoga još ne koristim .. kao što rekoh, newb sam) pogledajte u izvrsnoj Perl.Hacks.On.Vim prezentaciji.

Web browser - Google Chrome

Velika promjena u zadnje dvije godine - većina browser opcija sada je bazirana na WebKit engineu, a jedino se Firefox drži svojeg Gecka. Novi rat browsera koji se zahuktava u poslijednje vrijeme osigurao je da svi browseri budu mnogo kvalitetniji nego njihove starije inačice - Firefox više nikako nije neosporni vlasnik Linux desktop browser mindsharea.

Pri najavi Google Chrome browsera bio sam prilično nezadovoljan overhypeom koji je dotični doživio. Nakon izlaska bete za Linux, prebacio sam se par dana na nju i mogu zadovoljno reći da Googlovci nisu podbacili - browser je stvarno kvalitetan. Nakon tjedan-dva testiranja, sve svoje browsanje prebacio sam na Chrome. Zasad mi se subjektivno čini stvarno brži od Firefoxa (3.5). Koliko je stvar u činjenici da je Firefox opterećen raznoraznim ekstenzijama i alatima (jeste li znali da Firebug usporava JavaScript čak i na stranicama gdje nije upaljen?) a koliko u stvarnoj brzini enginea i rendera, vidjet ću s vremenom kad se i na Chromeu nakupi po par ekstenzija.

Jedna stvar koja mi se kod Chromea sviđa za razliku od Firefoxa je jednostavnost pisanja ekstenzija - jednostavne ekstenzije se mogu napisati u par desetaka linija JS-a, za razliku od mnoštva boilerplatea kojeg treba pripremiti za Firefox.

Kao lagano off-topic zanimljivost, napomenuo bih da iako koristim Google Chrome kao browser, ne koristim Google kao tražilicu (niti GMail, niti Google Docs, … koristim GMaps kad mi zatreba te GTalk iz Empathya); umjesto toga, koristim DuckDuckGo! zbog toga što mi daje preglednije, relevantne rezultate, a njihov 0-click info box je u većini slučajeva točno ono što me i zanima. U par mjeseci korištenja mislim da nisam više od 2-3 puta zatražio drugu “stranicu” rezultata. Mana DuckDuckGoa su slabiji rezultati za .hr prostor i slabiji rezultati ukoliko copy-pasteam neki dugački opis greške; za te stvari i dalje ručno odem na Google.

Grafičko sučelje - XMonad

Pomalo je depresivno da današnja računala subjektivno ne djeluju mnogo brža od računala koje smo koristili pred 5 ili 10 godina. Naravno da objektivno jesu mnogo brža - dovoljno je samo usporediti grafiku sadašnjih i tadašnjih igara, ili sadašnje multimedijske mogućnosti sa tadašnjim playbackom poštanskih maraka ili kockastih filmova niske rezolucije. Sama GUI sučelja su mnogo rafiniranija, sa više opcija, efekata i slično. Ali opet, pomalo je to depresivno.

Isprobavši par alternativa, otkrio sam da mi je od laganih rješenja najzgodniji XMonad, window manager pisan u Haskellu (isprobavanje XMonada pogodilo se vremenski sa čitanjem izvrsne Real World Haskell knjige o tom programskom jeziku). XMonad mi se učinio stvarno user-friendly, mnogo više od awesome WM-a pisanog napola u Lui, iz jednostavnog razloga što sam za awesome morao odmah editirati konfiguracijsku datoteku (i učiti Luu) dok za XMonad još uvijek nemam nikakvu konfig datoteku - stvar radi po defaultu točno ono što želim.

Kad sam već maknuo Metacity, rješio sam se i GNOME panela, a kako niti Nautilus ne koristim često, izbacio sam i njega. Da izbjegnem pokretanje gnome-sessions-daemona samo zbog gnome-screensavera, zamjenio sam i njega xscreensaverom, a kad već idem u tom smjeru, i gdm sam zamjenio xdm-om.

Networking - male shell skripte

Izbacivši GNOME Panel ostao sam i bez Network Managera (cnetworkmanager, komandolinijski alat, nije pretjerano korisna stvar). Srećom, Nikola mi je otkrio wicd, zamjenu za NetworkManager sa dobrim grafičkim i terminal klijentima. No zbog nekih problema drivera wireless kartice na svom laptopu, kod resumea treba reinicijalizirati driver pa sam cijelu stvar automatizirao sa par shell skripta i otkrio da mi je i sam wicd nepotreban.

Terminal - GNOME Terminal

Kako na kraju ispada da većinu stvari radim / pokrećem iz komadndne linije, bitno mi je da je terminal emulator lagan i brz. Kao pobjednik pokazao mi se GNOME Terminal, jer iako nije lagan po potrošnji memorije i prvom startupu, najbrži je u prikazu antialiasinih TrueType fontova (a od Inconsolate se ne odvajam).

E-mail - Thunderbird 3

Thunderbird 3 pokazao mi se kao odličan mail klijent - osim vidljivih unapređenja u odnosu na verziju 2 (bolji i brži search, tabovi, tagiranje), pokazao mi se kao mnogo bolji u hendlanju velikih IMAP foldera s kojima svakodnevno radim.

Media centar - XBMC

Da sam ovaj post pisao pred 3 tjedna, pod ovu stavku stavio bih Moovidu (nee. Elisa), vrlo dobar media centar baziran na GStreamer frameworku. No Moovida mi zna imati problema sa nekim formatima (ponajviše .mkv) i updateom librarya, a pogotovo sa hendlanjem velike količine fajlova u mojoj glazbenoj kolekciji (zbog čega trenutno koristim i remote kontrolirani Music Player Daemon). XBMC ne pati od tih boljki, također ima podršku za pluginove te mi se zasad ukupno čini kao bolji sustav.

Chat - Empathy

Kako sam jedan od developera na Telepathy projektu (kojeg je i Empathy client jedan dio), nije nikakvo čudo da mi je Empathy najdraži IM client. No otkad imam N900, više chatam sa njega (opet pogonjeno Telepathyem) nego sa laptopa…

Twitter - Chromed Bird

Rudimentaran, ali ima sve što meni treba (pregled svog timelinea, reply, retweet, skraćivanje linkova putem bit.ly-a). Neko vrijeme sam koristio Thwirl i poslije Gwibber, ali prvi mora učitati popriličan AIR runtime a drugi WebKit. Za razliku od njih, Chromed Bird nema praktički nikakvi dodatni load na sustav.

U prošlom postu pokušao sam objasniti zašto je korištenje nekog DVCSa dobra ideja, čak i ako jedini radite na projektu, čak i ako se ne bavite programiranjem.

Kako to izgleda u praksi, vidjet ćemo uz primjere korištenja git sustava. Git je vjerojatno najpopularniji DVCS danas - koriste ga Linux kernel (za kojeg je i napisan), X.Org, GNOME i mnogi drugi projekti. Osim git-a, popularni DVCSovi danas su mercurial (hg) (Python, Mozilla, OpenSolaris) i bazaar (bzr) (Ubuntu). Iako se pojedini pojmovi i način rada pomalo razlikuju od sustava do sustava, osnovna ideja je ista.

Za primjer projekta uzet ćemo Hello World program u C-u pod Linuxom. Osim samog programa (hello.c datoteka), projekt će sadržavati i Makefile datoteku za buildanje programa te README.txt sa uputama za program.

Inicijalizacija repozitorija

Kako tek započinjemo s projektom, kreirat ćemo novi prazni direktorij hello i u njemu inicijalizirati prazan git repozitorij (u mom primjeru, projektni direktorij kreirao sam u home (~) direktoriju):

> mkdir hello
> cd hello
> git init
Initialized empty Git repository in ~/hello/.git/

Git sve svoje podatke sprema u poddirektorij .git vašeg projekta. Za razliku od SVN-a, koristi se samo jedan za cijeli projekt, a ne po jedan za svaki direktorij unutar vašeg projekta.

Ukoliko ste već prije započeli rad na projektu, a želite početi koristiti git na njemu, možete pokrenuti git init izravno u direktoriju projekta. Ukoliko želite raditi sa repozitorijem nekog projekta koji već koristi git, originalni repozitorij možete klonirati i onda raditi na svom klonu. Primjer za Empathy (GNOME chat client):

> cd /tmp
> git clone git://git.collabora.co.uk/git/empathy.git
Initialized empty Git repository in /tmp/empathy/.git/
....

Committanje

Jednom kad ste inicijalizirali projekt (na bilo koji način), možete raditi promjene i spremati ih. Kreirajmo datoteku hello.c i u nju spremimo prvu verziju našeg Hello World programa:

void main() { printf("Hello world\n"); }

Brza provjera pokazuje da se stvar kompajlira uz neka upozorenja. Za početak smo zadovoljni pa želimo spremiti prvu verziju. Da bi to napravili, gitu moramo reći da mora voditi računa o datoteci hello.c te da smo je upravo promijenili:

> git add hello.c

Napomena: ovaj add ne znači da smo datoteku dodali u repozitorij, nego smo datoteku označili za spremanje u slijedećem commitu. Pošto datoteka još nije bila spremana u repozitoriju, prilikom commita će biti stvorena. Napravimo commit sa komentarom “prva verzija” (ukoliko ne dodate komentar u komandnoj liniji, otvorit će vam se editor pa se možete raspisati do mile volje):

> git commit -m "prva verzija"
[master (root-commit) ac3a485] prva verzija
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 hello.c

Git nam govori da je spremio prvi commit u master granu (branch). Master grana uvijek postoji u git repozitoriju (osim ako radite čudne stvari :) te se automatski stvara kod inicijalizacije novog repozitorija ili kloniranja postojećeg, te je po defaultu aktivna.

Pogledajmo što zasad sve imamo spremljeno u master grani:

> git log
commit ac3a48559de3b7f225ffa96c504a8586057fb4b9
Author: Senko Rasic <senko@localhost>
Date:   Fri Dec 11 00:38:16 2009 +0100
prva verzija

Ovaj čudan niz znakova u prvoj liniji je jedinstveni ID commita. Kada želite pregledavati pojedine committove, vraćati se natrag u prošlost, preuzimati committove iz jedne grane u drugi i slično, obično trebate koristiti ovaj ID. Ne brinite, ne trebate ga ručno utipkavati cijelog - git je dovoljno pametan da ga prepozna iz prvih par znakova (bar 4, ali ukoliko ima više committova koji počinju sa istim znakovima, onda možete specificirati i više znakova). Pogledajmo detalje ovog što smo upravo spremili:

> git show ac3a
commit ac3a48559de3b7f225ffa96c504a8586057fb4b9
Author: Senko Rasic <senko@localhost>
Date:   Fri Dec 11 00:38:16 2009 +0100

prva verzija

diff --git a/hello.c b/hello.c
new file mode 100644
index 0000000..d08059a
--- /dev/null
+++ b/hello.c
@@ -0,0 +1,2 @@
+void main() { printf("Hello world\n"); }
+

Commit se sastoji od jedinstvenog ID-a, različitih polja (najčešća su Author i Date, ali može ih biti još), poruke koja opisuje što se napravilo (može biti jedan ili više redova), te same promjene u diff formatu. U ovom slučaju kreirali smo novu datoteku pa u diffu piše da je prethodna verzija bila /dev/null :)

Da biste pogledali zadnji commit, ne morate navoditi njegov ID. Tako smo istu stvar mogli napraviti i samo pozivanjem git show.

Work tree, staging area

Krenimo dalje sa našim projektom. Prva verzija datoteke nije baš reprezentativni C kod, pa ćemo je malo uljepšati. Editirajmo hello.c da izgleda ovako:

void main(void)
{
  printf ("Hello world\n");
}

U ovom trenutku u našem radnom direktoriju (work tree) postoje promjene koje još nismo pospremili. Nepospremljene promjene možemo vidjeti u diff formatu:

> git diff
diff --git a/hello.c b/hello.c
index d08059a..145804e 100644
--- a/hello.c
+++ b/hello.c
@@ -1,2 +1,4 @@
-void main() { printf("Hello world\n"); }
-
+void main(void)
+{
+  printf ("Hello world\n");
+}

Ukoliko je promjenjeno više datoteka, razlike za pojedinu datoteku (ili pojedini direktorij) možemo vidjeti navodeći njeno ime: git diff hello.c. Primjetite da će git diff pokazati promjene samo u datotekama koje prati, odnosno one za koje ste mu rekli da su dio repozitorija. Čim datoteku jednom označite sa git add, git će je pratiti (sve dok je ne obrišete sa git rm). Pregled stanja radnog direktorija, s popisom promjenjenih praćenih(tracked) i popisom nepraćenih (untracked) datoteka možemo vidjeti sa git status.

Označimo datoteku za spremanje:

> git add hello.c
> git diff
> git diff --cached
diff --git a/hello.c b/hello.c
index d08059a..145804e 100644
--- a/hello.c
+++ b/hello.c
@@ -1,2 +1,4 @@
-void main() { printf("Hello world\n"); }
-
+void main(void)
+{
+  printf ("Hello world\n");
+}

Nakon označivanja za spremanje, git diff više ne prijavljuje nikakve razlike! To je zbog toga što su razlike sada u pripremi za commit (staging area). Pripremljene razlike možemo vidjeti sa git diff --cached. Ukoliko smo nešto zeznuli pa ne želimo napraviti commit nad njima, git reset miče promjene nazad iz staging area i možemo ih nakadno opet označiti za spremanje. Napomena: git reset, ukoliko dodate još neke parametre (npr. –hard koji briše promjene i iz radnog direktorija, ili id committa, koji vas “vraća” na taj commit i briše sve naknadne promjene), može biti vrlo opasna po vaše podatke. Prilikom eksperimentiranja svakako pročitajte manual za git-reset.

Ukoliko samo želite označiti sve promjenjene datoteke (koje su dodane u repozitorij, tj. git ih prati) i napraviti commit svih njih, to možete učiniti ovako:

> git commit -a -m "malo uljepsano"
git commit -a -m "malo uljepsano"
[master 459b8bd] malo uljepsano
 1 files changed, 4 insertions(+), 2 deletions(-)

Uz ove osnove možete već početi raditi sa repozitorijom, spremati i pregledavati svoje promjene, ali zasad se git ne čini previše različitim od CVS-a ili SVN-a. U slijedećem postu bacit ćemo se na zanimljivije stvari - branching, merging, rebasing. Stay tuned :)

DVCS For The Win

Ukoliko je odgovor da, vjerojatno koristite neki sustav za rukovanje različitim verzijama vašeg uratka, pa makar to bili to direktoriji nazvani “novo”, “novije-2″, “staro-prošli-tjedan”. Moguće je da već i koristite neke od mnogobrojnih VCS / SCM sustava; no, podržava li sustav koji koristite i distibuiran rad?

Čak i ako sami radite na projektu i nitko nikada neće vidjeti ništa osim finalnog proizvoda, isplati se koristiti distribuirani sustav za verzioniranje projekta (DVCS - Distributed Version Control System) — osim jednostavnosti zbog toga što nije potrebno konfigurirati i spajati se na centralni repozitorij (čak i ako on bio na vašem lokalnom disku), DVCS-ovi vam pružaju nešto mnogo više, a to je puno, puno veća sloboda u eksperimentiranju na vašem projektu.

A kod kreativnog rada gdje možete imati mnogo draftova koje kombinirate, bacate u zaborav, vučete nazad iz ladice, slažete jedne preko drugih i na kraju dobijate konačan proizvod, ta sloboda u eksperimentiranju je ključna.

Što ne valja kod klasičnih sustava…

Kod klasičnih sustava (u koje spada i “kreiram-backup-direktorije-svako-malo” ad-hoc pristup), princip čuvanja verzija je linearan. Imate neku početnu verziju vašeg uratka, napravite promjene na njoj i kad ste zadovoljni pospremite novu verziju negdje na sigurno (npr. commit na server ili novi backup dir). Ukoliko kasnije saznate da ste nešto zeznuli, uvijek se možete vratiti na raniju spremljenu verziju, odnosno imate beskonačni undo.

Ali, jednom kada se vratite u prošlost (odlučite da novija verzija ne valja) i krenete drugim smjerom (kreirate novu granu projekta), praktički ste prisiljeni baciiti sve načinjene promjene u smeće, čak i ako dio njih još uvijek ima smisla. U teoriji vi možete iz zadnje verzije izvući dio promjena koji želite sačuvati i onda to primjeniti na novu granu. U praksi, svatko tko je radio netrivijalne SVN mergeove ili ručno kopirao izrezani dizajn i onda prepravljao da paše po drugom layoutu zna da to nije nimalo zabavan posao. U praksi, vi ručno morate napraviti posao koji bi VCS trebao moći napraviti za vas.

Zbog toga, najčeće se commitovi rade jednom kad ste prilično sigurni da je stvar ono što bi htjeli da bude. Rezultat toga je da se commit više koristi kao checkpoint, tj. pamti se trenutak u kojem je draft u “dobrom stanju”. Odnosno, promjene imeđu commitova su velike i često uključuju detalje koji nemaju nužno veze jedni s drugim, ali ste ih mijenjali u istom vremenskom periodu pa su eto završili zajedno.

… i kako distribuirani sustavi to popravljaju

Za razliku od toga, DVCS-ovi počinju od pretpostavke da postoji puno različitih grana u kojima se projekt neovisno razvija (jedan developer ima bar po jednu granu na kojoj on ili ona radi). Zbog toga si DVCS-ovi daju mnogo truda da osiguraju da se promjene jednog developera mogu jednostavno i sigurno kombinirati sa promjenama drugih, odnosno da se različite grane projekta mogu na siguran način mergeati.

Kako bi to osigurali, DVCS-ovi traže što manje promjene iz commita u commit, jer su male promjene puno manje ovisne o globalnom stanju u kojem je vaš projekt - ovise samo o nekoliko “susjednih” stvari (npr. nekoliko linija ispred i iza promjene u programskom kodu). Na taj način i developere “tjeraju” da promjene spremaju što ćešće i da međusobno neovisne promjene spremaju u različitim committovima.

Isto vrijedi i za vas kao solo developera na projektu. Filozofija DVCS-a je da za svaku ideju u projektu imate po jednu granu, u kojoj onda promjene nižete u puno commitova od kojih svaki sadrži malu promjenu. Ukoliko imate nekoliko stvari (ili alternativa iste stvari) na kojima radite u isto vrijeme, imat ćete nekoliko grana u repozitoriju. Ukoliko se tijekom razvoja pokaže da bi vam u jednoj grani dobro došle promjene koje ste već napravili za drugu granu, jednostavno “povučete” dotične commitove i automatski primjenite njihove promjene.

Odnosno, kod DVCS-ova grane projekta (branches) preuzimaju ulogu koju kod klasičnih VCS-ova imaju committovi. DVCS-ovi comittovi su, pak, dovoljno mali da ih je puno lakše preslagivati i kombinirati — ukoliko i dođe do konfliktalakše je izolirati problem i popraviti ga.

Kako organizirati repozitorij

Ukoliko ste novi u korištenju DVCS-a (ili čak klasičnih VCS-ova), sve ovo vam vjerojatno zvuči prilično zakomplicirano. Evo nekoliko općenitih savjeta kako jednostavno organizirati repozitorij za solo rad:

Za trenutni “dobar” draft (stanje s kojim ste zadovoljni i koje dalje nadograđujete - ono što biste zadnje skopirali u backup direktorij da sve to radite ručno) obično se koristi zasebna grana zvana master. Master je dakle početna točka za promjene koje radite.

Za svaku ideju, dodatak funkcionalnosti, bugfix, alternativu …., koju planirate, otvorite novu granu u kojoj ćete raditi samo na tome. Grana se kreira “grananjem” od mastera. Nakon što napravite par promjena u grani, ona će imati nekoliko comittova više od mastera (tj. sve comittove od prije + par novih koje ste napravili).

Kad ste zadovoljni sa promjenama koje ste napravili (npr. napisali ste i istestirali bugfix za vaš kod), granu spajate nazad u master, tj radite merge. Sustav će to napraviti tako da će uzeti sve comittove koji postoje u vašoj grani i redom ih zalijepiti na master. Ukoliko dođe do konflikta, trebat ćete popraviti samo zeznuti commit.

Da biste minimizirali mogućnost konflikta, trebate samo paziti na nekoliko stvari: da pojedini committovi budu što manji (i stoga što manje ovisini o ostatku koda), da pojedine grane ne rade promjene na istom mjestu (odnosno, ako rade, da koriste isti commit a ne zasebne committove za istu stvar) te da razlika između pojedine grane i mastera bude što manja.

Ovo zadnje zvuči kontra-produktivno - koji je smisao grane ako se ne smije (mnogo) razlikovati od mastera? Ne brinite, dugovječne i velike grane su sasvim česta pojava. Nema nikakve opasnosti da grana ima mnoge committove kojih nema u masteru - kod mergea će se oni samo zalijepiti na mastera i gotovo. Problematični dio su committovi kojih ima u masteru, a nema u dotičnoj grani - ova situacija događa se kad imate više grana pa jednu mergeate u master - ostale grane nemaju committove koje je ta grana sadržavala.

Stoga, da bi se smanjila mogućnost konflikta, ili bar olakšalo njegovo rješavanje, u dugovječnim granama treba s vremena na vrijeme povući u granu nove committove koji su došli u master. To se obično naziva rebase, a radi se tako da se privremeno maknu svi committovi iz grane, povuku se nove stvari iz mastera, a na kraju se committovi iz grane vraćaju jedan po jedan. Na taj način dobija se efekt kao da je grana kreirana iz trenutnog mastera.

Napomena: terminologija i organizacija razlikuju se ponešto od sustava do sustava; npr. neki nemaju više grana u jednom repozitoriju nego je svaka grana repozitorij za sebe. Ali osnovna ideja i način rada isti je za bilo koji od DVCS-ova.

Za kraj, najava

Ako ste nakon svega ovog pomalo (ili malo više od malo) zbunjeni, ne brinite. Stvar u praksi nije toliko komplicirana kako se čini (a moguće da sam je i ja komplicirano objasnio, primam sugestije u komentarima :). Stoga ne propustite slijedeći post u kojemu ću proći kroz osnove korištenja DVCSa koristeći kao primjer git, vjerojatno najpopularniji distribuirani VCS.

kako to izgleda kad zakomplicirate stvari ;-)