commonmarker 0.0.1 → 0.1.0

data/test/progit/ro/01-introduction/01-chapter1.markdown

@@ -0,0 +1,257 @@
+# Introducere #
+
+În acest capitol vom discuta despre cum să facem primii pași cu Git. Vom începe cu începutul, și anume, prin a explica câteva detalii despre controlul versiunilor, apoi vom continua prin a arăta cum instalăm Git pe sistemul dumneavoastră și în final cum să începem să lucram cu el. La finalul acestui capitol ar trebui să înțelegeți de ce Git este folosit, de ce ar trebui sa îl folosiți și ar trebui ca totul să fie pregătit pentru utilizare.
+
+## Despre Controlul Versiunilor ##
+
+Ce este de fapt controlul versiunilor, și de ce ar trebui să ne pese? Controlul versiunilor este un sistem care înregistrează schimbările dintr-un fișier sau o mulțime de fișiere de-a lungul timpului astfel încât putem reveni la anumite versiuni mai târziu. Pentru exemplele din acestă carte veți folosi cod sursă ca și fișiere ce se află în sistemul de versionare, cu toate că în realitate puteți face asta pentru aproape orice tip de fișier de pe un calculator.
+
+Dacă sunteți un designer web sau de grafică și doriți să vă păstrați fiecare versiune a unei imagini sau fiecare paginare creată (pe care mai mult ca sigur o doriți), un Sistem de Control al Versiunilor (SCV, VCS [en]) este un lucru foarte util în munca zilnică. Acesta vă va permite să reveniți la o stare anterioară, să comparați schimbările de-a lungul timpului, să vedeți cine a făcut ultima modificare ce poate cauza o problemă, cine a introdus o anumită problemă și când, și multe altele. Folosind un VCS mai înseamnă în general că dacă reușiți totuși să stricați lucruri sau să pierdeți fișiere, veți putea recupera cu ușurință datele inițiale. În plus, obțineți toate acestea cu un minim de resurse suplimentare.
+
+### Sisteme Locale pentru Controlul Versiunilor ###
+
+Metoda aleasă de mulți pentru controlul versiunilor este de a copia fișierele în alt director (poate chiar un director care conține data în nume, dacă sunt isteți). Această abordare este foarte comună pentru că este atât de simplă, dar în același timp este foarte susceptibilă la erori. Este atât de ușor să uitați în care director lucrați în prezent și din neatenție să scrieți în fișierul incorect sau să suprascrieți fișiere ce nu intenționați să schimbați.
+
+Pentru a trata această problemă, programatorii au dezvoltat cu mult timp în urmă sisteme locale pentru controlul versiunilor (VCS locale) care conțineau o bază de date simplă ce ținea toate schimbările fișierelor aflate sub controlul versiunilor (vezi Figura 1-1).
+
+Insert 18333fig0101.png 
+Figura 1-1. Diagramă pentru controlul versiunilor local.
+
+Unul dintre cele mai populare unelte VCS era un sistem denumit rcs, care este încă distribuit cu multe calculatoare și astăzi. Până și popularul sistem de operare Mac OS X include comanda rcs atunci când instalați Uneltele de Dezvoltare. Acest utilitar practic funcționează prin menținerea mai multor mulțimi de patch-uri ("petice" [ro], care reprezintă de fapt diferențele dintre fișiere) de la schimbare la alta într-un format special pe disc; apoi utilitarul poate recrea cum arăta un anumit fișier la un anumit moment de timp prin adăugarea tuturor patch-urilor.
+
+### Sisteme Centralizate pentru Controlul Versiunilor ###
+
+Următoarea mare problemă pe care oamenii o au este necesitatea de a colabora cu alți dezvoltatori din alte sisteme. Pentru a face față acestei probleme, au fost dezvoltate Sisteme Centralizate de Controlul Versiunilor (SCCV, CVCS [en]). Aceste sisteme, cum ar fi CVS, Subversion, și Perforce, au un singur server care conține toate fișierele aflate sub controlul versiunilor, și un număr de clienți care preiau (check out [en]) fișiere din acea locație centrală. Timp de mulți ani, acesta a reprezentat standardul sistemele pentru controlul versiunilor (vezi Figura 1-2).
+
+Insert 18333fig0102.png 
+Figura 1-2. Diagramă pentru controlul versiunilor centralizat.
+
+Acest model oferă multe avantaje, în special pentru sistemele locale de versionare. De exemplu, oricine știe până la un anumit punct ce face într-un proiect orice altcineva. Administratorii au un control foarte exact asupra ce poate face un anumit utilizator; în același timp fiind mult mai ușor de administrat un CVCS decât lucrul cu baze de date locale fiecărui client.
+
+Totuși, acest model are și niște dezavantaje serioase. Cel mai evident este legat de un singur punct slab care este reprezentat de serverul central. Dacă acel server se oprește timp de o oră, în acea perioadă nimeni nu mai poate colabora cu nimeni altcineva sau nu poate salva schimbările făcute în cadrul proiectului la care lucrează. Dacă hard discul bazei de date centrale se defectează, și nu există un back-up consistent, se poate ajunge la situația de a pierde totul - întreaga istorie a proiectului cu excepția lucrurilor curente pe care unii membrii ai proiectului le pot avea pe stațiile de lucru locale. Sistemele locale de versionare suferă de aceleași probleme - oricând avem întreaga istorie a unui proiect într-un singur loc, riști să pierzi totul.
+
+### Sisteme Distribuite pentru Controlul Versiunilor ###
+
+Acum este momentul în care Sistemele Distribuite pentru Controlul Versiunilor (DVCS [en]) își fac apariția. Într-un DVCS (cum ar fi Git, Mercurial, Bazaar sau Darcs), clienții nu doar preiau ultima versiune a fișierelor: ei descarcă o copie completă a repository-ului. Deci chiar dacă orice server se defectează, și aceste sisteme colaborau prin intermediul lui, oricare din repository-urile de la client pot fi copiate înapoi pe server pentru a-l aduce la starea inițială. Fiecare checkout este efectiv un backup complet a tuturor datelor (vezi Figura 1-3).
+
+Insert 18333fig0103.png 
+Figura 1-3. Diagramă cu sistemul distribuit al versiunilor.
+
+Mai mult, multe din aceste sisteme se descurcă suficient de bine cu lucrul simultan cu mai multe repository-uri, așă că putem colabora cu diferite grupuri de oameni în diverse moduri în același timp în cadrul aceluiași proiect. Aceasta ne permite să ne configurăm diverse modele de lucru care nu sunt posibile în sistemele centralizate, de exemplu un model ierarhic.
+Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
+
+## O Scurtă Istorie a Git ##
+
+Ca și cu multe alte lucruri bune din viață, Git a început cu puțină distrugere creativă și multe controverse. Kernelul Linux este un proiect open source cu o gamă de aplicabilitate destul de mare. În marea parte a vieții proiectului (1991-2002), schimbările din cadrul kernelului Linux erau trimise ca și patches sau fișiere arhivate. În 2002, kernelul Linux a început să folosească un DVCS proprietar numit BitKeeper.
+
+În 2005, relațiile dintre comunitatea care dezvolta kernelul și firma care dezvolta BitKeeper s-au stricat, și statutul de gratuit al aplicației a fost revocat. Această schimbare a impus comunității (și în special lui Linus Torvalds, creatorul Linux) să dezvolte propriul sistem bazat pe unele din lucrurile învățate în timpul utilizării BitKeeper. Unele din scopurile noului sistem au fost:
+
+*	Rapiditate
+*	Design simplu
+*	Suport puternic pentru dezvoltare nelineară (mii de branch-uri paralele)
+*	Complet distribuit
+*	Abilitatea de a gestiona proiecte mari similare cu kernelul Linux într-un mod eficient (din punct de vedere al vitezei și mărimii datelor)
+
+Începând cu nașterea sa din 2005, Git a evoluat și s-a maturizat pentru a deveni ușor de folosit dar păstrându-și toate aceste calități inițiale. Git este incredibil de rapid, este foarte eficient cu proiecte mari, și deține un sistem incredibil pentru crearea de branch-uri utilizate in dezvoltarea neliniară (Vezi Capitolul 3).
+
+## Bazele Git ##
+
+Pe scurt, ce este Git? Această secțiune este important de urmărit, deoarece dacă ințelegeți ceea ce este Git și bazele funcționării acestuia, atunci folosirea lui eficientă va fi mult ușurată pentru dumneavoastră. Pe măsură ce învățați Git, încercați să vă mențineți o minte limpede cu privire la lucrurile deja cunoscute de la alte sisteme de versionare, cum ar fi Subversion și Perforce; făcând asta vă va ajuta să evitați confuziile subtile cauzate de folosirea inițială a sa. Git stochează informațiile și lucrează cu ele mult diferit comparativ cu oricare din acele sisteme, chiar dacă interfața cu utilizatorul este destul de asemănătoare; înțelegerea acelor diferențe vă va ajuta să nu fiți confuz în timpul folosirii.
+
+### Instantanee, nu Diferențe ###
+Principala diferență dintre Git și oricare alte sisteme de versionare (Subversion și prietenii săi inclusiv) este modul în care Git își gestionează datele. Conceptual, majoritatea celorlalte sisteme își stochează informațiile ca o listă de schimbări asupra fișierelor. Aceste sisteme (CVS, Subversion, Perforce, Bazaar și altele) văd informațiile ca o mulțime de fișiere și schimbările asupra fișierelor în timp, după cum este ilustrat în Figura 1-4.
+
+Insert 18333fig0104.png 
+Figura 1-4. Alte sisteme tind să stocheze datele ca schimbări relative la versiune de bază a fiecărui fișier.
+
+Git nu vede și nici nu stochează datele în acest mod. În schimb, Git consideră datele sale mai mult ca o mulțime de instantanee (snapshots [en]) ale unu mini sistem de fișiere. De fiecare dată când faceți commit, sau salvați starea proiectului dumneavoastră în Git, acesta practic salvează o poză a stării curente a tuturor fișierelor din acel moment și stochează o referință la acel instantaneu. Pentru a fi eficient, dacă există fișiere care nu s-au schimbat, Git nu stochează fișierul iarași ci doar o legătură către fișierul anterior stocat identic cu cel din prezent. Git vede datele stocate similar cu Figura 1-5.
+
+Insert 18333fig0105.png 
+Figura 1-5. Git stochează datele ca și instantanee ale proiectului de-a lungul timpului.
+
+Aceasta este o distincție importantă dintre Git și aproape toate celelalte VCS. Aceasta face ca Git să reconsidere fiecare aspect al controlului versiunilor pe care majoritatea sistemelor le-au copiat de la generația anterioară. Acest aspect face ca Git să fie mult asemănător cu un mini sistem de fișiere cu niște unelte incredibil de utile adăugate peste el, comparativ cu un simplu VCS, Vom analiza unele dintre benefiicle câștigate prin a vedea datele voastre în acest fel atunci când ne vom ocupa de crearea ramurilor (branches [en]) in Capitolul 3.
+
+### Aproape Orice Operație Este Locală ###
+
+Majoritatea operațiilor în Git necesită doar fișiere locale și resurse locale pentru a funcționa - în general nu sunt necesare informații de la un alt calculator din rețea. Dacă sunteți obișnuit cu un CVCS în care majoritatea operațiilor au o extra latență dată de rețea, aceste aspect al Git vă va face să credeți că zeii vitezei au binecuvântat Git cu puteri din alte lumi. Deoarece aveți întreaga istorie a proiectului chiar aici pe discul local, majoritatea operațiilor par aproape instantanee.
+
+De exemplu, pentru a răsfoi istoria proiectului, Git nu necesită să acceseze serverul pentru a prelua istoria și să o afișeze pentru dumneavoastră - pur și simplu o citește direct din baza de date locală. Aceasta înseamnă că vedeți istoria proiectului aproape instant. Dacă doriți să vedeți schimbările introduse între versiunea curentă a fișierului și cea de acum o lună, Git poate căuta fișierul de acum o lună și să facă un calcul față de diferența locală, în loc de a cere unui server să o facă sau să descarce o versiune mai veche a fișierului de la un server și apoi să facă operația local.
+
+Aceasta înseamnă de asemenea că sunt foarte puține lucruri care nu le puteți face atunci când nu sunteți conectat la rețea sau prin VPN. Dacă sunteți într-un avion sau într-un tren și doriți să munciți putin, puteți adăuga schimbări proiectului iar când ajungeți la o rețea să le încărcați. Dacă ajungeți acasă și nu vă puteți porni clientul VPN, încă puteți lucra. În multe alte sisteme, aceste activități sunt fie imposibile fie foarte greoaie de gestionat. În Perforce, nu puteți face mare lucru atunci când nu sunteți conectat la server; și în Subversion și CVS, puteți edita fișiere, dar nu le puteți face commit în baza de date (deoarece baza de date nu poate fi accesată). Aceasta poate părea o mică îmbunătațire, dar veți fi surprins ce diferență imensă poate face.
+
+### Git Are Integritate ###
+
+Totul in Git are o sumă de control (checksum [en]) înainte de a fi stocat și este apoi referit de către acea sumă de control. Aceasta înseamnă că este imposibil de schimbat conținutul oricărui fișier sau director fără ca Git să știe de el. Aceast funcționalitate este inclusă în Git la cele mai de jos nivele și este o parte integrantă a filosofiei sale. Nu puteți pierde informații în tranzit sau să întâlniți corupere de fișiere fără ca Git să le detecteze.
+
+Mecanismul folosit de Git pentru sumele de control este denumit hash SHA-1. Acesta este un șir de 40 de caractere compus din caractere hexazecimale (toate cifrele, 0 la 9 și caracterele de la a la f) și este calculat pe baza conținutului unui fișier sau a structurii de directoare din Git. Un hash SHA-1 arată similar cu următorul șir:
+
+	24b9da6552252987aa493b52f8696cd6d3b00373
+
+Veți vedea aceste șiruri peste tot în cadrul Git deoarece Git le folosește foarte mult. De fapt, Git stochează orice nu bazându-se pe numele fișierului ci în baza de date Git adresabilă prin intermediul valorii hash a conținutului său. 
+
+### Git Adaugă Date în General ###
+
+Când efectuați anumite operații în Git, aproape toate din ele doar adaugă date în baza de date Git. Este foarte dificil să constrângem sistemul să facă orice operații care sunt permanente sau să șteargă date în vreun fel. Dar ca în orice VCS, puteți pierde sau strica informații datorată schimbărilor care nu sunt deja adăugate; dar după ce faceți commit unui snapshot în Git, este foarte dificil să pierdeți date, mai ales dacă vă împingeți (push [en]) repository-ul către un alt repository.
+
+Acest fapt face Git foarte ușor de folosit deoarece știm că putem experimenta fără a fi în pericol de a strica lucrurile într-un mod grav. Pentru o privire mai atentă la cum stochează Git datele și cum puteți recupera date care par pierdute, vedeți "Sub Capota Git" din Capitolul 9.
+
+### Cele Trei Stări ###
+
+Acum, fiți atenți. Acesta este lucrul principal care trebuie să vi-l amintiți despre Git dacă doriți ca restul procesului de învățare să se desfășoare lin. Git are trei stări principale în care se pot afla fișierele: comise, modificate, și în așteptare (commited, modified, staged [en]). Comise (commited [en]) presupune că datele sunt în siguranță în baza de date locală. Modificate presupune că ați schimbat fișierul dar nu l-ați comis încă în baza de date. În așteptare (staged [en]) înseamnă că ați marcat un fișier în forma curentă să fie inclus în următorul instantaneu comis (commited snapshot [en]).
+
+Aceasta ne duce la principalele trei secțiuni ale unui proiect Git: directorul Git, directorul curent, și zona de așteptare (staging area [en]).
+
+Insert 18333fig0106.png 
+Figura 1-6. Directorul de lucru, zona de așteptare, și directorul git.
+
+Directorul Git este locația unde Git își stochează metadate și baza de date cu obiecte a proiectului dumneavoastră. Aceasta este partea cea mai importantă a Git, și reprezintă ceea ce este copiat atunci când clonați un repository de la un alt calculator.
+
+Directorul de lucru reprezintă un singur checkout al unei versiuni a proiectului. Aceste fișiere sunt preluate din baza de date comprimată din directorul Git și plasate pe discul dumneavoastră pentru a le putea modifica.
+
+Zona de așteptare (staging [en]) este un simplu fișier, de obicei conținut in directorul Git, și stochează informații despre ce va fi folosit pentru urmatorul commit. Este uneori denumit și index, dar devine obișnuit să i se spună zona de așteptare.
+
+Modelul de lucru a Git poate arată ceva similar cu:
+
+1. Modificați fișierele din directorul de lucru.
+2. Puneți fișierele în așteptare, adăugând instantanee ale lor în zona de așteptare.
+3. Faceți un commit, care preia fișierele în starea curentă din zona de așteptare și stochează acel instantaneu permanent în directorul dumneavoastră Git.
+
+Dacă o anumită versiune a unui fișier este în directorul Git, este considerat ca și adăugat (commited [en]). Dacă este modificat dar a fost adăugat în zona de așteptare, este în așteptare. Si dacă a fost schimbat de la ultimul moment în care a fost comis dar nu este în așteptare, este modificat. În Capitolul 2, veți învăța mai multe despre aceste stări și cum puteți fie să le folosiți în avantajul dumneavoastră sau să le omiteți complet.
+
+## Instalarea Git ##
+
+Să începem să folosim Git. Începând cu începutul - trebuie să îl instalăm. Puteți să îl obțineți în mai multe feluri; cele mai importante sunt să îl instalați din surse sau să instalați un pachet deja existent pentru platforma dumneavoastră.
+
+### Instalarea din Fișiere Sursă ###
+
+Dacă puteți, este uneori folositor să instalați Git din surse, deoarece veți obține cea mai nouă versiune. Fiecare nouă versiune tinde să conțină îmbunătațiri ale interfeței, așa că dacă doriți ultima apariție aceasta este cea mai bună metodă dacă sunteți confortabil în lucrul cu cod sursă. Uneori puteți întâlni cazul în care versiunea dumneavoastră de Linux conține pachete foarte vechi; așa că dacă nu aveți ultima apariție a distribuției sau folosiți backports, instalarea din surse poate fi cea mai sigură alegere.
+
+Pentru a instala Git, aveți nevoie de următoarele biblioteci de care Git depinde: curl, zlib, openssl, expat, și libiconv. De exemplu, dacă sunteți într-un sistem care folosește yum (cum ar fi Fedora) sau apt-get (cum ar fi un sistem bazat pe Debian), puteți să folosiți una din aceste comenzi pentru a instala toate dependințele:
+
+	$ yum install curl-devel expat-devel gettext-devel \
+	  openssl-devel zlib-devel
+
+	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
+	  libz-dev libssl-dev
+
+Când aveți toate dependințele cerute, puteți să treceți la pasul următor și să luați ultimul snapshot de pe site-ul Git:
+
+	http://git-scm.com/download
+
+Apoi, compilați și instalați:
+
+	$ tar -zxf git-1.6.0.5.tar.gz
+	$ cd git-1.6.0.5
+	$ make prefix=/usr/local all
+	$ sudo make prefix=/usr/local install
+
+După toți acești pași, puteți să luați Git prin intermediul lui însăși folosind update-uri:
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+
+### Instalarea în sistemele Linux ###
+
+Dacă doriți să instalați Git în Linux prin intermediul unui program de instalare, puteți de obicei să folosiți uneltele locale pentru administrarea pachetelor în funcție de distribuția utilizată. Dacă folosiți Fedora, puteți folosi yum:
+
+	$ yum install git-core
+
+Sau dacă folosiți o distribuție bazată pe Debian, de exemplu Ubuntu, încercați apt-get:
+
+	$ apt-get install git
+
+### Instalarea pe sistemele Mac ###
+
+Sunt două moduri simple de a instala Git pe sistemele Mac. Cea mai simplă este să folosiți programul de instalare grafic pentru Git, pe care îl puteți descărca de la pagina SourceForge ( vedeți Figura 1-7):
+
+	http://sourceforge.net/projects/git-osx-installer/
+
+Insert 18333fig0107.png 
+Figura 1-7. Programul de instalare Git în OS X.
+
+Cealaltă posibilitate este să instalați Git prin intermediul MacPorts (`http://www.macports.org`). Dacă aveți instalat MacPorts, atunci instalați Git cu comanda
+
+	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+
+Nu trebuie să adăugați toate extra-opțiunile, dar probabil veți dori să includeți +svn în caz că veți dori să folosiți Git cu repository-uri Subversion (vedeți Capitolul 8).
+
+### Instalarea pe sistemele Windows ###
+
+Instalarea Git în Windows este foarte simplă. Proiectul msysGit are una din procedurile cele mai simple de instalare. Pur și simplu descărcați programul de instalare de pe pagina GitHub, și rulați-l:
+
+	http://msysgit.github.com/
+
+După ce este instalat, veți avea atât o versiune în linie de comandă (inclusiv un client SSH care vă va fi util mai târziu) cât și o interfață grafică standard (GUI [en]).
+
+## Stările Git Pentru Prima Rulare ##
+
+Acum că aveți Git instalat pe sistemul dumneavoastră, veți dori să faceți câteva schimbări în mediul dumneavoastră Git. Ar trebui să faceți aceste lucruri o singură dată; ele se vor păstra între diverse actualizări. Puteți de asemenea să le schimbați în orice moment rulând din nou comenzile.
+
+Git vine cu un utilitar denumit git config care vă permite să setați variabile de configurare care controlează toate aspectele legate de funcționarea Git și interfața sa. Aceste variabile pot fi păstrate în diverse locuri:
+
+*	fișierul `/etc/gitconfig`: Conține valuroi pentru fiecare utilizator al unui sistem și pentru toate repository-urile sale. Dacă introduceți opțiunea ` --system` pentru `git config`, va citi și scrie din fișierul menționat anterior. 
+*	fișierul `~/.gitconfig`: Specific utilizatorului dumneavoastră. Puteți de asemenea să instruiți Git să citească și să scrie în acest fișier dacă introduceți opțiunea `--global`. 
+*	fișierul de configurare pentru configurația git (adică, `.git/config`) sau specific repository-ului curent: Specific doar pentru acel repository. Fiecare nivel suprascrie valorile din celălalt nivel, deci valorile din `.git/config` le suprascriu pe cele din `/etc/gitconfig`.
+
+În sistemele Windows, Git caută fișierul `.gitconfig` din directorul `$HOME` (`C:\Documents and Settings\$USER` (utilizator [ro])). De asemenea se va uita în /etc/gitconfig, chiar dacă este relativ la rădăcin MSys, care este dată de locul unde v-ați decis să instalați Git pe sistemul dumneavoastră Windows la instalare.
+
+### Identitatea Dumneavoastră ###
+
+Primul lucru care ar trebui să îl faceți atunci când instalați Git este să vă stabiliți numele și adresa de email. Acest aspect este important deoarece fiecare commit în Git va folosi aceste informații, și acestea vor fi conținute în commit-urile care le veți distribui:
+
+	$ git config --global user.name "John Doe"
+	$ git config --global user.email johndoe@example.com
+
+Din nou, va fi necesar să efectuați acești pași o singură dată dacă introduceți opțiunea `--global`, deoarece atunci Git va folosi întotdeauna aceste informații pentru toate operațiile efectuate pe acel sistem. Dacă doriți să suprascrieți aceste informații cu un nume sau email diferite pentru anumite proiecte, atunci puteți executa comanda fără opțiunea `--global` atunci când vă aflați în acel proiect.
+
+### Editorul Dumneavoastră ###
+
+Acum că v-ați setat identitatea, puteți configura editorul de text ce va fi folosit implicit atunci când Git are nevoie să introduceți mesaje. Implicit, Git va folosi editorul definit în sistem, cel mai des acesta va fi Vi sau Vim. Dacă doriți să folosiți un editor text diferit, cum ar fi Emacs, puteți să faceți următoarele:
+
+	$ git config --global core.editor emacs
+	
+### Utilitatorul Pentru Diferențe ###
+
+O altă configurare utilă pe care o puteți face este utilitarul folosit în aflarea diferențelor (diff [en]) folosit pentru rezolvarea conflictelor. Să presupunem că doriți să folosiți vimdiff:
+
+	$ git config --global merge.tool vimdiff
+
+Git acceptă ca și unelte valide pentru diferențe următoarele: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, și opendiff. Puteți de asemenea să configurați un utlitar personalizat; vedeți Capitolul 7 pentru mai multe informații despre această procedură.
+
+### Verificarea Setărilor ###
+
+Dacă doriți să vă verificați setările, puteți folosi comanda `git config --list` pentru a afișa toate setările pe care Git le poate utiliza în prezent:
+
+	$ git config --list
+	user.name=Scott Chacon
+	user.email=schacon@gmail.com
+	color.status=auto
+	color.branch=auto
+	color.interactive=auto
+	color.diff=auto
+	...
+
+Puteți vedea și mai multe chei de mai multe ori, deoarece Git citește aceeași cheie din fișiere diferite (`/etc/gitconfig` și `~/.gitconfig`, de exemplu). În acest caz, Git folosește ultima valoare pentru fiecare cheie unică întâlnită.
+
+Puteți de asemenea să vedeți ceea ce Git crede despre valoarea unei anumite chei dacă scrieți `git config {cheie}`:
+
+	$ git config user.name
+	Scott Chacon
+
+## Cum să Obțineți Ajutor ##
+
+Dacă veți avea vreodată nevoie de ajutor pentru a folosi Git, sunt trei modalități pentru a ajunge la pagina din manual sau manpage pentru ajutor cu oricare din comenzile Git:
+
+	$ git help <verb>
+	$ git <verb> --help
+	$ man git-<verb>
+
+De exemplu, puteți ajunge la pagina din manual pentru comanda config dacă rulați
+
+	$ git help config
+
+Aceste comande sunt utile pentru că le puteți accesa de oriunde, chiar și când nu sunteți conectat la rețea.
+Dacă paginile din manual și această carte nu vă sunt suficiente și aveți nevoie de ajutor personal, puteți încerca canalele `#git` sau `#github` de pe serverul de IRC Freenode (irc.freenode.net). Aceste canale sunt în mod obișnuit pline cu sute de oameni care sunt versați în folosirea Git și sunt de obicei dispuși să vă ofere ajutorul.
+
+## Sumar ##
+
+Ar trebui să dețineți o înțelegere de bază a ceea ce este Git și cum este el diferit de CVCS pe care le utilizați în curent. De asemenea ar trebui să aveți o versiune funcțională a Git pe sistemul dumneavoastră care este configurată cu identitatea dumneavoastră. Acum a venit timpul să învățăm bazele Git.

data/test/progit/ru/01-introduction/01-chapter1.markdown

@@ -0,0 +1,259 @@
+# Введение #
+
+Эта глава о том, как начать работу с Git'ом. Сначала мы расскажем о происхождении инструментов для контроля версий, затем — как установить и запустить Git на вашей машине и наконец, как настроить его так, чтоб можно было приступить к работе. К концу этой главы вы будете понимать, зачем Git вообще сделан, почему вам стоит им пользоваться, и будете готовы начать с ним работать.
+
+## О контроле версий ##
+
+Что такое контроль версий, и зачем он вам нужен? Система контроля версий (СКВ) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов. Для примеров в этой книге мы будем использовать исходные коды программ, но на самом деле под версионный контроль можно поместить файлы практически любого типа.
+
+Если вы графический или веб-дизайнер и хотели бы хранить каждую версию изображения или макета — а этого вам наверняка хочется — то пользоваться системой контроля версий будет очень мудрым решением. СКВ даёт возможность возвращать отдельные файлы к прежнему виду, возвращать к прежнему состоянию весь проект, просматривать происходящие со временем изменения, определять, кто последним вносил изменения во внезапно переставший работать модуль, кто и когда внёс в код какую-то ошибку, и многое другое. Вообще, если, пользуясь СКВ, вы всё испортите или потеряете файлы, всё можно будет легко восстановить. Вдобавок, накладные расходы за всё, что вы получаете, будут очень маленькими.
+
+### Локальные системы контроля версий ###
+
+Многие предпочитают контролировать версии, просто копируя файлы в другой каталог (как правило добавляя текущую дату к названию каталога). Такой подход очень распространён, потому что прост, но он и чаще даёт сбои. Очень легко забыть, что ты не в том каталоге, и случайно изменить не тот файл, либо скопировать файлы не туда, куда хотел, и затереть нужные файлы.
+
+Чтобы решить эту проблему, программисты уже давно разработали локальные СКВ с простой базой данных, в которой хранятся все изменения нужных файлов (см. рисунок 1-1).
+
+Insert 18333fig0101.png
+Рисунок 1-1. Схема локальной СКВ.
+
+Одной из наиболее популярных СКВ такого типа является rcs, которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. Эта утилита основана на работе с наборами патчей между парами версий (патч — файл, описывающий различие между файлами), которые хранятся в специальном формате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи.
+
+### Централизованные системы контроля версий ###
+
+Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (ЦСКВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий (см. рис. 1-2).
+
+Insert 18333fig0102.png
+Рисунок 1-2. Схема централизованного контроля версий.
+
+Такой подход имеет множество преимуществ, особенно над локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте.
+
+Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё — всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей. Локальные системы контроля версий подвержены той же проблеме: если вся история проекта хранится в одном месте, вы рискуете потерять всё.
+
+### Распределённые системы контроля версий ###
+
+И в этой ситуации в игру вступают распределённые системы контроля версий (РСКВ). В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных (см. рисунок 1-3).
+
+Insert 18333fig0103.png
+Рисунок 1-3. Схема распределённой системы контроля версий.
+
+Кроме того, в большей части этих систем можно работать с несколькими удалёнными репозиториями, таким образом, можно одновременно работать по-разному с разными группами людей в рамках одного проекта. Так, в одном проекте можно одновременно вести несколько типов рабочих процессов, что невозможно в централизованных системах.
+
+## Краткая история Git ##
+
+Как и многие замечательные вещи, Git начинался с, в некотором роде, разрушения во имя созидания и жарких споров. Ядро Linux — действительно очень большой открытый проект. Бо́льшую часть существования ядра Linux (1991-2002) изменения к нему распространялись в виде патчей и заархивированных файлов. В 2002 году проект перешёл на проприетарную РСКВ BitKeeper.
+
+В 2005 году отношения между сообществом разработчиков ядра Linux и компанией, разрабатывавшей BitKeeper, испортились, и право бесплатного пользования продуктом было отменено. Это подтолкнуло разработчиков Linux (и в частности Линуса Торвальдса, создателя Linux) разработать собственную систему, основываясь на опыте, полученном за время использования BitKeeper. Основные требования к новой системе были следующими:
+
+*	Скорость
+*	Простота дизайна
+*	Поддержка нелинейной разработки (тысячи параллельных веток)
+*	Полная распределённость
+*	Возможность эффективной работы с такими большими проектами, как ядро Linux (как по скорости, так и по размеру данных)
+
+С момента рождения в 2005 году Git развивался и эволюционировал, становясь проще и удобнее в использовании, сохраняя при этом свои первоначальные качества. Он невероятно быстр, очень эффективен для больших проектов, а также обладает превосходной системой ветвления для нелинейной разработки (см. главу 3).
+
+## Основы Git ##
+
+Так что же такое Git в двух словах? Эту часть важно усвоить, поскольку если вы поймёте, что такое Git, и каковы принципы его работы, вам будет гораздо проще пользоваться им эффективно. Изучая Git, постарайтесь освободиться от всего, что вы знали о других СКВ, таких как Subversion или Perforce. В Git'е совсем не такие понятия об информации и работе с ней как в других системах, хотя пользовательский интерфейс очень похож. Знание этих различий защитит вас от путаницы при использовании Git'а.
+
+### Слепки вместо патчей ###
+
+Главное отличие Git'а от любых других СКВ (например, Subversion и ей подобных) — это то, как Git смотрит на свои данные. В принципе, большинство других систем хранит информацию как список изменений (патчей) для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени, как показано на рисунке 1-4.
+
+Insert 18333fig0104.png
+Рисунок 1-4. Другие системы хранят данные как изменения к базовой версии для каждого файла.
+
+Git не хранит свои данные в таком виде. Вместо этого Git считает хранимые данные набором слепков небольшой файловой системы. Каждый раз, когда вы фиксируете текущую версию проекта, Git, по сути, сохраняет слепок того, как выглядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл. То, как Git подходит к хранению данных, похоже на рисунок 1-5.
+
+Insert 18333fig0105.png
+Рисунок 1-5. Git хранит данные как слепки состояний проекта во времени.
+
+Это важное отличие Git'а от практически всех других систем контроля версий. Из-за него Git вынужден пересмотреть практически все аспекты контроля версий, которые другие системы переняли от своих предшественниц. Git больше похож на небольшую файловую систему с невероятно мощными инструментами, работающими поверх неё, чем на просто СКВ. В главе 3, коснувшись работы с ветвями в Git'е, мы узнаем, какие преимущества даёт такое понимание данных.
+
+### Почти все операции — локальные ###
+
+Для совершения большинства операций в Git'е необходимы только локальные файлы и ресурсы, т.е. обычно информация с других компьютеров в сети не нужна. Если вы пользовались централизованными системами, где практически на каждую операцию накладывается сетевая задержка, вы, возможно, подумаете, что боги наделили Git неземной силой. Поскольку вся история проекта хранится локально у вас на диске, большинство операций кажутся практически мгновенными.
+
+К примеру, чтобы показать историю проекта, Git'у не нужно скачивать её с сервера, он просто читает её прямо из вашего локального репозитория. Поэтому историю вы увидите практически мгновенно. Если вам нужно просмотреть изменения между текущей версией файла и версией, сделанной месяц назад, Git может взять файл месячной давности и вычислить разницу на месте, вместо того чтобы запрашивать разницу у СКВ-сервера или качать с него старую версию файла и делать локальное сравнение.
+
+Кроме того, работа локально означает, что мало чего нельзя сделать без доступа к Сети или VPN. Если вы в самолёте или в поезде и хотите немного поработать, можно спокойно делать коммиты, а затем отправить их, как только станет доступна сеть. Если вы пришли домой, а VPN-клиент не работает, всё равно можно продолжать работать. Во многих других системах это невозможно или же крайне неудобно. Например, используя Perforce, вы мало что можете сделать без соединения с сервером. Работая с Subversion и CVS, вы можете редактировать файлы, но сохранить изменения в вашу базу данных нельзя (потому что она отключена от репозитория). Вроде ничего серьёзного, но потом вы удивитесь, насколько это меняет дело.
+
+### Git следит за целостностью данных ###
+
+Перед сохранением любого файла Git вычисляет контрольную сумму, и она становится индексом этого файла. Поэтому невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Эта функциональность встроена в сам фундамент Git'а и является важной составляющей его философии. Если информация потеряется при передаче или повредится на диске, Git всегда это выявит.
+
+Механизм, используемый Git'ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git'е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:
+
+	24b9da6552252987aa493b52f8696cd6d3b00373
+
+Работая с Git'ом, вы будете встречать эти хеши повсюду, поскольку он их очень широко использует. Фактически, в своей базе данных Git сохраняет всё не по именам файлов, а по хешам их содержимого.
+
+### Чаще всего данные в Git только добавляются ###
+
+Практически все действия, которые вы совершаете в Git'е, только добавляют данные в базу. Очень сложно заставить систему удалить данные или сделать что-то неотменяемое. Можно, как и в любой другой СКВ, потерять данные, которые вы ещё не сохранили, но как только они зафиксированы, их очень сложно потерять, особенно если вы регулярно отправляете изменения в другой репозиторий.
+
+Поэтому пользоваться Git'ом — удовольствие, потому что можно экспериментировать, не боясь что-то серьёзно поломать. Чтобы узнать подробнее о том, как Git хранит свои данные и как восстановить то, что кажется уже потерянным, читайте главу 9.
+
+### Три состояния ###
+
+Теперь внимание. Это самое важное, что нужно помнить про Git, если вы хотите, чтобы дальше изучение шло гладко. В Git'е файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. "Зафиксированный" значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.
+
+Таким образом, в проектах, использующих Git, есть три части: каталог Git'а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area).
+
+Insert 18333fig0106.png 
+Рисунок 1-6. Рабочий каталог, область подготовленных файлов, каталог Git'а.
+
+Каталог Git'а — это место, где Git хранит метаданные и базу данных объектов вашего проекта. Это наиболее важная часть Git'а, и именно она копируется, когда вы клонируете репозиторий с другого компьютера.
+
+Рабочий каталог — это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git'а и помещаются на диск для того, чтобы вы их просматривали и редактировали.
+
+Область подготовленных файлов — это обычный файл, обычно хранящийся в каталоге Git'а, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area).
+
+Стандартный рабочий процесс с использованием Git'а выглядит примерно так:
+
+1. Вы вносите изменения в файлы в своём рабочем каталоге.
+2. Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.
+3. Делаете коммит, который берёт подготовленные файлы из индекса и помещает их в каталог Git'а на постоянное хранение.
+
+Если рабочая версия файла совпадает с версией в каталоге Git'а, файл считается зафиксированным. Если файл изменён, но добавлен в область подготовленных данных, он подготовлен. Если же файл изменился после выгрузки из БД, но не был подготовлен, то он считается изменённым. В главе 2 вы узнаете больше об этих трёх состояниях и как можно либо воспользоваться этим, либо пропустить стадию подготовки.
+
+## Установка Git ##
+
+Настало время немного ознакомиться с использованием Git'а. Первое, что вам необходимо сделать, — установить его. Есть несколько способов сделать это; два основных — установка из исходников и установка собранного пакета для вашей платформы.
+
+### Установка из исходников ###
+
+Если есть возможность, то, как правило, лучше установить Git из исходных кодов, поскольку так вы получите самую свежую версию. Каждая новая версия Git'а обычно включает полезные улучшения пользовательского интерфейса, поэтому получение последней версии — часто лучший путь, если, конечно, вас не затрудняет установка программ из исходников. К тому же, многие дистрибутивы Linux содержат очень старые пакеты. Поэтому, если только вы не на очень свежем дистрибутиве или используете пакеты из экспериментальной ветки, установка из исходников может быть самым выигрышным решением.
+
+Для установки Git'а вам понадобятся библиотеки, от которых он зависит: curl, zlib, openssl, expat и libiconv. Например, если в вашей системе менеджер пакетов — yum (Fedora), или apt-get (Debian, Ubuntu), можно воспользоваться следующими командами, чтобы разрешить все зависимости:
+
+	$ yum install curl-devel expat-devel gettext-devel \
+	  openssl-devel zlib-devel
+
+	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
+	  libz-dev libssl-dev
+
+Установив все необходимые библиотеки, можно идти дальше и скачать последнюю версию с сайта Git'а:
+
+	http://git-scm.com/download
+
+Теперь скомпилируйте и установите:
+
+	$ tar -zxf git-1.7.2.2.tar.gz
+	$ cd git-1.7.2.2
+	$ make prefix=/usr/local all
+	$ sudo make prefix=/usr/local install
+
+После этого вы можете скачать Git с помощью самого Git'а, чтобы получить обновления:
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+
+### Установка в Linux ###
+
+Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива. Если у вас Fedora, можно воспользоваться yum'ом:
+
+	$ yum install git-core
+
+Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте apt-get:
+
+	$ apt-get install git
+
+### Установка на Mac ###
+
+Есть два простых способа установить Git на Mac. Самый простой — использовать графический инсталлятор Git'а, который вы можете скачать со страницы на SourceForge (см. рисунок 1-7):
+
+	http://sourceforge.net/projects/git-osx-installer/
+
+Insert 18333fig0107.png
+Рисунок 1-7. Инсталлятор Git'а под OS X.
+
+Другой распространённый способ установки Git'а — через MacPorts (`http://www.macports.org`). Если у вас установлен MacPorts, установите Git так:
+
+	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+
+Вам не обязательно устанавливать все дополнения, но, вероятно, вам понадобится +svn, если вы когда-нибудь захотите использовать Git вместе с репозиториями Subversion (см. главу 8).
+
+### Установка в Windows ###
+
+Установить Git в Windows очень просто. У проекта msysGit процедура установки — одна из самых простых. Просто скачайте exe-файл инсталлятора со страницы проекта на GitHub'е и запустите его:
+
+	http://msysgit.github.com/
+
+После установки у вас будет как консольная версия (включающая SSH-клиент, который пригодится позднее), так и стандартная графическая.
+
+Пожалуйста, используйте Git только из командой оболочки, входящей в состав msysGit, потому что так вы сможете запускать сложные команды, приведённые в примерах в настоящей книге. Командная оболочка Windows использует иной синтаксис, из-за чего примеры в ней могут работать некорректно.
+
+## Первоначальная настройка Git ##
+
+Теперь, когда Git установлен в вашей системе, хотелось бы сделать кое-какие вещи, чтобы настроить среду для работы с Git'ом под себя. Это нужно сделать только один раз — при обновлении версии Git'а настройки сохранятся. Но вы можете поменять их в любой момент, выполнив те же команды снова.
+
+В состав Git'а входит утилита `git config`, которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git'а и его внешний вид. Эти параметры могут быть сохранены в трёх местах:
+
+*	Файл `/etc/gitconfig` содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске `git config` указать параметр `--system`, то параметры будут читаться и сохраняться именно в этот файл.
+*	Файл `~/.gitconfig` хранит настройки конкретного пользователя. Этот файл используется при указании параметра `--global`.
+*	Конфигурационный файл в каталоге Git'а (`.git/config`) в том репозитории, где вы находитесь в данный момент. Эти параметры действуют только для данного конкретного репозитория. Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в `.git/config` перекрывают соответствующие значения в `/etc/gitconfig`.
+
+В системах семейства Windows Git ищет файл `.gitconfig` в каталоге `$HOME` (`C:\Documents and Settings\$USER` или `C:\Users\$USER` для большинства пользователей). Кроме того Git ищет файл /etc/gitconfig, но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git, когда запускали инсталлятор.
+
+### Имя пользователя ###
+
+Первое, что вам следует сделать после установки Git'а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git'е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
+
+	$ git config --global user.name "John Doe"
+	$ git config --global user.email johndoe@example.com
+
+Повторюсь, что, если указана опция `--global`, то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе. Если для каких-то отдельных проектов вы хотите указать другое имя или электронную почту, можно выполнить эту же команду без параметра `--global` в каталоге с нужным проектом.
+
+### Выбор редактора ###
+
+Вы указали своё имя, и теперь можно выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git'е. По умолчанию Git использует стандартный редактор вашей системы, обычно это Vi или Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно сделать следующее:
+
+	$ git config --global core.editor emacs
+
+### Утилита сравнения ###
+
+Другая полезная настройка, которая может понадобиться — встроенная diff-утилита, которая будет использоваться для разрешения конфликтов слияния. Например, если вы хотите использовать vimdiff:
+
+	$ git config --global merge.tool vimdiff
+
+Git умеет делать слияния при помощи kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge и opendiff, но вы можете настроить и другую утилиту. Подробнее об этом написано в главе 7.
+
+### Проверка настроек ###
+
+Если вы хотите проверить используемые настройки, можете использовать команду `git config --list`, чтобы показать все, которые Git найдёт:
+
+	$ git config --list
+	user.name=Scott Chacon
+	user.email=schacon@gmail.com
+	color.status=auto
+	color.branch=auto
+	color.interactive=auto
+	color.diff=auto
+	...
+
+Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ из разных файлов (например из `/etc/gitconfig` и `~/.gitconfig`). В этом случае Git использует последнее значение для каждого ключа.
+
+Также вы можете проверить значение конкретного ключа, выполнив `git config {ключ}`:
+
+	$ git config user.name
+	Scott Chacon
+
+## Как получить помощь? ##
+
+Если вам нужна помощь при использовании Git'а, есть три способа открыть страницу руководства по любой команде Git'а:
+
+	$ git help <команда>
+	$ git <команда> --help
+	$ man git-<команда>
+
+Например, так можно открыть руководство по команде config:
+
+	$ git help config
+
+Эти команды хороши тем, что ими можно пользоваться всегда, даже без подключения к сети.
+Если руководства и этой книги недостаточно и вам нужна персональная помощь, вы можете попытаться поискать её на каналах `#git` и `#github` IRC-сервера Freenode (irc.freenode.net). Обычно там сотни людей, отлично знающих Git, которые могут помочь.
+
+## Итоги ##
+
+Теперь у вас должно быть общее понимание, что такое Git, и в чём его отличие от тех ЦСКВ, которыми вы, вероятно, пользовались раньше. Также у вас должна быть установлена рабочая версия Git'а с вашими личными настройками. Настало время перейти к изучению основ Git'а.