Sistem de control al versiunii Git. Bazele sistemului de control al versiunilor Git pentru începători, folosind SmartGit ca exemplu

În timp ce lucrează la un proiect, participanții săi adesea întâmpină probleme cu sincronizarea și istoricul fișierelor, care sistemele de control al versiunilor (SUMS) ajută la rezolvarea acestora. Scopul acestei serii de articole este să cunoască cititorul principiile de funcționare a SUV-ului și să ia în considerare în detaliu unul dintre ele, și anume Git. De ce git? recent,   acest sistem câștigă popularitate, iar importanța sa pentru software-ul liber (și în special pentru proiectul GNU / Linux) este greu de supraestimat.

Vom analiza în mod constant, în linii generale, caracteristicile sistemelor de control și vom vorbi despre arhitectura lor și principalele caracteristici ale aplicației în cauză. În plus, vom analiza interfețele existente pentru lucrul cu Git.

Autorul omite în mod intenționat terminologia funcțiilor, tastelor și a altor subtilități pentru a vă prezenta în mod clar, clar și, în general, o imagine. Acest articol presupune că cititorul este familiarizat cu sistemele de operare asemănătoare Unix și are, de asemenea, cunoștințe de bază despre algoritmi și informatică în general.

În materialele următoare, vom aprofunda structura și filozofia lui Git, specificul acestui sistem și subtilitățile lucrărilor practice cu acesta. Articolul despre interacțiunea Git cu alte SUV-uri (precum Subversion, CVS, Mercurial etc.) va încheia ciclul.

2. Git este ...

Git este un sistem distribuit de control al versiunilor de fișiere. Codul programului este scris în principal în C. Proiectul a fost creat de Linus Torvalds în 2005 pentru a gestiona dezvoltarea nucleului Linux și, la fel ca GNU / Linux, este software gratuit (software), iar utilizarea unei terțe părți este supusă variantei 2. GNU GPL. Acest acord poate fi descris ca software cu cod gratuit care trebuie dezvoltat deschis, adică. orice programator are dreptul să continue îmbunătățirea proiectului în orice etapă. Pentru timpul său scurt de existență acest sistem   a fost introdus de mulți dezvoltatori de vârf. Git este utilizat în astfel de proiecte cunoscute de comunitatea Linux ca Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. Sisteme de control al versiunilor

Versiunea sistemelor de control (versiunea sistemelor de control) este un software conceput pentru a automatiza lucrul cu istoricul unui fișier (sau grup de fișiere), asigură monitorizarea modificărilor, sincronizează datele și organizează un depozit sigur al proiectului. Pe scurt, principalul obiectiv al sistemelor de control al versiunilor este de a simplifica munca cu schimbarea informațiilor. Să analizăm punctul de vedere general al dezvoltării folosind un exemplu.

Să presupunem că există un anumit proiect pe care îl dezvoltați, mai multe departamente de programatori și sunteți coordonatorul (sau liderul). În legătură cu sistemul de control, indiferent dacă este un server (dacă este un sistem centralizat) sau o mașină locală, orice dezvoltator de proiect este limitat doar de drepturile de acces pentru modificarea și / sau citirea versiunilor de fișiere acest depozit. În orice moment, puteți returna datele la versiunea de care aveți nevoie. Voi, în calitate de coordonator, puteți restricționa accesul anumitor utilizatori pentru a actualiza versiunea de fișier. SUV oferă, de asemenea, o interfață pentru monitorizarea și căutarea versiunilor de fișiere. De exemplu, puteți crea o interogare: „Unde și când s-a schimbat această bucată de cod?”.

Sistemul presupune stocarea securizată a datelor, adică orice bloc stocat în el are multe clone. Deci, de exemplu, dacă un fișier este deteriorat, îl puteți înlocui cu o copie în timp util. Pentru a reduce cantitatea de date ale proiectului, se utilizează adesea compresia delta - un tip de stocare în care nu sunt stocate versiunile de fișier în sine, ci doar schimbări între revizuirile succesive.

4. Diferențe între sistemele de control distribuite versiuni

Sistemele de control distribuit de versiuni sunt SUV-uri, principala paradigmă a acestora fiind localizarea datelor fiecărui dezvoltator de proiect. Cu alte cuvinte, dacă într-un SUV centralizat, toate acțiunile, într-un fel sau altul, depind de obiectul central (server), atunci într-un SUV distribuit, fiecare dezvoltator își păstrează propria versiune a întregului proiect. Comoditatea unui astfel de sistem este că fiecare dezvoltator are oportunitatea de a lucra independent, ocazional schimbând opțiuni de fișiere intermediare cu alți participanți la proiect. Luați în considerare această caracteristică, continuând exemplul anterior.

Fiecare dezvoltator de pe aparat are propriul său depozit local - un loc pentru stocarea versiunilor de fișiere. Lucrul cu datele proiectului este implementat în depozitul local și pentru aceasta nu este necesar să vă mențineți legătura cu restul (chiar și principalele) filiale de dezvoltare. Conectarea cu alte depozite va fi necesară numai la schimbarea / citirea versiunilor de fișiere ale altor sucursale. În același timp, fiecare participant la proiect stabilește drepturile propriului spațiu de stocare pentru a citi și scrie. Astfel, toate sucursalele din SUA distribuite sunt egale între ele, iar coordonatorul îl selectează pe cel principal. Ramura principală este diferită doar prin faptul că dezvoltatorii o vor egala mental.

5. Caracteristici și caracteristici cheie ale Git

Merită să spunem că sistemul, dacă nu a făcut un splash, atunci a stârnit puțin comunitatea în domeniul SUV cu noutatea sa și a propus o nouă cale de dezvoltare. Git oferă instrumente flexibile și ușor de utilizat pentru istoricul proiectului.

O caracteristică a Git este că lucrul la versiunile de proiect nu poate avea loc în ordine cronologică. Dezvoltarea poate fi realizată în mai multe ramuri paralele, care se pot contopi și împărți în orice moment în timpul proiectării.

Git este un sistem destul de flexibil, iar domeniul său de aplicare nu se limitează numai la domeniul de dezvoltare. De exemplu, jurnaliștii, autorii literaturii tehnice, administratorii, cadrele didactice universitare pot să-l folosească în propriile lor activități. Aceste sarcini includ controlul versiunii oricărei documentații, raport, teme.

Subliniem principalele diferențe între Git și alte SUV-uri distribuite și centralizate.

Git Architecture

SHA1 (Secure Hash Algorithm 1) este un algoritm de criptare criptografic. Fiecare fișier al proiectului dvs. din Git constă dintr-un nume și conținut. Numele este primul 20 de octeți de date, este scris vizual în patruzeci de caractere în sistemul de numere hexadecimale. Cheie dată   obținut prin hashing conținutul fișierului. Deci, de exemplu, comparând cele două nume, putem spune cu aproape o sută la sută probabilitate că au același conținut. De asemenea, numele obiectelor identice din diferite ramuri (depozite) sunt aceleași, ceea ce vă permite să operați direct pe date. Supliment bun   Ceea ce s-a spus mai sus este că hash-ul vă permite să determinați cu exactitate corupția fișierelor. De exemplu, comparând hash-ul conținutului cu numele, putem spune cu exactitate dacă datele sunt corupte sau nu. Mai departe, prin nume ne referim la numele fișierului, iar șirul de caractere se va numi hașa SHA1.

Merită menționate așa-numitele ciocniri. „Determinați corect deteriorarea” înseamnă că există astfel de fișiere, cu conținut diferit, al cărui haș SHA1 este același. Probabilitatea unor astfel de coliziuni este foarte scăzută, iar conform estimărilor preliminare este de 2 în -80 ° grad (~ 10 în -25 ° grad). Nu există o estimare exactă, deoarece momentan comunitatea mondială nu a fost în măsură să decripteze eficient această schemă criptografică.

Obiecte git

Lucrul cu versiuni de fișiere în Git poate fi comparat cu operațiunile obișnuite ale sistemului de fișiere. Structura este formată din patru tipuri de obiecte: Blob, Tree, Commit și Referințe; unele dintre ele, la rândul lor, sunt împărțite în subobiecte.

Blob (obiect binar mare) - un tip de date care conține doar conținutul fișierului și propriul haș SHA1. Blob este principalul și singurul operator de date în cadrul Git. Puteți desena o paralelă între acest obiect și inode în sistemele de fișiere, deoarece structura și obiectivele lor sunt foarte similare.

Copac (copac)

  • hash SHA1 propriu;
  • SHA1 hash de pete și / sau copaci;
  • drepturile de acces ale sistemelor Unix;
  • nume simbolic al obiectului (nume pentru uz intern în sistem).

La baza sa, un obiect este un analog al unui director. Definește ierarhia fișierelor de proiect.

comite   - un tip de date care conține:

  • hash SHA1 propriu;
  • o legătură către exact un copac;
  • o legătură cu angajamentul anterior (pot exista mai multe)
  • numele autorului și timpul de creare al angajamentului;
  • numele angajatorului (comitent - persoana care a solicitat angajarea în depozit, acesta poate diferi de autor) și momentul aplicării angajamentului;
  • o informație arbitrară (blocul poate fi utilizat pentru semnătură electronică sau, de exemplu, pentru a explica modificările angajamentului).

Acest obiect este proiectat pentru a stoca o instantanee (versiune) a unui grup de fișiere la un moment dat specific în timp, puteți să îl comparați cu un punct de control. Angajamentele pot fi unite, sucursale sau, de exemplu, stabilesc o structură liniară, reflectând astfel ierarhia versiunilor proiectului.

Referință - un tip de date care conține o legătură la oricare dintre cele patru obiecte (Blob, Arbore, Commit și Referințe). Scopul său principal este să indice direct sau indirect un obiect și să fie un sinonim pentru fișierul la care se referă. Acest lucru crește înțelegerea structurii proiectului. Este foarte incomod să funcționezi cu un set de caractere fără sens în nume, dar o legătură, spre deosebire de hașa SHA1, poate fi numită ca fiind mai convenabilă pentru dezvoltator.

Din legături, la rândul lor, putem distinge o serie de subobiecte care au unele diferențe: Ramifica, Etichetă. Luați în considerare.

Sucursală (șef, filială) - o legătură simbolică (legătură simbolică), care indică ultima din cronologia de comitere a unei anumite ramuri și stochează hașa SHA1 a obiectului. Este un tip de date a sistemelor de fișiere cu jurnalizare. Acest tip de obiect nu este definit în Git în sine, ci este moștenit de la sistemele de operare și fișiere. Ramura este folosită ca sinonim pentru fișierul la care se referă, adică. Git vă permite să îl operați direct. Vă puteți permite să nu vă gândiți dacă lucrați cu cea mai recentă versiune sau nu.

Tag (tag)   - un tip de date care, spre deosebire de ramuri, se referă invariabil la același obiect precum blob, tree, commit sau tag. La rândul său, poate fi împărțit în etichete ușoare și ușoare sau adnotate. Eticheta de lumină, pe lângă imuabilitatea legăturii, nu este diferită de ramurile obișnuite, adică. conține doar hașa SHA1 a obiectului referit în sine. O etichetă adnotată este formată din două părți:

  • prima parte conține propriul haș SHA1;
  • a doua parte constă din:
    • SHA1 al obiectului la care se indică eticheta adnotată;
    • tipul obiectului indicat (blob, arbore, angajare sau etichetă);
    • numele simbolic al etichetei;
    • data și ora la care a fost creată eticheta;
    • numele și e-mailul creatorului de etichete;
    • o bucată de date arbitrare (acest bloc poate fi utilizat pentru semnătura electronică sau pentru a explica o etichetă).

Cu alte cuvinte, un proiect în Git este o colecție de pete care sunt conectate de o rețea de copaci. Structura ierarhică rezultată poate fi, în funcție de timp, reflectată sub forma versiunilor de angajare, iar pentru a înțelege structura lor din Git există obiecte precum link-uri. Excluzând acțiunile cu link-uri, aproape toate lucrările cu obiecte de sistem sunt cât se poate de automatizate din interior. Pe baza mecanismului de legătură, ajungem la următoarea idee - să lucrăm la grupuri de fișiere. Potrivit autorului, ideea este cheia în filozofia lui Git. Prin setarea, de exemplu, a unei operații pentru un angajat dat, își elaborează recursiv partea din arborele la care se referă. Fiind o extensie a vizualizării general acceptate „acțiune asupra fiecărui fișier”, inovația simplifică implementarea și abordarea din partea programatorului asupra sarcinilor cotidiene ale SUV-ului, cum ar fi fuzionarea / divizarea ramurilor, automatizarea procesului din nou. Această abordare este ușor de înțeles, muncind rapid și flexibil în realizarea obiectivelor sale. Multe dintre aceste caracteristici sunt realizate datorită sistemului orientat Unix, adică. care operează cu dispozitive standard, Git se bazează pe cele existente în sistem de operare   soluții.

Să clarificăm momentul stocării datelor. Conținutul fișierelor din diferite versiuni din cronologie necesită multă memorie. Așadar, de exemplu, într-un proiect format din douăzeci de fișiere de douăzeci de versiuni, arhiva va cântări de 20 de ori mai mult (poate de aproximativ o sută de megabyte) și ce se va întâmpla dacă numărul acelora și al altora este de 10 ori mai mult (se pare că nu este mult)? Dimensiunea spațiului ocupat va crește de 100 de ori (adică aproximativ 1 GB). În problemele reale, rata de creștere a memoriei ocupate este departe de a fi liniar dependentă de timp. Pentru a rezolva această problemă, există mai multe optimizări:

  • fiecare obiect Git este stocat ca arhivă obișnuită (tar.gz);
  • compresia secvențială delta este utilizată pentru întreaga ierarhie de fișiere.

Să luăm un exemplu.

Aveți o istorie de trei ani a proiectului dvs., în ea există aproximativ o mie de fișiere și o sută de versiuni. Dacă la un moment dat trebuie să apelați la cea mai veche versiune, Git va trebui să decuplați compresia delta a întregului istoric de fișiere. Dezamăgitor, dar acest proces poate dura până la prânz. Git sugerează să facă așa-numitele puncte de control, adică stocați un fișier arhivat săptămânal printr-o serie de versiuni, pe care le numim adâncimea de compresie. Apoi, în exemplul nostru, întreaga poveste se restrânge la un anumit număr predeterminat de compresii delta, dezafectându-le, puteți privi orice versiune din cronologie. Rețineți că este foarte convenabil să folosiți compresia delta peste anumite tipuri de obiecte cele mai apropiate de ierarhie, pentru aceasta, depozitul trebuie să fie sortat în funcție de tip și dimensiune. Această serie de operații descrise în această clauză sunt efectuate de funcția git-repack (și git-gc care o conține).

Unirea și împărțirea ramurilor

Această problemă este foarte laborioasă și saturată, în legătură cu care introducem conceptele de fuziune și separare doar în termeni generali. Haideți să revenim la un exemplu.

Imaginează-ți momentul dezvoltării proiectului, când obiectivul principal este viteza programului. Una dintre soluțiile tactice posibile este divizarea dezvoltatorilor în două grupuri, fiecare rezolvând aceeași problemă. În acest caz, ramura istoriei proiectului ar trebui să se divizeze. Această procedură   numită ramură. Acțiunea de a ramifica o ramură este doar crearea unei copii a acesteia care va avea ulterior propriul istoric.

Să obținem două rezultate deja finalizate ale aceleiași sarcini, la care au lucrat două grupuri de programatori. Cum suntem? Vedeți al cui cod este mai rapid și mai fiabil? Aceasta este prea ușoară, dar nu întotdeauna cea mai bună soluție. O soluție bună este, având o mică înțelegere a codului și a fișierelor, să le împărțiți în subtascheri sau blocuri de cod. Și abia atunci putem identifica punctele tari și punctele slabe ale acestor piese. Desigur, această opțiune este potrivită numai dacă ați prevăzut dinainte că puteți colecta ulterior toate aceste particule împreună. Cazul când dezvoltați singur codul, îmbunătățirea și remedierea unor erori este echivalent cu exemplul dat. Acest proces   combinarea a două numere întregi într-unul se numește îmbinare. Procesul de combinare a celor două versiuni este punctul cheie al proiectului. Fie că este posibil, ar trebui să evitați executarea automată a acestei operații. O caracteristică distinctivă a Git este cea mai fiabilă și destul de bună cale rapidă   rezolvarea problemei de ramificare.

Avantajele sistemului includ:

  1. Orientare Unix.
  2. Coerența ideologică (urmând regulile de utilizare a sistemului, este foarte dificil să intri situație fără speranță   sau obține ceea ce nu te așteptai).
  3. Performanță ridicată (acesta este unul dintre cele mai evidente avantaje ale sistemului, a căror plată este „Sustenabilitatea ideologică” și „orientată către Unix”).
  4. Integrarea git-ului cu sisteme de control ale unor terți precum Subversion, Mercurial, ...
  5. Gestionarea unui grup de fișiere (sistemul nu trebuie să ia în considerare separat modificările din fiecare fișier, amintește orice modificări din întregul proiect, iar dacă trebuie să urmăriți brusc modificări, acesta va da exact partea care este asociată cu acest fișier).
  6. Operațiunea de combinare (cea mai automată implementare a unei sarcini complexe).

Dezavantajele includ:

  1. Orientare Unix (merită remarcată lipsa unei implementări mature a Git pe sistemele non-Unix).
  2. Necesitatea de a executa periodic comanda git-gc (ambalează grupuri de fișiere și șterge cele care nu sunt legate prin link-uri).
  3. Coliziuni Hash (potrivire hash SHA1 de fișiere cu conținut diferit).

6. Interfețe Git

„Câți oameni, atâtea opinii.” Să încercăm să evidențiem o serie de tipuri de interfață pentru lucrul cu sistemul. În anumite scopuri, fiecare dintre următoarele tipuri de aplicații este mai bun în felul său.

Pentru persoanele care nu sunt strâns implicate în dezvoltare, pentru „conservatori” - cei care iubesc „butoanele și marcajele” și care doresc în mod conștient să se protejeze de eforturile exorbitante de a-și aminti funcțiile, tastele și multe subtilități, opțiunea în stilul TortoiseGit sau Git Extensions este mai potrivită - simplă interfețe. Acestea vă permit să acționați în principal cu mouse-ul și să lucrați în sistemul de operare Windows obișnuit pentru mulți.





Exact tipul de interfață opus. Pentru programatorii care au nevoie să interacționeze constant cu angajații, să rezolve sarcini tipice de control al codului, pentru persoanele obișnuite să lucreze în sisteme similare Unix folosind un terminal, vizualizarea aplicațiilor este cea mai potrivită. De asemenea, sunt ușor de utilizat, puțin mai rapide și mai funcționale, însă vor trebui să își ia timp pentru a-și da seama cum să-l folosești.



Putem distinge un al treilea tip de interfață - un amestec dintre primele două. Ie aveți o aplicație de consolă, de exemplu, un shell autohton „autohton”. Puteți utiliza o serie de utilități suplimentare, cum ar fi Gitk sau QGit, pentru a afișa arbori, pentru a simplifica revizuirea ierarhiei de versiuni, diferențele dintre versiuni și pentru a căuta obiectele necesare.



7. Concluzie

Deci, cititorii își dau deja seama cum funcționează sistemele moderne de control al versiunilor. În plus, am analizat arhitectura unuia dintre cele mai populare sisteme - Git. În articolul următor, vom încerca să facem cunoștință cu unele dintre caracteristicile sale în practică - vom lua în considerare funcțiile și cheile acestora. Articolul va oferi o serie de exemple ilustrative de menținere a istoriei fișierelor, precum și filozofia sistemelor distribuite. Autorul va încerca să le arate cititorilor cum să folosească Git corect și va analiza unele greșeli tipice în utilizarea acestui GMS.

Multe dintre cele asociate dezvoltării software-ulauzit despre git. Ce sunt aceste trei litere? Este foarte important să înțelegem descrierea, precum și principiile de funcționare, pentru a utiliza în mod eficient acest sistem de control al versiunii în care, spre deosebire de alte sisteme similare, concepte complet diferite despre informație, lucrează cu ea, în ciuda similară interfață de utilizator. Deci ce este git?

descriere

Git este un sistem de control distribuit pentru versiuni pentru fișierele dezvoltate. A fost creat în 2005 de autorul sistemului de operare Linux. Acest sistem sincronizează lucrul cu site-ul și, de asemenea, salvează și actualizează modificările la fișiere. Aceasta este o abordare foarte convenabilă în cazul mai multor dezvoltatori care lucrează la un proiect. Astăzi, multe proiecte cunoscute folosesc exact Git. Ce dă utilizarea? De exemplu, dezvoltarea unei operații sisteme Android   angajat într-un număr mare de programatori. Ar fi extrem de incomod dacă unul dintre ei ar face schimbări, în timp ce ceilalți nu ar fi știut despre asta. Git permite tuturor să se țină la curent cu toate schimbările și, în caz de erori, să revină la versiuni anterioare   fișiere.

Folosirea distribuțiilor mai degrabă decât a petelor


Principala diferență între Git și celelalte este modul în care arată datele. Majoritatea programelor stochează informații sub forma unei liste cu modificările numite patch-uri pentru fișiere. Astfel de sisteme se referă la datele stocate ca un set de fișiere, precum și un set de modificări care se fac pentru fiecare fișier, în raport cu timpul. Cum stochează datele sale Git? Care este acest sistem care îl distinge de ceilalți? În loc de patch-uri, datele stocate aici sunt considerate un set de nuggets ale unui sistem de fișiere mici. Ori de câte ori un utilizator comite o nouă versiune a unui proiect, sistemul pur și simplu salvează o imagine a stării fișierelor în momentul actual. Pentru a crește eficiența în cazul în care fișierul nu a fost schimbat, sistemul nu îl salvează, ci face o legătură către o instanță salvată anterior în care au fost făcute ultimele modificări.

Aceasta este o diferență foarte importantă față de alte sisteme de control, care este inerentă Git. Care este diferența? Git devine ca puțin sistem de fișiereposedând instrumente foarte puternice care funcționează deasupra.

În principal operațiuni locale


Pentru a efectua majoritatea operațiilor în Git, aveți nevoie doar de resurse și fișiere locale. Aceasta înseamnă că cel mai adesea nu este nevoie de informații pe alte computere din rețea. Deoarece toate modificările proiectului sunt pe disc, operațiile sunt efectuate cu viteză fulger. De exemplu, pentru a vizualiza istoricul unui proiect, nu trebuie să fie descărcat de pe server. Este citit din depozitul local de pe computer. Dacă trebuie să vedeți modificările dintre versiunea fișierului făcut acum o lună și cea actuală, o puteți face foarte repede fără a fi nevoie să mergeți pe server.

Munca locală înseamnă, de asemenea, că puteți face o mulțime de lucruri fără a vă conecta la rețea. De exemplu, un dezvoltator poate face modificări în timpul transportului. În multe sisteme de control, acest lucru nu este posibil.

Monitorizarea integrității datelor

Înainte de a salva orice fișier, i se atribuie un index sub forma unui sumar de control calculat direct de Git. Ce este această valoare, care este calculată folosind algoritmi speciali și este utilizată pentru a verifica integritatea datelor în timpul stocării și transmiterii acestora. Este imposibil să schimbați nimic aici fără cunoașterea lui Git, iar aceasta este o componentă importantă a filozofiei sistemului.

Datele sunt adesea adăugate.


Aproape toate acțiunile efectuate în Git sunt adăugate la baza de date. Scoaterea lor este foarte dificilă. Puteți pierde doar informațiile care nu au fost încă salvate, dar atunci când sunt angajate, pierderea este exclusă. Din acest motiv, mulți oameni aleg Git, pentru că aici puteți experimenta fără riscuri de a face ceva ireparabil.

Stare fișier

Lucrul cu Git pentru începători presupune să vă amintiți că un fișier poate fi într-una din cele trei stări:

  • Angajat, adică fișierul este salvat în spațiul de stocare local.
  • Modificat la modificări, dar salvarea nu a fost încă finalizată.
  • Fișiere modificate pregătite care sunt marcate pentru salvare.

Deci, în proiectele care folosesc Git, există trei secțiuni pentru diferite stări de fișiere:

  • Directorul Git unde sunt stocate metadatele, precum și o bază de date de obiecte. Această parte a sistemului este cea mai importantă.
  • Directorul de lucru, care este o copie a unei versiuni a proiectului extras din baza de date.
  • Un fișier care conține informații despre salvarea ulterioară.

Instalați Git


Primul lucru de făcut pentru a utiliza sistemul de control al versiunii este instalarea acestuia. Există mai multe modalități de a face acest lucru. Principalele sunt două opțiuni:

  • Instalați Git de la sursă.
  • Instalarea pachetului pentru platforma dvs.

Instalați Git de la sursă

Dacă acest lucru este posibil, este mai bine să folosiți această opțiune, din moment ce cel mai mult versiune proaspătă. Fiecare actualizare conține de obicei multe îmbunătățiri utile, motiv pentru care dacă instalarea de la sursă nu vă este prea dificilă, este mai bine să o preferați. Da, iar majoritatea distribuțiilor Linux includ pachete vechi.

Pentru instalare, veți avea nevoie de bibliotecile necesare: expat, curl, libiconv, openssl, zlib. După instalarea lor, puteți descărca cea mai recentă versiune   sistem de control al versiunii, compilați și instalați-l.

Instalare Windows

Dacă utilizatorul nu are Linux, dar dorește să utilizeze Git, Windows acceptă și acest sistem. Iar instalarea acestuia este foarte simplă. Există un proiect msysGit, a cărui procedură de instalare este una dintre cele mai simple. Trebuie doar să descărcați fișierul instalator, care poate fi găsit pe pagina proiectului în GitHub, apoi să-l executați. La sfârșitul instalării, pe computer vor exista două versiuni - grafică și consolă.

Setare inițială Git


După instalarea sistemului de control pe computer, trebuie să efectuați unele acțiuni pentru a configura mediul pentru utilizator. Acest lucru se face o singură dată. La actualizare, toate setările sunt salvate. Pot fi schimbate în orice moment.

Git include utilitatea de configurare a git-ului, care vă permite să faceți setări și să controlați funcționarea sistemului, precum și apariție. Acești parametri pot fi stocați în trei locuri:

  • Într-un fișier care conține valori comune tuturor utilizatorilor și depozitelor.
  • Într-un fișier care conține setările unui anumit utilizator.
  • În fișierul de configurare situat în depozitul curent. Astfel de parametri sunt valabili doar pentru el.

nume personalizat

În primul rând, după instalare, trebuie să specificați numele de utilizator, precum și e-mail. Acest lucru este foarte important, deoarece fiecare angajament (conservarea stării) conține aceste date. Acestea sunt incluse în toate angajamentele asumate și nu pot fi modificate ulterior.

Dacă specificați opțiunea -global, aceste setări vor trebui făcute o singură dată.

Alegerea unui editor de text

După specificarea numelui, trebuie să selectați editorul care va fi necesar la tastarea mesajelor în Git. În mod implicit, va fi utilizat editorul de sistem de operare standard. Dacă utilizatorul dorește să folosească altul, trebuie să îl înregistrați în setările fișierului de configurare din linia core.editor.

Verificarea parametrilor

Pentru a cunoaște elementele de bază ale Git, trebuie să puteți verifica setările utilizate. Pentru a face acest lucru, utilizați config -list. Afișează toți parametrii disponibili pe care îi poate găsi. Unele nume de setare pot apărea pe listă de mai multe ori. Acest lucru se datorează faptului că Git citeste o cheie din fișiere diferite. În această situație, ultima valoare este utilizată pentru fiecare cheie. Este posibil să verificați valorile anumitor taste introducând comanda în loc de „--list” - „(cheie)”.

Cum se creează un depozit

Există două modalități de realizare a acestui obiectiv. Primul este importul unui catalog sau a unui proiect existent în sistem. Al doilea este clonarea unui depozit existent de pe server.

Creare în acest director

Dacă utilizatorul decide să înceapă să utilizeze Git pentru un proiect existent, el trebuie să meargă în director și să inițializeze sistemul. Aceasta necesită comanda git init. Ea creează un subdirector în directorul în care se vor afla toți fișiere necesare. În această etapă, controlul versiunii proiectului nu a fost încă stabilit. Pentru a adăuga fișiere sub control, trebuie să le indexați și să efectuați primele modificări de angajare.

Clonarea depozitului

Pentru a obține o copie a unui depozit existent, aveți nevoie de comanda git clone. Cu acesta, Git va primi o copie a aproape toate datele de pe server. Aceasta se aplică tuturor versiunilor fiecărui fișier. O caracteristică foarte convenabilă, deoarece în caz de eșec al serverului, programatorul va putea folosi clona de pe orice client pentru a returna serverul în starea în care se afla la clonare. Pare un punct de recuperare.

Ștergeți un fișier din Git

Puteți șterge orice fișier din sistem dacă îl excludeți din index, adică din fișierele monitorizate. Pentru a face acest lucru, aveți nevoie de comanda git rm. De asemenea, elimină fișierul din directorul de lucru al utilizatorului. Atunci trebuie să te angajezi. După acesta, fișierul dispare pur și simplu și nu va mai fi urmărit. Dacă este schimbat și deja indexat, atunci se utilizează ștergerea forțată cu opțiunea -f. Această metodă va preveni ștergerea datelor care nu au fost încă scrise în instantaneu și care nu pot fi restabilite din sistem.

Reveniți la modificări

În orice moment, poate fi necesar să anulați o acțiune. Dacă utilizatorul a executat angajarea din timp, uitând să adăugați unele fișiere, atunci îl puteți completa cu ajutorul opțiunii --amend. Această comandă este folosită pentru a comite indexul. Dacă după ultima salvare nu s-au făcut modificări, proiectul va fi în aceeași stare și va apărea un editor pentru comentarii, unde utilizatorul poate edita tot ceea ce este necesar. Trebuie reținut faptul că nu orice operațiune de anulare nu poate fi anulată. Uneori puteți șterge permanent datele necesare. Ar trebui să fie atent.

rezultate


Acum, utilizatorul ar trebui să aibă o idee despre ce este Git, de ce este nevoie de acest sistem de control al versiunilor, de cum diferă de alte produse similare. Este clar că pentru o introducere completă este necesar să instalați o versiune de lucru a Git cu setări personale. Orice manuale sau cursuri video de pe Git pentru „manechine” care vor putea ghida pas cu pas utilizatorul prin toate etapele de lucru cu sistemul nu va strica.

Acest capitol este despre a începe cu Git. Mai întâi, să învățăm elementele de bază ale sistemelor de control de versiuni, apoi să trecem la modul de a rula Git pe sistemul de operare și, în sfârșit, să-l configurăm să funcționeze. La sfârșitul capitolului, veți ști deja ce este Git și de ce trebuie utilizat și veți obține, de asemenea, un sistem care este în sfârșit configurat să funcționeze.

Despre controlul versiunii

Ce este un „sistem de control al versiunilor” și de ce este important? Un sistem de control al versiunilor este un sistem care scrie modificări într-un fișier sau un set de fișiere în timp și vă permite să reveniți mai târziu la o versiune specifică. Codul sursă al software-ului va fi folosit ca exemplu pentru a controla versiunile de fișiere din această carte, deși puteți utiliza de fapt controlul versiunii pentru aproape orice tip de fișier.

Dacă sunteți un grafic sau web designer și doriți să salvați fiecare versiune a imaginii sau a aspectului (cel mai probabil, doriți), sistemul de control al versiunilor (denumit în continuare SLE) este exact ceea ce aveți nevoie. Vă permite să returnați fișierele în starea în care se aflau înainte de modificări, să returnați proiectul stare inițială, vezi modificările, vezi cine a schimbat ultima dată ceva și a cauzat problema, cine a setat sarcina și când și multe altele. Folosirea SLE înseamnă de asemenea, în general, că dacă spargi ceva sau pierzi fișiere, îl poți repara cu ușurință. Pe lângă toate, veți obține toate acestea fără niciun efort suplimentar.

Sisteme locale de control a versiunii

Multe persoane folosesc copierea fișierelor într-un director separat ca metodă de control al versiunii (poate chiar și un director cu un timbru de timp, dacă sunt suficient de inteligente). Această abordare este foarte comună datorită simplității sale, dar este incredibil de predispusă la erori. Puteți uita cu ușurință în ce director vă aflați și puteți schimba accidental fișierul greșit sau puteți copia fișierele greșite dorite.

Pentru a rezolva această problemă, programatorii au dezvoltat demult o monedă locală cu o bază de date simplă care stochează înregistrările tuturor modificărilor din fișiere, controlând astfel reviziile.

Figura 1. Controlul versiunii locale.

Una dintre cele mai populare monede hard a fost sistemul RCS, care astăzi este distribuit cu multe calculatoare. Chiar și popularul Mac OS X furnizează comanda rcs după instalarea Instrumentelor pentru dezvoltatori. RCS stochează pe seturi de discuri de patch-uri (diferențe între fișiere) într-un format special, folosind care poate recrea starea fiecărui fișier la un moment dat.

Sisteme de control al versiunilor centralizate

Următoarea problemă serioasă cu care se confruntă oamenii este nevoia de a interacționa cu alți dezvoltatori. Pentru a face față, au fost dezvoltate sisteme de control al versiunii centralizate (CSCV). Sisteme precum: CVS, Subversion și Perforce au un singur server care conține toate versiunile de fișiere și un număr de clienți care primesc fișiere din acest depozit centralizat. Utilizarea CCSC a fost standard timp de mai mulți ani.


Figura 2. Controlul versiunii centralizate.

Această abordare are multe avantaje, în special față de moneda locală. De exemplu, toți dezvoltatorii de proiecte știu într-o oarecare măsură ce face fiecare dintre ei. Administratorii au control deplin asupra celor care pot face ce și este mult mai ușor să administreze CCSV decât să opereze baze de date locale la fiecare client.

În ciuda acestui fapt, această abordare prezintă și dezavantaje grave. Minusul cel mai evident este singurul punct de eșec reprezentat de serverul centralizat. Dacă acest server nu reușește timp de o oră, în acest timp nimeni nu va putea folosi controlul versiunii pentru a salva modificările la care lucrează și nimeni nu va putea împărtăși aceste modificări cu alți dezvoltatori. dacă hard disk, unde baza de date centrală este stocată, este deteriorată și nu există copii de rezervă în timp util, veți pierde totul - întregul istoric al proiectului, fără a număra instantaneele unice ale depozitului care au fost salvate pe mașinile locale ale dezvoltatorilor. Moneda hard local suferă de aceeași problemă - când întreaga istorie a proiectului este stocată într-un singur loc, riscați să pierdeți totul.

Sisteme descentralizate de control al versiunilor

Aici intră în joc sistemele descentralizate de control al versiunilor (DSCW). În DSCW (cum ar fi Git, Mercurial, Bazaar sau Darcs), clienții nu descarcă doar o imagine a tuturor fișierelor (starea fișierelor la un moment dat în timp): ci copiază complet depozitul. În acest caz, dacă unul dintre serverele prin care dezvoltatorii au schimbat date moare, orice depozit de clienți poate fi copiat pe un alt server pentru a continua să funcționeze. Fiecare copie a depozitului este o copie de rezervă completă a tuturor datelor.

Figura 3. Controlul versiunii descentralizate.

Mai mult, multe DSCWs pot interacționa simultan cu mai multe depozite la distanță, astfel încât puteți lucra cu grupuri diferite de oameni, aplicând abordări diferite în același timp, în cadrul aceluiași proiect. Acest lucru vă permite să aplicați mai multe abordări în dezvoltare, de exemplu, modele ierarhice, ceea ce este complet imposibil în sistemele centralizate.

Mi-a luat recent să predau elementele de bază ale Git la mai mulți dintre angajații mei care învață doar programarea și încearcă să lucreze. După ce am căutat pe Internet articole pentru începători, am descoperit că majoritatea sunt despre cum să folosești consola Git sau despre necesitatea și avantajul acesteia față de alte sisteme similare. Un începător nu este de obicei foarte puternic în toate aceste chestiuni. Cred că el, pentru început, nu are nevoie să știe toate acestea. Până la urmă, puteți utiliza Git pentru proiectele dvs. și puteți învăța toate farmecele sale în paralel cu studiul programării. Cu toate acestea,vă recomand să luați acest articol ca articol de constatare a informațiilor și să aflați mai multe despre Git în viitor..

În general, în conformitate cu un articol pentru pisici, ca folosindSmartGit și BitBucket   Îți poți îmbunătăți viața de dezvoltator începător.

M planul stacojie a ceea ce vom face:

  1. Crearea unui depozit pe Bitbucket.
  2. Clonarea unui depozit (adăugarea acestuia la SmartGit).
  3. Crearea angajamentelor.
  4. Eliminați modificările.
  5. Creați ramuri.
  6. Apăsarea ramurilor către un depozit la distanță (încărcați ramuri pe un server la distanță).
  7. Ramificați ramuri.

Hai să mergem. Crearea unui depozit este o sarcină foarte simplă. Vom folosi BitBucket pentru asta, deci trebuie să aveți un cont acolo. După înregistrare, faceți clic pe butonul „Creare” și completați câmpurile obligatorii. Clonați depozitul folosind SmartGit. Luați linkul către depozitul nostru.

Acum executați SmartGit, selectați „Proiect” - „Clonă” (sau Ctrl + Alt + O) și completați câmpurile necesare:

Sistemul vă va cere numele de utilizator și parola de la Bitbucket:


În fereastra următoare, sunt disponibile două opțiuni de clonare: „Includeți submodule” și „Obțineți toate capetele și etichetele”. Git permite stocarea modulelor separate pentru aplicații în diferite depozite. Dacă bifați opțiunea „Include submodule”, SmartGit va încărca automat toate modulele. Dacă opțiunea „Fetch all Heads and Tags” este bifată, atunci SmartGit, după crearea folderului de proiect, va descărca toate ramurile și etichetele pentru acest depozit:

Următoarea fereastră este numele proiectului în SmartGit:

Dacă ați clonat un depozit gol (ca în acest articol), veți vedea următoarea fereastră:

Mergeți mai departe. Să creăm un angajament. Ce este angajamentul? Aceasta comite modificări. Fiecare angajament „își amintește” exact ce ai schimbat și oricând poți restabili starea anterioară a fișierelor. Vă sfătuiesc să faceți un angajament după fiecare modificare semnificativă, de exemplu, să remediați o eroare într-o funcție. Pentru a crea un angajament, trebuie să schimbați ceva în proiect. Adăugați câteva fișiere în folderul proiectului:

Acum puteți vedea modificările proiectului nostru în SmartGit:

Selectați ambele fișiere și faceți clic pe „Etapa” și apoi pe „Compromis”. De ce apăsați Stage? Butonul Stage adaugă fișierele selectate la indexul curent. Dacă doriți să creați un angajament pentru două fișiere, dar schimbat, să presupunem cât mai multe 5, selectați doar aceste două fișiere, faceți clic pe „Etapă”, care le va adăuga la index și după „Commit”. Astfel, numai cele două fișiere selectate vor fi în cursul angajării.

După care va apărea o fereastră în care va trebui să introduceți un comentariu la angajare. De obicei, scrie ceea ce a fost schimbat, adăugat, șters și așa mai departe:

Apoi faceți clic pe butonul „Commit”. Butonul Commit & Push face același lucru, dar și apasă (încarcă) modificările din depozitul de la distanță (în cazul nostru, Bitbucket). Nu faceți acest lucru încă. Vom împinge mai departe. Mai jos, în lista de sucursale, apare filiala locală   «Maestrul». Aceasta este ramura principală a codului aplicației. Ce sunt ramurile, vă voi povesti puțin mai târziu. Acum să facem ceva cu proiectul nostru, apoi să redăm modificările. Voi șterge fișierul readme.txt, voi edita fișierul index.php și voi adăuga un nou fișier confic.cfg:

Acum revărsă schimbarea după comitere. Să mergem la Jurnal:

Vom selecta angajamentul la care dorim să redăm și vom face clic pe „Resetare”:

În următoarea fereastră ni se oferă să alegem ce „Resetare” dorim să facem:

Voi explica. Reamintim că la crearea unui angajament, mai întâi adăugați fișiere la index (etapă). Aceasta vă permite să comiteți doar fișiere indexate. Resetarea soft resetează doar comiterile. Indexul și modificările fizice la fișiere rămân. Resetarea mixtă funcționează la fel ca software-ul, dar șterge și indexul fișierului. Resetarea rapidă șterge angajamentele, indexul și modificările fizice din fișiere. Folosiți cu atenție resetare tareasta ar elimina din neatenție excesul.

Am făcut o resetare dificilă pentru claritate:

După cum puteți vedea, toate modificările din fișiere au dispărut, sau mai bine zis, totul a revenit la starea primei angajări.

Acum un pic despre crearea de sucursale. De ce sunt necesare deloc? Sucursala vă permite să salvați starea curentă a codului și să experimentați. De exemplu, scrieți un nou modul. Este logic să faceți acest lucru într-o ramură separată. Șeful apelează și spune că există un bug în proiect și trebuie să fie rezolvat urgent, dar modulul dvs. nu a fost adăugat. Cum se umple fișiere sparte? Trebuie doar să treceți la o ramură de lucru fără modul, să remediați o eroare și să încărcați fișierele pe server. Și când „pericolul” a trecut - continuați să lucrați la modul. Și acesta este unul dintre numeroasele exemple ale beneficiilor ramurilor.

Să încercăm să ne creăm propria ramură. Avem deja unul, acesta este maestru. Este creat automat (dacă lipsește) atunci când faceți prima angajare. Creați o altă ramură și denumiți-o „new_future1”. Apăsați F7 sau faceți clic dreapta mai jos în fila „Ramuri” din inscripția „Filiale locale” și selectați „Adăugați sucursală” din lista verticală:

Faceți clic pe „Adăugați ramură și comutator” pentru a trece imediat la sucursala creată. Acum puteți crea noi angajamente, modifica fișierele și nu vă faceți griji. Întrucât întotdeauna ai o ramură principală la care poți să te întorci. Când schimbați o ramură, Git schimbă fișierele locale pe cele din sucursală. Adică, dacă creați ramură nouă   schimbați ceva în fișierul index.php, apoi treceți la sucursala principală, apoi toate modificările pe care le-ați făcut vor fi șterse. Dacă reveniți la sucursala creată, modificările vor fi returnate.

Până acum, am lucrat la nivel local. Să încercăm să încărcăm lucrările noastre pe server. Haideți să creăm câteva comiteri în noua ramură_futură1. În cazul în care depozitul este gol și este gol, din moment ce l-am creat cu ceva timp în urmă și nu am încărcat nimic pe server, Bitbucket va atribui ramura principală care a fost descărcată mai întâi la cea principală. Prin urmare, treceți la ramura „master” și apăsați butonul „Push”:

În continuare, SmartGit vă va întreba dacă configurați urmărirea ramurilor (cofigure tracking). Urmărirea vă permite să actualizați automat ramurile relevante atunci când descărcați sau descărcați actualizări de cod. Așadar, nu ezitați să faceți clic pe „Configurare”:

Acum treceți la o altă ramură și faceți la fel. Să mergem la Bitbucket și să vedem ce s-a schimbat în secțiunea „Angajamente”:

După cum puteți vedea, totul a ajuns la serverul de la distanță.

Acum sare sare ramurile. De ce este nevoie de asta? Ia același exemplu cu modulul. Mai devreme sau mai târziu, îl veți adăuga și va trebui să adăugați codul modulului la codul principal al aplicației. Pur și simplu îmbinați ramurile. Pentru a face acest lucru, treceți la sucursala în care doriți să îmbinați codul. În cazul nostru, acesta este un maestru. După aceea, faceți clic dreapta pe sucursala din care doriți să îmbinați codul și selectați „Fuziune”:

Și acum rămâne să împingeți modificările filialei principale către server. Completați modificarea la server în același mod ca și înainte și obțineți:

Asta e totul pentru o dată. Din cauza pozelor, articolul a ieșit grozav. Întrebați-vă răspunsurile. Scrieți întrebări.

Bazele VCS

introducere

Înainte de a vorbi despre orice sistem de control al versiunilor, trebuie să înțelegeți ce este, ce sunt și de ce au apărut deloc. Această prelegere este destinată cunoașterii inițiale cu sistemele de control și gestionare a versiunilor și, mai întâi, vă voi spune despre originea instrumentelor de control de versiuni, vă voi spune ce sisteme de control de versiuni sunt populare acum și care sunt principalele diferențe între ele.

Despre controlul versiunii

Ce este controlul versiunii și de ce ai nevoie?

Probabil că merită să începeți cu definiția unui sistem de control al versiunii (SLE) - acesta este un sistem care înregistrează modificări în unul sau mai multe fișiere, astfel încât în \u200b\u200bviitor va fi posibil să reveniți la anumite versiuni vechi ale acestor fișiere.

Recent, fișierele sunt rezultatul final pentru multe profesii (de exemplu, scrierea, cercetarea și, desigur, dezvoltarea de software). Este nevoie de mult timp și efort pentru a dezvolta și întreține aceste fișiere și nimeni nu dorește să fie nevoit să aloce și mai mult timp și efort în recuperarea datelor pierdute ca urmare a oricăror modificări.

Imaginați-vă că un programator dezvoltă un proiect format dintr-un fișier mic (apropo, exemplul este destul de real, nu sintetic, întâlnit în viața reală). După lansarea primei versiuni a proiectului, el se confruntă cu o alegere dificilă: este necesar să se rezolve problemele raportate de utilizatorii primei versiuni și, în același timp, să se dezvolte ceva nou pentru a doua. Chiar dacă trebuie doar să remediați problemele care apar, este posibil ca, după orice modificare, proiectul să înceteze să funcționeze și trebuie să determinați ce s-a schimbat, astfel încât să fie mai ușor de localizat problema. De asemenea, este recomandabil să păstrați un fel de jurnal de modificări și corecții făcute pentru a nu face același lucru de mai multe ori.

În cel mai simplu caz, problema de mai sus poate fi rezolvată prin stocarea mai multor copii de fișiere, de exemplu, una pentru remedierea erorilor din prima versiune a proiectului și a doua pentru noi modificări. Deoarece modificările nu sunt de obicei foarte mari în comparație cu dimensiunea fișierului, puteți stoca doar linii schimbate folosind utilitarul dif și le îmbinați ulterior folosind utilitarul patch. Dar dacă un proiect constă din câteva mii de dosare și o sută de oameni lucrează la el? Dacă în acest caz utilizați metoda cu stocarea de copii separate ale fișierelor (sau chiar doar modificări), atunci proiectul se va bloca foarte repede. În prelegerile ulterioare, de exemplu, voi folosi codurile sursă ale programelor, dar, de fapt, fișierele de aproape orice tip pot fi plasate sub controlul versiunii.

Dacă sunteți un designer grafic sau web și doriți să stocați fiecare versiune a unei imagini sau aspect - și probabil doriți acest lucru - atunci utilizarea unui sistem de control al versiunii va fi o decizie foarte înțeleaptă. SLE face posibilă returnarea fișierelor individuale la starea lor anterioară, restaurarea întregului proiect la starea lor anterioară, vizualizarea modificărilor care apar în timp, se stabilește cine a făcut modificări ale modulului care a încetat să funcționeze brusc, cine a făcut eroarea când și multe altele. În general, dacă, folosind SLE, distrugeți totul sau pierdeți fișierele, totul poate fi restabilit cu ușurință. În plus, cheltuielile generale pentru tot ce veți obține vor fi foarte mici.

Sisteme locale de control a versiunii

Așa cum am menționat anterior, unul dintre exemplele SUV-ului local este extrem de simplu: multe persoane preferă să controleze versiunile prin simpla copiere a fișierelor într-un alt director (adăugând de obicei data curentă la numele directorului). Această abordare este foarte frecventă, pentru că este simplă, dar deseori eșuează. Este foarte ușor să uitați că vă aflați într-un director greșit și să schimbați accidental fișierul greșit sau să copiați fișierele într-un loc greșit și să ștergeți fișierele necesare. Pentru a rezolva această problemă, programatorii au dezvoltat mult timp o monedă locală locală cu o bază de date simplă care stochează toate modificările la fișierele necesare.

Una dintre cele mai populare monede tari de acest tip este RCS (Revision Control System), care este încă instalată pe multe computere. Chiar și pe Mac OS X modern, rcs este instalat cu Instrumente pentru dezvoltatori. RCS a fost dezvoltat la începutul anilor 1980 de către Walter F. Tichy. Sistemul vă permite să stocați versiuni ale unui singur fișier, deci trebuie să gestionați mai multe fișiere manual. Pentru fiecare fișier aflat sub controlul sistemului, informațiile de versiune sunt stocate într-un fișier special cu numele fișierului original la care se adaugă caracterele „, v” la final. De exemplu, pentru file.txt, versiunile vor fi stocate în file.txt, v. Această utilitate se bazează pe lucrul cu seturi de patch-uri între perechi de versiuni (un patch este un fișier care descrie diferența dintre fișiere). Acest lucru vă permite să recreați orice fișier în orice moment, aplicând secvențial patch-uri. Sistemul folosește utilitatea dif pentru a stoca versiunile. Deși RCS îndeplinește cerințele minime pentru un sistem de control al versiunii, acesta prezintă următoarele dezavantaje principale, care au servit, de asemenea, ca un stimulent pentru crearea următorului sistem:

  • Lucrați cu un singur fișier, fiecare fișier trebuie controlat separat;
  • Mecanism incomod pentru lucrul simultan al mai multor utilizatori cu sistemul, stocarea este pur și simplu blocată până când utilizatorul care îl blochează îl deblochează;
  • Nimeni nu te eliberează de copii de rezervă, riscă să pierzi totul.

Sisteme de control al versiunilor centralizate

Următoarea problemă principală a fost nevoia de a colabora cu dezvoltatorii de pe alte computere. Pentru rezolvarea acesteia, au fost create sisteme de control al versiunii centralizate (CSCV). În astfel de sisteme, de exemplu CVS, Subversion și Perforce, există un server central pe care toate fișierele sunt stocate sub controlul versiunii și un număr de clienți care primesc copii de fișiere de la acesta. De mulți ani, acesta a fost standardul pentru sistemele de control al versiunilor.

Această abordare are multe avantaje, în special față de moneda hard locală. De exemplu, toată lumea știe cine și ce este implicat în proiect. Administratorii au un control clar asupra cine și ce pot face și, desigur, administrarea CCSC este mult mai ușoară decât bazele de date locale de la fiecare client. Cu toate acestea, cu această abordare, există mai multe dezavantaje grave. Cel mai evident este că un server centralizat este o vulnerabilitate în întregul sistem. Dacă serverul se oprește timp de o oră, atunci o oră dezvoltatorii nu pot interacționa și nimeni nu poate salva versiune nouă   munca lor. Dacă discul cu baza de date centrală este deteriorat și nu copie de rezervă, pierzi absolut totul - întreg istoricul proiectului, cu excepția, poate, cu excepția mai multor versiuni de lucru care au fost salvate pe mașinile de lucru ale utilizatorilor.

CVS

CVS (Concurrent Versions System) este încă cel mai utilizat sistem, dar își pierde rapid popularitatea din cauza defectelor despre care voi discuta mai jos. Dick Grune a dezvoltat CVS la mijlocul anilor '80. Pentru a stoca fișiere individuale, CVS (precum RCS) folosește fișiere în format RCS, dar vă permite să gestionați grupuri de fișiere localizate în directoare. CVS folosește, de asemenea, o arhitectură client-server în care toate informațiile de versiune sunt stocate pe server. Utilizarea arhitecturii client-server permite utilizarea CVS chiar și de către echipele de utilizator distribuite geografic unde fiecare utilizator are propriul său director de lucru cu o copie a proiectului. După cum sugerează și numele, utilizatorii pot partaja sistemul.

Conflictele posibile la schimbarea aceluiași fișier se rezolvă prin faptul că sistemul vă permite să faceți modificări doar la cea mai recentă versiune a fișierului. Prin urmare, se recomandă întotdeauna să actualizați copia de lucru a fișierelor în caz de posibile modificări conflictuale înainte de a încărca modificările. La actualizare, sistemul face modificări ale copiei de lucru în mod automat și numai în cazul unor modificări contradictorii într-una din locațiile fișierului necesită o corecție manuală a locației conflictului.

CVS vă permite, de asemenea, să conduceți mai multe linii de dezvoltare a proiectului folosind ramurile de dezvoltare. Astfel, după cum am menționat mai sus, puteți corecta erorile din prima versiune a proiectului și puteți dezvolta simultan o nouă funcționalitate.

CVS a fost utilizat o mulțime de   proiecte, dar, desigur, nu a fost lipsit de defecte care au dus ulterior la apariția următorului sistem examinat. Luați în considerare principalele dezavantaje:

  • Deoarece versiunile sunt stocate în fișiere RCS, nu este posibilă salvarea versiunilor directoarelor. Mod standard   pentru a evita acest obstacol este să salvați un fișier (de exemplu, README.txt) într-un director;
  • Mutarea sau redenumirea fișierelor nu este supusă controlului versiunii. Modul standard de a face acest lucru este să copiați mai întâi fișierul, să îl ștergeți pe cel vechi folosind comanda cvs remove și apoi să adăugați cu noul său nume folosind comanda cvs add;
Subversion

Subversion (SVN) a fost dezvoltat în anul 2000 la inițiativa CollabNet. SVN a fost inițial dezvoltat drept „cel mai bun CVS”, iar sarcina principală a dezvoltatorilor a fost să corecteze erorile în proiectarea CVS, menținând în același timp o interfață similară. SVN, la fel ca CVS, folosește o arhitectură client-server. Cele mai semnificative schimbări în comparație cu CVS sunt:

  • Modificări atomice (angajare). Dacă procesarea angajamentului a fost întreruptă, nu se vor face modificări.
  • Redenumirea, copierea și mutarea fișierelor salvează întreaga istorie a modificărilor.
  • Directorii, link-uri simbolice și meta-date sunt supuse controlului versiunii.
  • Stocare eficientă de schimbare pentru fișiere binare.

Sisteme de control al versiunilor distribuite

Și în această situație, sistemele de control al versiunilor distribuite (RSKV) intră în joc. Pe sisteme precum Git, Mercurial, Bazaar sau Darcs, clienții nu pur și simplu descarcă cele mai recente versiuni de fișiere, ci copiază complet întregul depozit. Prin urmare, în cazul în care serverul prin care urma să moară lucrarea, orice depozit client poate fi copiat înapoi în server pentru a restabili baza de date. De fiecare dată când clientul alege cea mai recentă versiune a fișierelor, el creează o copie completă a tuturor datelor.

În plus, în majoritatea acestor sisteme puteți lucra cu mai multe depozite la distanță, astfel încât să puteți lucra simultan diferit cu diferite grupuri de persoane din cadrul aceluiași proiect. Deci, într-un singur proiect, mai multe tipuri de procese de lucru pot fi realizate simultan, ceea ce este imposibil în sistemele centralizate.

De ce avem nevoie de sisteme distribuite?

După cum sugerează și numele, una dintre ideile principale ale sistemelor distribuite este lipsa unui depozit central clar definit de versiuni - un depozit. În cazul sistemelor distribuite, setul de versiuni poate fi distribuit integral sau parțial între diverse depozite, inclusiv cele la distanță. Un astfel de model se potrivește perfect cu munca echipelor distribuite, de exemplu, o echipă de dezvoltare distribuită la nivel mondial care lucrează la un proiect cu un program deschis cod sursă. Dezvoltatorul unei astfel de echipe poate descărca toate informațiile despre versiune și poate lucra numai pe mașina locală. Imediat ce rezultatul uneia dintre etapele de lucru este atins, modificările pot fi încărcate pe unul dintre depozitele centrale sau publicate pentru vizualizare pe site-ul dezvoltatorului sau în lista de e-mailuri. Alți participanți la proiect, la rândul lor, vor putea să își actualizeze copiile din depozitul de versiuni cu noi modificări sau să încerce modificările publicate pe o ramură separată de dezvoltare a testelor. Din păcate, fără o bună organizare a proiectelor, absența unui depozit central poate fi un minus de sisteme distribuite. Dacă în cazul sistemelor centralizate există întotdeauna un depozit comun de unde puteți obține cea mai recentă versiune a proiectului, atunci în cazul sistemelor distribuite, trebuie să decideți organizațional care dintre ramurile proiectului va fi principalul. De ce ar putea interesa un sistem distribuit de control al versiunilor pentru cineva care utilizează deja un sistem centralizat - cum ar fi Subversion? Orice lucrare presupune luarea deciziilor și, în cele mai multe cazuri, este necesar să încercați diferite opțiuni: atunci când lucrați cu sisteme de control al versiunilor, ramurile de dezvoltare sunt folosite pentru a lua în considerare diverse opțiuni și pentru a lucra la mari schimbări. Deși acesta este un concept destul de natural, utilizarea lui în Subversion nu este ușor. Mai mult, totul devine mai complicat în cazul îmbinărilor multiple consecutive de la o ramură la alta - în acest caz, este necesar să indicați cu exactitate versiunile inițiale și finale ale fiecărei modificări pentru a evita conflictele și erorile. Pentru sistemele distribuite de control al versiunilor, ramurile de dezvoltare sunt unul dintre conceptele fundamentale - în majoritatea cazurilor, fiecare copie a magazinului de versiuni este o ramură de dezvoltare. Astfel, mecanismul de combinare a schimbărilor de la o ramură la alta în cazul sistemelor distribuite este unul dintre principalele, ceea ce permite utilizatorilor să depună eforturi mai puțin atunci când folosesc sistemul.

O scurtă descriere a SUV-ului distribuit popular

  • Git este un sistem de control distribuit al versiunilor dezvoltat de Linus Torvalds. Inițial, Git era destinat să fie utilizat în procesul de dezvoltare a nucleului Linux, dar mai târziu a început să fie utilizat în multe alte proiecte - cum ar fi, de exemplu, X.org și Ruby on Rails, Drupal. Git este în prezent cel mai rapid sistem distribuit folosind cel mai compact magazin de revizuire. Dar, în același timp, pentru utilizatorii care comută, de exemplu, din Subversion, interfața Git poate părea complicată;
  • Mercurial este un sistem distribuit scris în Python cu mai multe extensii în C. Dintre proiectele care utilizează Mercurial, puteți numi Mozilla și MoinMoin.
  • Bazaar este un sistem de dezvoltare susținut de Canonical, cunoscut pentru distribuția sa Ubuntu și site-ul https://launchpad.net/. Sistemul este scris în principal în Python și este utilizat de proiecte precum MySQL, de exemplu.
  • Codeville - sistem distribuit bazat pe Python folosind un algoritm inovator de schimbare a îmbinărilor. Sistemul este utilizat, de exemplu, la dezvoltarea clientului BitTorrent original.
  • Darcs este un sistem distribuit de control al versiunilor, scris în Haskell, folosit de exemplu de proiectul Buildbot.
  • Monoton - un sistem scris în C ++ și care folosește SQLite ca depozit de revizii.