Ce este Git și de ce ar trebui să utilizați controlul versiunii Dacă sunteți dezvoltator

În calitate de dezvoltatori web, o mare parte a timpului pe care avem tendința de a lucra pe site-urile de dezvoltare locală, atunci încărcați totul atunci când terminăm. Acest lucru este bine când sunteți doar dvs. și schimbările sunt mici, dar atunci când aveți de-a face cu mai multe persoane care lucrează la ceva sau pe un proiect mare cu multe componente complicate, acest lucru nu este posibil. Atunci ne întoarcem la ceva numit control al versiunii.

Astăzi voi vorbi despre un software de control al versiunii open source numit Git. Acest lucru permite mai mult de o persoană să lucreze în condiții de siguranță pentru același proiect fără a interfera unul cu celălalt, dar este mult mai mult decât atât.

De ce să utilizați software de control al versiunii?

În primul rând, numele trebuie să renunțe. Versiunea software-ului de control vă permite să aveți “versiuni” a unui proiect, care arată schimbările aduse codului în timp și vă permite să faceți backtrack dacă este necesar și să anulați aceste modificări. Această abilitate singură - de a putea compara două versiuni sau de a schimba schimbările, o face destul de neprețuită atunci când lucrează la proiecte mai mari.

Probabil că ați făcut chiar și asta la un moment dat, salvând copii ale unui proiect în diferite puncte, astfel încât să aveți un backup. Într-un sistem de control al versiunii, doar modificările ar fi salvate - un fișier de patch-uri care ar putea fi aplicat unei singure versiuni, pentru ao face la fel ca și versiunea următoare. Cu un dezvoltator, acest lucru este suficient.

Dar dacă aveți mai mulți dezvoltatori care lucrează la un proiect? Atunci vine ideea unui server centralizat de control al versiunilor. Acestea au fost standard pentru o lungă perioadă de timp, prin care toate versiunile sunt stocate pe un server central, iar dezvoltatorii individuali verifică și încarcă modificările înapoi la acest server. Dacă v-ați uitat vreodată la istoricul editării unei pagini Wikipedia, veți avea o idee bună despre cum funcționează acest lucru într-un scenariu real al lumii:

Beneficiile unui astfel de sistem sunt că mai mulți dezvoltatori pot face modificări, iar fiecare schimbare poate fi atribuită unui dezvoltator specific. În partea inferioară, faptul că totul este stocat într-o bază de date la distanță înseamnă că nu se pot face modificări atunci când serverul coboară; și dacă baza de date centrală este pierdută, fiecare client are doar versiunea curentă a activității pe care au lucrat-o.

Asta ne duce spre Git și alte așa-numite sisteme de control al versiunilor distribuite. În aceste sisteme, clienții nu doar verifică versiunea curentă a fișierelor și lucrează de la ei - ei oglindesc întreaga istorie a versiunii. Fiecare dezvoltator are întotdeauna o copie completă a tuturor lucrurilor. Un server central este încă folosit, dar ar trebui să se întâmple cel mai rău, atunci totul poate fi restabilit de la oricare dintre clienții care au cele mai recente versiuni.

Git lucrează în mod special prin luare “instantanee” de fișiere; dacă fișierele rămân neschimbate într-o anumită versiune, acestea se leagă pur și simplu la fișierele anterioare - aceasta ține totul rapid și slab.

S-ar putea să vă intereseze, de asemenea, să aflați că Git este folosit pentru a gestiona și dezvolta kernel-ul linux core - elementul de bază pe care se construiesc toate distribuțiile linux.

Ce este Github?

Deși puteți să vă difuzați propriul server Git local, Github este atât un server la distanță, o comunitate de dezvoltatori, cât și o interfață grafică web pentru gestionarea proiectului dvs. Git. Este gratuită pentru până la 5 registre publice - adică atunci când cineva vă poate vedea sau aloca codul dvs. - cu planuri de cost redus pentru proiecte private. Vă sugerez să vă înscrieți pentru un cont gratuit pentru a putea începe să jucați cu propriile dvs. proiecte sau pentru a vă forța pe cineva elses.

Forking & ramificare

Acestea sunt concepte de baza ale experientei Git, asa ca sa luam un moment pentru a explica diferenta.

Probabil ați auzit lucrarea “furculiţă” atunci când se ocupă de linux distros. Dacă sunteți familiarizați cu App Media Center Plex, veți ști că a fost inițial o furculiță a Xbox Media Center similară open source Aeon Nox 3.5: Temă frumoasă și personalizabilă pentru XBMC Aeon Nox 3.5: Temă frumoasă și personalizabilă pentru setul XBMC până la centrul dvs. de mass-media exact așa cum doriți. Aeon Nox 3.5 este cea mai recentă versiune a ceea ce este probabil cea mai bună temă pentru XBMC, și este o combinație rară: frumoasă ... Citește mai mult. Acest lucru înseamnă pur și simplu că, la un moment dat în trecut, unii dezvoltatori au luat codul XBMC și au decis să meargă pe cont propriu; care a devenit Plex.

Acest lucru este, desigur, permis în totalitate când proiectul este open source - puteți lua codul, faceți tot ce vreți cu el. Cu Git, dacă simțiți că schimbările dvs. sunt suficient de bune pentru a vă întoarce înapoi “maestru” proiect, puteți face o “trageți cererea” la autor, cerându-le să-și tragă schimbările înapoi în proiectul lor inițial. Acest lucru vă permite să aveți sute de mii de dezvoltatori care lucrează la un proiect în orice moment, dintre care niciunul nu trebuie să fie aprobat în mod neapărat pentru accesul la cod - ei doar copiază codul, fac modificări și solicită să fie reintroduse în master. Bineînțeles, depinde de proprietarul proiectului inițial dacă aceștia decid să accepte schimbările sau nu.

Brancharea este ceva realizat intern pe un proiect de către dezvoltatorii autorizați. Vă permite să separați cu ușurință anumite probleme sau caracteristici și să lucrați la acestea fără a rupe fișierele master. După ce sunteți mulțumit că sucursala dvs. a rezolvat problema, o îmbinați înapoi în comandă. În orice moment, pot exista cât mai multe ramuri pe care le doriți; ele nu interferează unul cu celălalt. De asemenea, puteți îmbina schimbările dintre ramuri fără să atingeți maestrul.

Iată o diagramă excelentă a unui exemplar de lucru al lui Vincent Driessen:

Data viitoare vom analiza cum să configurați un exemplu de lucru Git și să efectuați modificări de cod în cadrul sucursalelor. Controlul versiunii este un subiect uriaș. Am dat doar cea mai scurta prezentare de ansamblu aici, dar ca dezvoltator care este obisnuit doar sa faca schimbari si sa-i desfaca daca nu functioneaza, tot conceptul mi-a suflat mintea - sper ca si dvs..

Sunteți un dezvoltator experimentat cu experiență în Git? Începeți să începeți și credeți că doriți să mergeți? Sunați în comentarii!

Explorați mai multe despre: Programare, Management de proiect, Dezvoltare Web.