Acest conținut face parte din seria: Git pentru utilizatorii de subversiune
Aveți grijă de articole noi din această serie.
Pentru cei care nu cunosc VCS liber open-source, trebuie spus că Subversion a devenit de fapt standardul pentru VCS necomercial, înlocuind vechiul și bunul CVS (System Concurrent Versions). Sistemele CVS sunt încă excelente pentru utilizare limitată, dar Subversion este atras de faptul că necesită aproape doar o mică configurație a serverului Web. Subversiunea are unele probleme pe care le vom discuta aici, dar în cele mai multe cazuri funcționează bine.
Deci, de ce avem nevoie de altceva? Sistemul Git (cu capitala "G", deoarece git este un instrument de linie de comandă) este proiectat în mare măsură pentru a fi mai bun decât Subversion. Este unul dintre numeroasele distribuite VCS. Personal, am lucrat cu Arch / tla, Mercurial, Bazaar, darcs și altele. Din multe motive pe care le voi vorbi despre momentul în care devin importante pentru povestea noastră, Git a devenit popular și este adesea considerat unul dintre cei doi lideri (împreună cu Subversion) dintre VCS personale și corporative.
Există două motive pentru care, în calitate de utilizator Subversion, ar putea fi interesat de Git.
- Aveți de gând să treceți la utilizarea Git, deoarece Subversion vă restricționează într-un fel.
- Sunteți interesat să aflați despre Git și doriți să îl comparați cu Subversion.
Deși poate că există un al treilea motiv: Git - este o tehnologie relativ nouă pe care doriți să o specificați în CV. Sper că acest lucru nu este obiectivul dvs. principal; learning Git este unul dintre cele mai utile lucruri pe care un dezvoltator le poate face. Chiar dacă nu utilizați Git Acum, conceptul și procesul de lucru pus în aplicare în acest distribuit VCS, va deveni cu siguranță cunoștințe esențiale pentru cele mai multe segmente ale industriei IT în următorii 10 ani, deoarece industria este în curs de schimbări majore în limitele lor și structura geografică.
În cele din urmă, deși acest lucru nu este un motiv bun, dacă nu dezvoltați kernelul Linux, Git este folosit pentru a sprijini kernelul și multe alte proiecte importante. Prin urmare, dacă intenționați să contribuiți la oricare dintre proiectele deschise, trebuie să vă familiarizați cu acest sistem.
În partea a doua a acestei serii, vom discuta metodele dificile de utilizare a fuzionării de ramuri Git: generarea de fișiere diferențiale și alte sarcini tipice.
Bazele subversiunii și Git
Apoi, în loc de "Subversion", voi folosi abrevierea "SVN" pentru a uza mai puțin tastele U, B, E, R, S, I și O de pe tastatura mea.
Poate că ați auzit de instrumentul git-svn, care vă permite să utilizați Git atunci când lucrați cu depozitul Subversion. În unele situații, poate fi util, dar folosirea unui client dintr-un sistem distribuit atunci când lucrați cu un VCS centralizat nu este o tranziție la un VCS distribuit.
Deci, ce este bun despre SVN? Poate că deja știți că principalul lucru din VCS nu sunt fișiere, ci schimbări. SVN care rulează pe serverul central adaugă modificări în depozitul de date și vă poate furniza o copie a acestor date după fiecare modificare. Această copie are numărul versiunii; Numărul versiunii este foarte important pentru SVN și pentru cei care lucrează cu acesta. Dacă schimbarea urmează după mine, numărul dvs. de versiune este garantat să fie mai mare decât al meu.
Git are un scop similar - urmărirea schimbărilor - dar nu are un server centralizat. Aceasta este o diferență foarte importantă. SVN este un sistem centralizat, iar Git este un sistem distribuit, deci nu există o ordine crescătoare de versiuni în Git, deoarece nu există o "ultima versiune" în acesta. Cu toate acestea, există încă identificatori de versiune unică în el, doar ei înșiși nu sunt la fel de folositori ca numerele de versiuni (revizuiri) în SVN.
Lucrul cu un director în SVN
Listarea 1. Configurarea directorului pentru a lucra în SVN
Ce ne dă acest lucru? Acum putem obține cele mai recente versiuni ale tuturor fișierelor din acest director din depozit, ștergem fișierele, redenumește-le, creăm noi fișiere și directoare, schimbăm fișierele existente etc:
Listing 2. Operații simple de fișiere în SVN
Nu vom studia aceste comenzi aici în detaliu, dar pur și simplu le vom aminti. Pentru a vedea informații de ajutor de bază pentru oricare dintre aceste comenzi, tastați svn help COMMAND. și pentru informații detaliate, consultați manualul de utilizare.
Lucrul cu directorul din Git
Voi acționa în același mod ca în exemplul cu SVN. Ca și înainte, presupun că aveți un director cu date.
Ca server de la distanță, am folosit serviciul gratuit github.com, dar, desigur, puteți folosi orice alt server. GitHub este o modalitate simplă de a încerca să lucrați cu un depozit Git la distanță. La momentul redactării, cantitatea de date pentru un cont gratuit este limitată la 300 MB, în plus, depozitul trebuie să fie public. Am creat un cont numit "tzz" și am creat un depozit public "datatest"; îl puteți folosi. Am furnizat cheia mea SSH publică. Dacă nu aveți deja cheia proprie, ar trebui să o generați. De asemenea, puteți încerca serverele Gitorious sau repo.or.cz. În secțiunea Wiki a site-ului git.or.cz există o listă largă de site-uri care furnizează servicii de găzduire pentru depozitele Git (consultați link-ul din secțiunea Subiecte conexe).
GitHub este bun pentru că este prietenos utilizatorilor. Acesta vă spune ce comenzi să utilizați pentru a configura Git și pentru a pregăti depozitul pentru utilizare. Vom realiza aceste acțiuni împreună.
Listă 3. Configurație Git de bază
Apoi, configurez fișierele de date și inițializez-le cu depozitul meu. (GitHub le poate importa, de asemenea, din depozitul SVN, care poate fi utilă.)
Listarea 4. Configurarea directorului și primul comitet
Git afișează informații despre modurile de acces la fișiere; 100644 reprezintă o reprezentare octală a biților de permisiune pentru aceste fișiere. Nu puteți să le acordați atenție, dar mesajul despre inserarea 2371 poate părea misterios. Am schimbat doar 2 dosare, nu-i așa? De fapt, acest număr indică numărul de rânduri introduse. Și, desigur, nu am șters o singură linie.
Afișarea 5. Publicarea modificărilor la un depozit la distanță
Aici, OpenSSH emite un avertisment din cauza faptului că anterior mașina lui github.com nu era cunoscută. Nu-i acordați atenție.
Mesajele date de Git sunt extrem de detaliate. Spre deosebire de plamani pentru intelegerea mesajelor SVN, mesajele Git sunt scrise de initiati si sunt destinate initierii. Dacă veniți din Herbert Frank Dune și sunteți instruiți ca un biocomputer, probabil că îi veți înțelege, deși probabil că ați scris deja propria versiune a lui Git. Ei bine, restul rapoartelor despre compresia delta și numărul de fire pe care le folosește pur și simplu nu sunt foarte importante (și pot provoca o durere de cap).
Transferul de modificări a fost efectuat prin SSH, dar puteți utiliza și alte protocoale, cum ar fi HTTP, HTTPS, rsync și fișier. Pentru mai multe informații, consultați ajutorul: git push --help.
Am ajuns la cea mai importantă diferență dintre SVN și Git. În SVN, operația de comitere indică: "trebuie să copiați acest lucru la serverul central". În SVN, schimbările dvs. rămân intangibile până când le-ați comite. În Git, comiterea schimbărilor este locală. aveți un depozit local care nu are grijă de ce se întâmplă pe partea îndepărtată. Puteți renunța la schimbare, la sucursală, la schimbare la sucursale etc. fără nici o interacțiune cu serverul de la distanță. Publicarea modificărilor (push) către Git este în esență sincronizarea stării depozitului dvs. cu un server de la distanță.
Ei bine, în sfârșit, să vedem cum ceea ce am făcut este afișat în jurnalul Git:
Listing 6. Git log
În jurnal există o înregistrare care stabilește numai modificările (rețineți că aici, spre deosebire de numărul de revizie din SVN, apare un identificator aleatoriu lung al operației de comitere). Nu se menționează sincronizarea efectuată de comanda push git.
Lucrul cu Git
Până acum, am folosit Git ca înlocuitor pentru SVN. Desigur, pentru a face totul mai interesant, trebuie să aveți mai mulți utilizatori și câteva seturi de modificări. Să lucrăm cu depozitul nostru dintr-o altă mașină (o să folosesc o mașină cu Ubuntu GNU / Linux, pe care pachetul pe care vrei să-l instalezi nu este git, ci git-core):
Listare 7. Configurați încă o instanță a Git și încărcați conținutul depozitului în el
OpenSSH emite din nou un avertisment că înainte ca această mașină să nu funcționeze prin SSH cu GitHub. Comanda clonei git este similară cu comanda de verificare SVN, dar în loc să obținem o versiune specifică a conținutului, vom obține întreaga repozitorie în întregime.
Am adus aici conținutul directorului datatest / .git și al subdirectorului hooks pentru a arăta că avem cu adevărat totul. În mod implicit, Git nu ascunde secretele, spre deosebire de SVN, care stochează în mod implicit depozitul în secret și permite accesul numai la copii ale conținutului.
Apropo, dacă doriți să configurați pentru Git-repository toate regulile care ar fi executate, de exemplu, cu fiecare comitere de modificări, puteți face acest lucru folosind scripturi din directorul de cârlige. Acestea sunt scripturile obișnuite, în multe privințe similare cu "capcanele" din SVN, care, conform standardelor UNIX, întoarce zero în caz de succes și orice altceva în caz de eroare. Nu voi intra în detalii despre scenariile "capcane", dar dacă intenționați să utilizați Git în lucrul în echipă, cu siguranță trebuie să le studiați în detaliu.
Deci, utilizatorul "The Other Ted" dorește să adauge un nou fișier în ramura principală (care poate fi aproape legată de sucursala TRUNK din SVN) și să creeze, de asemenea, o nouă ramură cu unele modificări în fișierul gdbinit.
Listarea 8. Adăugarea unui fișier și crearea unei noi filiale
A fost un exemplu lung și sper că nu ați adormit în timp ce ați citit-o. Dacă ai adormit, sper că ai visat la depozitele Git care se sincronizează într-un vals nesfârșit de seturi de schimbări (oh, nu te îngrijora, vei visa despre asta).
Mai întâi am adăugat și fixat fișierul (encode.pl, toate dintr-o singură linie). După reparație, depozitul de la distanță nu știa nimic despre ceea ce am făcut. Apoi am creat o nouă ramură a lui empty-gdbinit și am trecut la el (și acest lucru se poate face și cu comanda git check -b-gdbinit). În această ramură, am adăugat un fișier gol gdbinit și am fixat această modificare. În cele din urmă, am mutat modificările la serverul de la distanță.
Dacă vom trece la ramura principală, nu vom vedea intrarea pentru "gdbinit gol" în jurnal. Ie fiecare ramură are un jurnal propriu, care pare logic.
Afișați 9. Căutați jurnale de diferite ramuri
Când am pornit comanda push, Git a spus serverelor GitHub: "Hei, uite, există un nou fișier numit encode.pl"
Listare 10. Publicați toate modificările
Interfața pentru gânditori apare din nou în toată gloria sa. Dar ne putem da seama ce se întâmplă, nu-i așa? Noi nu poate fi gânditori mari, dar simțul nostru comun ne spune că 0000000000000000000000000000000000000000 - este un fel de etichetă specială în prealabil. De asemenea, din revista, așa cum se arată în Listarea 9, putem vedea că eticheta 5512d0a4327416c499dcb5f72c3f4f6a257d209f este ultima fixarea (și numai) în ramurile goale-gdbinit. Orice altceva este pentru majoritatea utilizatorilor și ar putea fi scrise în limba aramaică, deoarece anterior nu le pasă. Acum, GitHub afișează o nouă ramură și schimbările sale.
Există, de asemenea, comenzi git mv și git rm. cu care puteți muta și redenumi fișierele respective.
concluzie
În acest articol, am vorbit despre conceptele de bază ale lui Git și am organizat controlul versiunii într-un director simplu, comparându-l în cursul povestirii cu Subversion. Pe un exemplu simplu, am demonstrat lucrul cu filialele.
Pe de altă parte, Git este un DVCS foarte bogat; aflați mai multe despre capabilitățile sale, le veți folosi aproape sigur pentru a vă simplifica și îmbunătăți stilul de lucru cu VCS. De asemenea, probabil veți vedea câteva vise despre depozitele Git.