Control versiune distribuită - Distributed version control

În dezvoltarea de software , controlul versiunii distribuite (cunoscut și sub numele de control al reviziilor distribuite ) este o formă de control al versiunii în care baza de cod completă , inclusiv istoricul său complet, este reflectată pe computerul fiecărui dezvoltator. Comparativ cu controlul centralizat al versiunii, acest lucru permite gestionarea automată a ramificării și fuzionării , accelerează majoritatea operațiunilor (cu excepția apăsării și extragerii), îmbunătățește capacitatea de a lucra offline și nu se bazează pe o singură locație pentru backup-uri. Git , cel mai popular sistem de control al versiunilor din lume, este un sistem de control al versiunilor distribuite.

În 2010, autorul dezvoltării software Joel Spolsky a descris sistemele de control al versiunilor distribuite ca „posibil cel mai mare progres în tehnologia de dezvoltare software din ultimii zece ani”.

Distribuit vs. centralizat

Sistemele de control al versiunii distribuite (DVCS) utilizează o abordare peer-to-peer a controlului versiunilor, spre deosebire de abordarea client-server a sistemelor centralizate. Controlul de revizuire distribuit sincronizează depozitele prin transferul patch-urilor de la egal la egal. Nu există o singură versiune centrală a bazei de cod; în schimb, fiecare utilizator are o copie de lucru și istoricul complet al modificărilor.

Avantajele DVCS (comparativ cu sistemele centralizate) includ:

  • Permite utilizatorilor să lucreze productiv atunci când nu sunt conectați la o rețea.
  • Operațiunile obișnuite (cum ar fi confirmările, vizualizarea istoricului și inversarea modificărilor) sunt mai rapide pentru DVCS, deoarece nu este nevoie să comunicați cu un server central. Cu DVCS, comunicarea este necesară numai atunci când partajarea schimbărilor între alți colegi.
  • Permite munca privată, astfel încât utilizatorii să își poată folosi modificările chiar și pentru versiunile anterioare pe care nu doresc să le publice.
  • Copiile de lucru funcționează efectiv ca copii de rezervă la distanță, ceea ce evită să se bazeze pe o mașină fizică ca un singur punct de eșec.
  • Permite utilizarea diferitelor modele de dezvoltare, cum ar fi utilizarea ramurilor de dezvoltare sau a unui model de comandant / locotenent.
  • Permite controlul centralizat al „versiunii de lansare” a proiectului
  • La proiectele software FOSS este mult mai ușor să creați un fork de proiect dintr-un proiect care este blocat din cauza conflictelor de conducere sau a dezacordurilor de proiectare.

Dezavantajele DVCS (comparativ cu sistemele centralizate) includ:

  • Verificarea inițială a unui depozit este mai lentă în comparație cu verificarea într-un sistem de control al versiunilor centralizat, deoarece toate ramurile și istoricul reviziilor sunt copiate în mod implicit pe mașina locală.
  • Lipsa mecanismelor de blocare care face parte din cele mai multe VCS centralizate și încă joacă un rol important atunci când vine vorba de fișiere binare care nu pot fi combinate, cum ar fi active grafice sau pachete binare sau XML de un singur fișier prea complexe (de exemplu, documente de birou, fișiere PowerBI, SQL Server Pachete de instrumente de date BI etc.).
  • Stocare suplimentară necesară pentru ca fiecare utilizator să aibă o copie completă a istoricului complet al bazei de cod.
  • Expunere crescută a bazei de cod, deoarece fiecare participant are o copie vulnerabilă la nivel local.

Unele sisteme centralizate inițial oferă acum unele caracteristici distribuite. De exemplu, Subversion poate face multe operații fără rețea. Team Foundation Server și Visual Studio Team Services găzduiesc acum depozite de control de versiune centralizate și distribuite prin găzduirea Git.

În mod similar, unele sisteme distribuite oferă acum caracteristici care atenuează problemele legate de timpii de plată și costurile de stocare, cum ar fi sistemul de fișiere virtuale pentru Git dezvoltat de Microsoft pentru a funcționa cu baze de cod foarte mari, care expune un sistem de fișiere virtuale care descarcă fișierele doar în spațiul de stocare local. pe măsură ce sunt necesare.

Model de lucru

Modelul distribuit este, în general, mai potrivit pentru proiectele mari cu dezvoltatori parțial independenți, cum ar fi proiectul kernel Linux, deoarece dezvoltatorii pot lucra independent și își pot trimite modificările pentru îmbinare (sau respingere). Modelul distribuit permite adoptarea flexibilă a fluxurilor de lucru personalizate pentru contribuția codului sursă. Fluxul de lucru integrator este cel mai utilizat pe scară largă. În modelul centralizat, dezvoltatorii trebuie să își serializeze munca, pentru a evita problemele cu diferite versiuni.

Depozite centrale și de sucursale

Fiecare proiect are un depozit central care este considerat depozitul oficial, care este administrat de către mentenanții proiectului. Dezvoltatorii clonează acest depozit pentru a crea copii locale identice ale bazei de cod. Modificările codului sursă din depozitul central sunt sincronizate periodic cu depozitul local.

Dezvoltatorul creează o nouă ramură în depozitul lor local și modifică codul sursă pe acea ramură. Odată ce dezvoltarea este realizată, schimbarea trebuie integrată în depozitul central.

Trageți cererile

Contribuțiile la un depozit de cod sursă care utilizează un sistem de control al versiunii distribuite se fac în mod obișnuit prin intermediul unei cereri de extragere , cunoscută și sub numele de cerere de îmbinare . Contribuitorul solicită ca întreținătorul proiectului să extragă modificarea codului sursă, de unde și denumirea „pull request”. Întreținătorul trebuie să îmbine cererea de extragere dacă contribuția ar trebui să devină parte a bazei sursă.

Dezvoltatorul creează o cerere de extragere pentru a notifica întreținătorii cu privire la o nouă modificare; un fir de comentarii este asociat cu fiecare cerere de extragere. Acest lucru permite o discuție concentrată asupra modificărilor de cod . Solicitările de extragere trimise sunt vizibile pentru oricine are acces la depozit. O cerere de extragere poate fi acceptată sau respinsă de către întreținători.

Odată ce cererea de extragere este revizuită și aprobată, aceasta este fuzionată în depozit. În funcție de fluxul de lucru stabilit, este posibil ca codul să fie testat înainte de a fi inclus în versiunea oficială. Prin urmare, unele proiecte conțin o ramură specială pentru fuzionarea cererilor de extragere netestate. Alte proiecte rulează o suită de testare automată la fiecare cerere de extragere, utilizând un instrument de integrare continuă , cum ar fi Travis CI , iar examinatorul verifică dacă orice cod nou are o acoperire adecvată a testelor.

Istorie

Primele sisteme open source DVCS au inclus Arch , Monotone și Darcs . Cu toate acestea, DVCS-urile open source nu au fost niciodată foarte populare până la lansarea Git și Mercurial .

BitKeeper a fost utilizat în dezvoltarea kernel-ului Linux din 2002 până în 2005. Dezvoltarea Git , acum cel mai popular sistem de control al versiunilor din lume, a fost determinată de decizia companiei care a făcut BitKeeper să anuleze licența gratuită pe care Linus Torvalds și unii alți dezvoltatori de kernel Linux profitaseră anterior.

Vezi si

Referințe

linkuri externe