Git tutorial

În timp ce citeam un eseu despre Luceafărul, am văzut că Eminescu a prelucrat poemul în 5 variante succesive și am început să mă gândesc ce sistem de versionare folosea. Sigur nu era așa de eficient ca și Git.

Git e un sistem de versionare dis­tribuită, dezvoltat de Linus Torvalds în 2005 când acesta s-a plictisit de a tot colabora cu câteva mii de oameni la kernelul Linux prin fișiere .tar și patchuri.

De ce ar folosi cineva un sistem de versionare?

Pentru că omu' e prost și greșește. Face o schimbare într-un fișier, salvează și a doua zi își dă seama că nu trebuia să șteargă și să rescrie jumate din textul acela. Se poate face și cu toporul de piatră, moștenit de la strămoșii „ne­an­der­tal­i”, făcând copii cu mânuța de fiecare dată când facem vreo schimbare majoră, dar omu' tot greșește.

Ok, ok, îmi trebuie un sistem de versionare. Dar sunt o mulțime: SVN, Mercurial, Bazaar, Vi­su­al­Source­Safe, Darcs, CVS, etc. De ce tocmai Git?

Pentru că ... dați un search pe Google și găsiți o droaie de motive. E rapid, are branching, are staging area, etc. etc. Discutabil. Îi aceeași chestie ca și Vi vs Emacs, Windows vs restu: cui ce îi place și cu ce îi obișnuit.

Dar Git are un element care consider eu că îl difer­enți­ază: GitHub. Pentru proiect open-source e absolut cel mai tare server cen­tral­izat pentru dis­tribuire. Și Mercurial are Bitkeeper, SVN are Source­Forge, dar pe GitHub e super simplu să faci fork, scrii un patch și apoi ceri un pull-request. Câte linkuri ați văzut cu chestii de genul pentru BitKeeper sau Source­Forge? Eu cred că de vreo 2 ori m-am întâlnit cu așa ceva. Pe GitHub în schimb găsești mii de proiecte open-source geniale, la care de­vel­operii au pe blog/Facebook/etc „Con­tribute to the project. Fork us on GitHub”. Și poți comenta pe branchuri, taguri, chiar și pe linii de cod. Și aici s-a descoperit cea mai comentată liniede cod EVER (și posibil cel mai fail typo).

În sfârșit, să trecem la cea mai importantă chestie: cum folosim Git?

Mă voi referi doar la instalarea și folosirea sub Windows. Dacă folosești Linux, se presupune că ești destul de geeky să te descurci cu man pages, iar dacă folosești Mac OS X, folosește superbul App Store pentru a instala. Folosirea îi cam la fel oricum

În primul rând, îl instalăm. Bucată de tort: http://code.google.com/p/gi­tex­ten­sions/. Git Extensions e un program GUI prin care se poate face cam orice în Git. Dacă vreți să folosiți Git prin acest program, just click the buttons. Merge foarte bine și așa (așa am folosit eu timp de 5 luni GitHub). Totuși, dacă vrem să facem chestiile un pic mai old-school, pentru o flex­i­bil­i­tate mai mare, atunci ajungem la linia de comandă.

Apoi, ne setăm numele și eventual adresa de email:

> git config --global user.name rolisz 
> git config --global user.email yahoo@rolisz.ro

Configurăm editorul de texte favorit (din start îi Vim, mie îmi place Notepad++):

> git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

Acum puteți verifica dacă s-au salvat con­fig­urările cu:

> git config --list

Ar trebui să apară toate opțiunile setate și încă câteva proprii.

Să presupunem că avem în D: un folder numit Proiect, care are 2 fișiere: release.txt, nogit.txt. Nu prea contează ce scrie în fișiere.

Creăm un repository în folderul Proiect:

> cd /D D:Proiect  
> git init  
Initialized empty Git repository in D:/Proiecte/.git/

Acuma o să vedeți în folderul Proiect un folder ascuns „.git”. Acesta conține toate chestiile legate de acest repository. Vă atingeți de el doar cu un băț de 2m și după ce ați făcut o copie, pentru că probabil îl veți strica.

Să ne verificăm statutul repository-ului:

> git status  
# On branch master  
#  
# Initial commit  
#  
# Untracked files:  
#   (use "git add ..." to include in what will be committed)  
#  
#   nogit.txt  
#   release.txt  
nothing added to commit but untracked files present (use "git add" to track)

Git vede că sunt prezente câteva fișiere, dar încă nu le-a adăugat la lista internă de fișiere pe care trebuie să le versioneze. Pentru a adăuga fișierele în „staging area”:

> git add release.txt  
> git status  
# On branch master  
#  
# Initial commit  
#  
# Changes to be committed:  
#   (use "git rm --cached ..." to unstage)  
#  
#   new file:   release.txt  
#  
# Untracked files:  
#   (use "git add ..." to include in what will be committed)  
#  
#   nogit.txt

Pentru a adăuga toate fișierele se poate folosi *, se pot folosi patternuri pentru a adăuga fișiere, etc. Add are o listă lungă de opțiuni. Dar ce facem cu fișierul nogit.txt? Să presupunem că acesta este ceva fișier generat automat de compilator, și nu vrem să fie versionat de Git și nici nu vrem să îl excludem manual de fiecare dată. Aici vine fișierul .gitignore:

> echo. > .gitignore 
> echo nogit.txt >> .gitignore 
> git add .gitignore 
> git status 
# On branch master 
# 
# Initial commit 
# 
# Changes to be committed: 
#   (use "git rm --cached ..." to unstage) 
# 
#   new file:   .gitignore 
#   new file:   release.txt 
#

(Trebuie două comenzi de echo pentru că prima linie din fișierul .gitignore trebuie să fie goală și CLI din Windows... așa acceptă doar new line.) Am adăugat fișierul .gitignore la staging area pentru că, de obicei, e util, mai ales dacă lucrezi în echipă, e bine să aveți cu toții aceleași fișiere ignorate. Și acum, să facem primul commit:

> git commit -m "First Release" 
[master (root-commit) 618cc06] First Release  2 files changed, 3 insertions(+), 0 deletions(-)  
    create mode 100644 .gitignore  
    create mode 100644 release.txt

Parametrul -m e opțional, și, dacă nu e folosit, atunci se va deschide Notepad++ și veți scrie acolo mesajul de commit. Și cu asta aveți prima versiune a fișierelor voastre în Git.

Urmează: revenirea la versiuni anterioare, branch-uri, compararea ver­si­u­nilor, tagging. Când? Probabil după proba de română la Bac :D