eliberarea unui sistem distribuit de gestionare a codului sursă . Git este unul dintre cele mai populare, fiabile și performante sisteme de gestionare a versiunilor, oferind instrumente flexibile pentru dezvoltarea non-liniară, bazate pe ramificare și fuziune. Pentru a asigura integritatea istoricului și rezistența la modificările retroactive, se folosește o funcție implicită de hashing a întregii istorii anterioare în fiecare commit, fiind posibilă și autentificarea digitală a semnăturilor dezvoltatorilor pentru anumite tag-uri și commits.
Comparativ cu versiunea anterioară, noua versiune include 745 de modificări, pregătite cu participarea a 74 de dezvoltatori, dintre care 18 au participat pentru prima dată la dezvoltare. :
- Disponibil începând cu versiunea 1.18, noul mod de transfer al setului de commit-uri „git rebase —rebase-merges” a înlocuit vechea opțiune „—preserve-merges”, care acum este marcată ca fiind învechită. Operațiunea „git rebase” este utilizată pentru a înlocui o serie de commit-uri cu un nou commit de bază, de exemplu, pentru a aduce o ramură separată, în care se dezvoltă o nouă caracteristică, la starea actuală a ramurii master, care include corecții adăugate după ramificare:
o — o — o (my-feature)
/
o — o — o — o — o (master)
o — o — o (my-feature)
/
o — o — o — o — o (master)
Pentru a păstra structura ramificării în ramura portabilă, înainte putea fi utilizată opțiunea „—preserve-merges”, care, atunci când era executată în modul interactiv (git rebase -i —preserve-merges), permitea editarea istoricului commit-urilor, dar nu garanta păstrarea completă a structurii repository-ului. Moda „—rebase-merges” care a venit înlocuind-o permite păstrarea structurii modificărilor în ramura portabilă, oferind în același timp un set complet de operații interactive, inclusiv ștergerea, reorganizarea și redenumirea commit-urilor.
De exemplu, „—rebase-merges” reîncărca commit-uri dintr-o ramură separată în ramura master mai nouă, păstrând în același timp structura ramificării în ramura portabilă și făcând pe parcurs unele modificări în notițele commit-urilor.
- A fost adăugată suportul pentru crearea unei noi ramuri pe baza rezultatului determinării bazei de îmbinare a două alte ramuri (merge base, legat de strămoșul comun) prin utilizarea construcțiilor „git branch new A…B” și „git checkout -b new A…B”, în care „A…B” înseamnă determinarea bazei de îmbinare între cele două commit-uri specificate, similar cu modul în care „git checkout A…B” mută HEAD pe commit-ul de bază și „diff A…B” arată modificările dintre commit-ul „B” și strămoșul comun cu commit-ul „A”.
De exemplu, când lucrezi pe o ramură separată my-feature, această funcționalitate propusă poate fi utilizată când este necesar să începi de la o altă ramură, de exemplu, de la același punct în ramura master de unde a fost extrasă ramura my-feature. Anterior, era necesar să examinezi manual jurnalul modificărilor, ceea ce crea neplăceri în prezența unei istorii extinse de modificări, apoi să execuți „git merge-base master my-feature” pentru a calcula hash-ul bazei de îmbinare între ramurile master și my-feature și a crea o nouă ramură în raport cu strămoșul comun „git branch my-other-feature hash”. În Git 2.22, pentru a crea o ramură în raport cu baza de îmbinare a două alte ramuri, se poate utiliza sintaxa „git branch my-other-feature A…B”;
- A fost adăugată opțiunea „git branch —show-current” pentru a afișa numele ramurii obținute în urma execuției operațiunii checkout;
- A fost adăugată opțiunea „git checkout —no-overlay — dir”, permițând ca, în urma execuției operațiunii checkout, conținutul directorului dir să fie adus într-o formă care să corespundă complet stării ramurii master. De exemplu, dacă în copia locală a directorului dir există un fișier care lipsește în ramura master, prin execuția „git checkout master — dir” va rămâne, dar prin specificarea opțiunii „—no-overlay” va fi șters;
- În comanda „git diff” a fost activat un API universal pentru analiza opțiunilor, ceea ce a permis uniformizarea prelucrării opțiunilor cu alte utilitare git. De exemplu, în „git diff” pentru toate opțiunile acum sunt disponibile și antagonistii lor („—function-context” și „—no-function-context”);
- A fost adăugată capacitatea de filtrare în ieșirea „git log” a etichetelor extinse atașate commit-urilor („trailer” – steaguri informaționale suplimentare, cum ar fi Signed-off-by și Co-authored-by). Este posibilă filtrarea etichetelor atât după cheie, cât și după valoare, de exemplu:
„git log —pretty=„%(trailers:key=Reviewed-by,valueonly)”; - A fost adăugat un nou mecanism de trasare Trace2, care oferă un format de ieșire mai flexibil și structurat. Trace2 permite colectarea telemetriei despre operațiunile efectuate și datele de performanță pentru o analiză și depanare mai detaliată (handlerul este definit de utilizator, fără a trimite date externe);
- A fost îmbunătățit raportul „git bisect”, care acum evidențiază mai clar commit-urile problematice și oferă o statistică sumară a modificărilor pentru fiecare fișier (la nivelul numărului de linii modificate);
- A fost revizuită heuristica pentru determinarea redenumirilor directoarelor, pentru a exclude marcajele false de redenumire. În cazul în care există îndoieli, astfel de directoare sunt acum marcate ca fiind conflictuale;
- Este generat un avertisment atunci când se încearcă să se instaleze un tag pe alt tag, ceea ce, de obicei, se face din greșeală și poate duce la instalarea unei etichete pe un commit greșit (de exemplu, comanda de tip „git tag -f -m „updated message” my-tag1 my-tag2” va crea un tag pe un tag vechi, în timp ce dezvoltatorul se aștepta ca noul tag să fie instalat pe commitul indicat de tagul vechi);
- A fost inclusă generarea pentru repozitoarele bitmap (structura de disc „reachability bitmaps”), care păstrează informații despre seturile de obiecte disponibile pentru fiecare commit și permit identificarea rapidă a existenței unui obiect de bază. Această structură reduce semnificativ timpul necesar pentru operațiile de extragere a datelor (git fetch).
Sursa: opennet.ro
