Vă rog să-l întâmpinați pe Manish Sinha la echipa de redactare! Manish este un individ foarte inteligent, cu experiență lucrând la orice, de la Zeitgeist la Elementar.
Bună OMG! Ubuntu! cititori, aceasta este prima mea postare. În principal voi scrie despre subiecte tehnice ca editoriale.
Scopul meu este să explic subiecte tehnice dure într-un mod simplu, care ar fi util pentru wannabe contribuitorii care au considerat că contribuie prea greu din cauza curbei abrupte de învățare asociată anumite instrumente.
Colaborarea este probabil cea mai dificilă și consumatoare de timp atunci când lucrezi în echipă. Când ați auzit prima dată expresia „control de versiune”, s-ar putea să fi început să vă gândiți la cod și la programatori. Problema colaborării nu este doar cu programatorii, ci și cu alte domenii și profesie și anume cu proiectarea, documentarea etc. Controlul versiunilor ca instrument a fost extrem de faimos în cercurile de programare, dar utilizarea sa nu este limitată doar pentru codul sursă.
Când lucrați în echipă la același lucru (cum ar fi un design similar sau un set de fișiere de documentare), atunci cea mai mare problemă ar putea fi să vă asigurați că fiecare persoană are cele mai recente lucrări. Când toți contribuitorii lucrează împreună, fac modificări în fiecare parte și apoi schimbările trebuie să fie partajate.
O soluție este să vă trimiteți prin e-mail modificările doar pentru a vă deschide căsuța poștală și a vă pierde printre fotografiile lolcat sau reddit. Șansele de a omite unele dintre ele sunt, de asemenea, mari, deoarece s-ar putea să ajungeți să primiți prea multe e-mailuri. Dacă tu și un alt tip schimbați același fișier, atunci scoaterea modificărilor sale și încorporarea lor în a ta poate fi un coșmar.
O altă soluție este de a trimite toate modificările unei singure persoane, care se va ocupa de fuzionarea mai multor fișiere și de actualizarea fișierelor. Aceasta implică o persoană dedicată acestei lucrări. Ce pierdere de timp!
O altă problemă cu care s-ar putea confrunta este că, într-un anumit moment, descoperiți că situația actuală a proiectării sau documentației dvs. nu este atât de bună și cea pe care ați avut-o cu 4 zile în urmă arăta mai bine. Ce vei face?
Uită-te la fișierele trimise de tine cu 4 zile în urmă. Vânați acele fișiere în căsuța dvs. poștală, uniți toți biții și este posibil să nu fiți sigur dacă aveți setul corect de fișiere.
Ce zici de cineva te întreabă - „Cât de mult ați făcut voi în ultima lună”. Poate exista timp când doriți să vă lăudați cu cât de mult ați făcut oamenii în echipă sau dacă lucrați ca antreprenor sau angajat, este util să aveți o evidență a muncii.
Problemele majore evidențiate mai sus sunt:
Aici intră în imagine sistemele de control al versiunilor (VCS). Evit termenul „sistem de control sursă”, deoarece sună de parcă ar fi fost destinat doar codului sursă. Cele două probleme de mai sus evidențiate sunt rezolvate de VCS în mod strălucit.
Pe scurt, majoritatea VCS constă din două părți. Un server central care este utilizat de toți membrii echipei ca zonă comună în care își pun munca și, de asemenea, preluează munca altor persoane de acolo. Este o încercare de a ne sincroniza cu toți ceilalți.
A doua parte, instrumentul client al sistemului de control al versiunilor, vă ajută să vă împingeți munca către server și să extrageți lucrarea altora de pe server.
Dacă sunteți o persoană care tocmai s-a alăturat echipei, vă recomandăm să preluați toate fișierele. În acest caz, veți crea o clonă a setului de fișiere.
Furnizați adresa URL a serverului clientului dvs. VCS și acesta va prelua toate fișierele pentru dvs. Apoi, puteți începe să lucrați la aceste fișiere.
După ce ați lucrat la fișiere (remedierea erorilor, adăugarea de funcții noi etc.), decideți că această lucrare este suficientă pentru moment și doriți să partajați aceste modificări cu alte persoane.
Clientul VCS urmărește toate fișierele. Puteți să-i cereți să arate ce fișiere ați modificat și ce ați modificat în acele fișiere.
După ce verificați dacă modificările sunt în regulă, trebuie să le comiteți. Un commit nu este altceva decât un punct de salvare sau o etapă importantă. Puteți avea multe puncte de salvare într-o bază de cod.
Puteți găsi chiar și modificările pe care le-ați făcut între a treia și a patra confirmare sau a 23-a și a 25-a confirmare. Acest lucru se datorează faptului că VCS-ul dvs. știe situația actuală a fișierelor și știe, de asemenea, ce conținut era prezent atunci când ați făcut 23-a validare și ce conținut era prezent când ați făcut 26-a validare.
În captura de ecran de mai jos afișăm modificările făcute între comiterea nr. 1714 și 1716:
După efectuarea validării, VCS vă va spune că nu există modificări în așteptare.
Acest lucru se întâmplă deoarece ați angajat toate modificările în așteptare. În acest caz, trebuie să trimiteți modificările pe server. Acest lucru se face prin împingerea modificărilor adresei URL de la distanță de unde ați făcut o copie a fișierelor.
După ce ați împins, s-ar putea să fiți interesat să știți dacă altcineva și-a împins munca în timp ce efectuați modificările și le comiteți. Acest lucru se face solicitând clientului dvs. VCS să extragă modificările de pe serverul de la distanță.
Puteți încerca să trageți din nou după ceva timp dacă veți afla că altcineva din echipă și-a împins schimbările. De obicei, este o bună practică să trageți modificările înainte de a începe să lucrați la fișiere. Acest lucru s-ar putea să nu fie necesar în fiecare scenariu, dar veți avea întotdeauna cele mai recente modificări, care de obicei sunt mai bune.
În captura de ecran de mai jos, încerc să extrag modificările și am fost anunțat că nu mai există modificări.
Aceasta a fost doar o introducere a ceea ce este de fapt un sistem de control al versiunilor.
Cel pe care l-am folosit în instantanee este bazarul (aka. bzr) care este folosit în Launchpad și în alte câteva locuri (de exemplu, GNU Savannah).
Celelalte din categoria VCS sunt Subversion, Git, Mercurial etc.
Există două tipuri de control de versiune: centralizat și distribuit. Bazaar este un exemplu de sistem de control al versiunii distribuite - DVCS. Git și mercurial se încadrează, de asemenea, în această categorie, în timp ce Subversion (svn) este un VCS centralizat.
Acest articol a fost destinat persoanelor cărora le-a fost frică întotdeauna să folosească orice fel de sisteme de control al versiunilor, așa că, dacă începi să scapi, vor fi multe greșeli! Viitoarele articole vor fi foarte precise și vor folosi termeni reali.
În părțile viitoare ar trebui să vă așteptați:
.. si multe altele.
Mulțumiri!
Totul Ubuntu, zilnic. Din 2009.