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

Publicitate

În calitate de dezvoltatori web, de multe ori avem tendința de a lucra pe site-uri de dezvoltare locală, atunci doar încărcăm totul când am terminat. Acest lucru este în regulă atunci când este doar tu, iar modificările sunt mici, dar când aveți de-a face cu mai mult de unul persoană care lucrează la ceva sau la un proiect mare cu multe componente complicate, asta nu este pur și simplu fezabilă. Atunci vom apela la ceva numit control versiune.

Astăzi voi vorbi despre un software de control al versiunii open source numit Git. Acest lucru permite mai multor persoane să lucreze în siguranță la același proiect, fără a interfera între ele, dar este mult mai mult decât atât.

De ce să folosiți software-ul de control al versiunii?

În primul rând, numele ar trebui să-l ofere. Programul de control al versiunilor vă permite să aveți „versiuni” ale unui proiect, care arată modificările aduse codului în timp și vă permite să faceți backtrack dacă este necesar și să anulați modificările respective. Această abilitate singură - de a putea compara două versiuni sau schimbări inverse, o face destul de neprețuită atunci când lucrează la proiecte mai mari.

Probabil chiar ați făcut acest lucru chiar la un moment dat, salvând copii ale unui proiect în diferite puncte, astfel încât să aveți o copie de rezervă. Într-un sistem de control al versiunilor, doar modificările ar fi salvate - un fișier patch care ar putea fi aplicat la o versiune, pentru a face același lucru ca versiunea următoare. Cu un singur dezvoltator, acest lucru este suficient.

Dar dacă ai mai mult de un dezvoltator care lucrează la un proiect? Atunci apare ideea unui server de control al versiunii centralizate. Acestea au fost standardul pentru o lungă perioadă de timp, prin care toate versiunile sunt stocate pe un server central, iar dezvoltatorii individuali efectuează verificări și încărcări înapoi la acest server. Dacă v-ați uitat vreodată la istoricul de editare a unei pagini Wikipedia, veți avea o idee bună despre cum funcționează acest lucru într-un scenariu din lumea reală:

Avantajele unui sistem ca acesta sunt că mai mulți dezvoltatori pot face modificări, iar fiecare modificare poate fi apoi atribuită unui dezvoltator specific. Dezavantaj, faptul că totul este stocat pe o bază de date la distanță înseamnă că nu se poate face nicio modificare atunci când serverul respectiv se reduce; și dacă baza de date centrală este pierdută, fiecare client are doar versiunea actuală a ceea ce lucrau.

Asta ne duce la Git și la alte așa-numite sisteme de control distribuite versiuni. În aceste sisteme, clienții nu verifică doar versiunea actuală a fișierelor și lucrează din ele - reflectă întregul istoric al versiunilor. Fiecare dezvoltator are întotdeauna o copie completă a tuturor. Un server central este încă utilizat, dar în cazul în care cel mai rău se întâmplă, atunci totul poate fi restaurat de la oricare dintre clienții care au cele mai recente versiuni.

Git funcționează în mod special luând „instantanee” de fișiere; dacă fișierele rămân neschimbate într-o anumită versiune, se leagă pur și simplu la fișierele anterioare - acest lucru menține totul rapid și slab.

De asemenea, v-ar putea interesa să aflați că Git este utilizat pentru a gestiona și dezvolta nucleu linux de bază - blocul de bază pe care sunt construite toate distrosurile linux.

Ce este Github?

Deși puteți rula propriul dvs. server Git local, github este atât un server la distanță, o comunitate de dezvoltatori, cât și o interfață web grafică pentru gestionarea proiectului dvs. Git. Este gratuit să folosești până la 5 depozite publice - adică atunci când oricine îți poate vizualiza sau pune codul dvs. cu planuri de costuri reduse pentru proiecte private. Vă sugerez să vă înscrieți pentru un cont gratuit, astfel încât să puteți începe să vă jucați cu propriile dvs. proiecte sau să faceți cu capul cuiva.

Forking & Branching

Acestea sunt concepte esențiale ale experienței Git, deci să luăm un moment pentru a explica diferența.

Probabil că ați auzit lucrarea „furculiță” atunci când aveți de-a face cu distros linux. Dacă cunoașteți aplicația Plex pentru centrul media, veți ști că a fost inițial o furculiță a sursei deschise similare Xbox Media Center Aeon Nox 3.5: Tema frumoasă și personalizabilă pentru XBMCConfigurați-vă centrul media exact așa cum doriți. Aeon Nox 3.5 este cea mai recentă versiune a ceea ce este poate cea mai bună temă pentru XBMC, și este o combinație rară: frumos ... Citeste mai mult . Acest lucru înseamnă pur și simplu că, la un moment dat, unii dezvoltatori au luat codul XBMC și au decis să meargă singuri cu acesta; care a devenit Plex.

Desigur, acest lucru este permis în totalitate atunci când proiectul este open source - puteți lua codul, faceți orice doriți cu el. Cu Git, dacă simțiți că schimbările dvs. sunt suficient de bune pentru a fi reduse în proiectul „master”, voi poate face o „solicitare de tragere” autorului, rugându-i să-și readucă modificările în original proiect. Acest lucru vă permite să aveți sute de mii de dezvoltatori care lucrează la un proiect în orice moment, niciunul dintre ei nu trebuie neapărat să fie aprobate pentru accesul codului - ele doar copiază codul, fac modificări și solicită să fie redate în maestru. Desigur, depinde de proprietarul proiectului inițial dacă decide să vă accepte sau nu modificările.

Filializarea este ceva realizat intern pe un proiect de către dezvoltatorii autorizați. Vă permite să separați cu ușurință probleme specifice sau funcții și să lucrați la ele fără a rupe fișierele master. După ce sunteți mulțumit de faptul că sucursala dvs. a tratat problema, o îmbinați în nou. În orice moment, pot exista atâtea ramuri pe cât doriți; ei nu se amestecă între ei. De asemenea, puteți îmbina modificările între ramuri fără a atinge maestrul.

Iată o diagramă excelentă a unui flux de lucru de exemplu Vincent Driessen:

Data viitoare, vom analiza cum să configurați un exemplu Git funcțional și să facem modificări de cod în sucursale. Controlul versiunilor este un subiect imens. Am primit doar cea mai scurtă privire de ansamblu aici, dar în calitate de dezvoltator obișnuit să facă doar schimbări și să le anuleze dacă nu funcționează, întregul concept mi-a aruncat în minte - sper că și al tău.

Ești un dezvoltator experimentat, cu experiență în Git? Tocmai începeți și credeți că doriți să faceți o pauză? Sună în comentarii!