Git (software)

Acest articol sau secțiune referitoare la informatică este considerat a fi verificat .

Motiv : orice altceva decât stilul enciclopedic, numeroase afirmații POV

Alăturați-vă discuției și / sau corectați intrarea. Urmați sfaturile de proiectare de referință .

Acest articol sau secțiune despre subiectul software nu menționează sursele necesare sau cei prezenți sunt insuficienți .

Puteți îmbunătăți această intrare adăugând citate din surse de încredere în conformitate cu liniile directoare privind utilizarea surselor . Urmați sfaturile de proiectare de referință .

Git software


Tip	Controlul versiunii
Dezvoltator	inițial Linus Torvalds , în prezent Junio Hamano
Data primei versiuni	7 aprilie 2005
Ultima versiune	2.33.0 (16 august 2021)
Sistem de operare	GNU / Linux macOS Microsoft Windows Solaris
Limba	Unix shell Piton C ++ Tcl C. Perl
Licență	GNU GPL v2 ( Licență gratuită )
Site-ul web	git-scm.com
Editați datele pe Wikidata · Manual

Git este un software de control al versiunii distribuite care poate fi utilizat de pe o interfață de linie de comandă , creat de Linus Torvalds în 2005 .

Git (care în argoul britanic înseamnă idiot ^[1] ) sa născut pentru a fi un instrument simplu pentru a facilita dezvoltarea kernel-ului Linux și a devenit unul dintre cele mai populare instrumente de control al versiunilor . Designul său a fost inspirat de instrumente similare (pe atunci proprietare ), cum ar fi BitKeeper și Monotone .

Istorie

Dezvoltarea Git a început după ce mulți dezvoltatori de kernel Linux au fost forțați să abandoneze accesul la codul sursă prin sistemul propriu BitKeeper . Abilitatea de a utiliza BitKeeper gratuit a fost retrasă de titularul drepturilor de autor Larry McVoy după ce a susținut că Andrew Tridgell a inventat protocoalele.

La Linux.Conf.Au conferința din 2005, Tridgell a demonstrat în discursul său că procedura de inginerie inversă el a folosit a fost pur și simplu telnet la portul corespunzător de pe un server Bitkeeper și de tip „ajutor“.

Torvalds dorea un sistem distribuit pe care să-l poată folosi ca BitKeeper, dar niciunul dintre sistemele disponibile în mod liber nu-i satisfăcea nevoile, în special nevoia sa de viteză. Iată un mesaj de e-mail (tradus în italiană) pe care l-a scris pe 7 aprilie 2005 în timp ce scria primul prototip:

„Toate sistemele de control al versiunilor pe care le-am considerat îngreunează [treaba]. Unul dintre lucrurile (de fapt, principalul lucru) la care am lucrat este acela de a face acest proces cu adevărat eficient . Dacă durează jumătate de minut pentru a aplica un patch și trebuie să vă amintiți limitele modificărilor aplicate etc. (și, sincer, s-ar putea să luați în considerare o scurtă jumătate de minut pentru majoritatea sistemelor de control al versiunilor și pentru un proiect de dimensiunea Linux), apoi o serie de 250 de e-mailuri (ceea ce nu este deloc nemaiauzit când mă sincronizez cu Andrew, pentru exemplu) durează două ore. Nici BitKeeper nu a fost rapid (de fapt, în comparație cu orice altceva, BitKeeper este foarte rapid, adesea o comandă sau două mai bune) și a durat aproximativ 10-15 secunde pe e-mail când fuzionam cu Andrew. Cu toate acestea, cu BitKeeper nu a fost o mare problemă, deoarece BitKeeper <-> Fuziunile BitKeeper sunt mai simple și niciodată nu a trebuit să fac o fuziune manuală mai lentă cu ceilalți dezvoltatori de bază.

Prin urmare, îmbinarea într-un sistem de control al versiunii bazat pe patch-uri ar trebui să fie mai rapidă decât BitKeeper. Ceea ce este cu adevărat dificil. Și de aceea scriu câteva scripturi pentru a încerca să urmăresc lucrurile mult mai repede.

Indicațiile inițiale sunt că ar trebui să pot face acest lucru la fel de repede ca patch-uri singur. Dar, sincer, cel mai bine sunt la jumătatea sarcinii și, dacă întâmpin obstacole, este posibil să nu fie deloc cazul. Motivul pentru care pot face acest lucru atât de repede este că scripturile mele nu vor fi un sistem de control al versiunilor, ci vor fi un tip foarte specific de tip „jurnal de stare Linus”. Acest lucru va face ca patch-urile să se îmbine mult mai rapid și, prin urmare, fezabile.

(Dacă durează trei secunde pentru a aplica un patch, chiar și o serie lungă de patch-uri nu este o problemă: dacă sunt avertizat într-un minut sau două că îmbinarea a eșuat la jumătatea drumului, este în regulă, în acest caz pot continua să o remedi la Acesta este motivul pentru care latența este esențială - dacă aș face lucrurile complet „offline”, prin definiție nu aș putea rezolva problemele atunci când se vor întâmpla). ”

Linus avea diverse criterii de proiectare:

Luați CVS ca exemplu de ceea ce nu trebuie făcut; dacă aveți dubii, faceți exact opusul. Pentru a-l cita pe Linus, care a vorbit puțin ironic:
„În primii 10 ani de întreținere a nucleului, am folosit literalmente tarballs (arhive comprimate) și patch-uri, care este un sistem de gestionare a sursei mult mai bun decât CVS. Apoi am ajuns să folosesc CVS timp de 7 ani într-o companie [probabil Transmeta ] și îl urăsc cu pasiune. Când spun că urăsc CVS cu pasiune, trebuie să mai spun că, dacă există utilizatori SVN ( Subversion ) în public, s-ar putea să doriți să plecați. Pentru că datorită urii mele față de CVS consider Subversion cel mai puțin sensibil proiect care a început vreodată. Pentru o vreme, sloganul Subversion a fost „CVS făcut bine”, sau ceva de genul acesta, iar dacă începeți cu acest tip de slogan, nu puteți merge nicăieri. Nu există nicio modalitate de a face CVS bine. "
Suport pentru un flux de lucru distribuit, similar cu BitKeeper. La fel ca BitKeeper, Git nu folosește un server centralizat.
„BitKeeper nu este doar primul sistem de control sursă pe care l-am crezut vreodată că merită folosit; De asemenea, sistemul a fost cel care m-a făcut să înțeleg de ce este de fapt necesar și cum poate fi operat eficient. Prin urmare, deși din punct de vedere tehnic Git este foarte diferit de BitKeeper (care a fost un alt obiectiv de proiectare, pentru că am vrut să clarific că nu era o clonă BitKeeper), multe dintre procesele pe care le folosim cu Git provin direct din procesele pe care le-am învățat de la BitKeeper. "
Protejați-vă de corupția datelor, indiferent dacă este accidentală sau intenționată
Performanță foarte ridicată

Primele trei criterii nu au fost îndeplinite de niciun sistem de control al versiunilor preexistent, cu excepția Monotone , iar al patrulea a exclus, de asemenea, Monotone. Prin urmare, imediat după dezvoltarea versiunii 2.6.12-rc2 a kernel-ului Linux, s-a dedicat scrierii lui.

Dezvoltarea Git a început pe 3 aprilie 2005 . Proiectul a fost anunțat pe 6 aprilie 2005 și a fost utilizat pentru gestionarea sursei dvs. din 7 aprilie 2005 . Prima fuziune a mai multor sucursale într-una a fost făcută la 18 aprilie 2005 . Torvalds și-a atins obiectivele de performanță: pe 29 aprilie 2005 , Git a reușit să aplice 6 sau 7 patch-uri pe Linux într-o secundă. La 16 iunie 2005 , a fost lansată versiunea 2.6.12 a kernel-ului Linux, prima care a fost gestionată cu Git.

Deși puternic influențat de BitKeeper, Torvalds a încercat în mod deliberat să evite abordările convenționale, ceea ce a dus la un sistem foarte inovator.

Torvalds a dezvoltat sistemul până când a devenit utilizabil de către utilizatorii tehnici; apoi, la 26 iulie 2005 , a predat întreținerea lui Junio Hamano, un important contribuitor la proiect. Hamano a fost responsabil pentru versiunea 1.0, lansată pe 21 decembrie 2005 și rămâne întreținătorul astăzi.

Descriere

Caracteristici

Proiectul Git este sinteza experienței lui Torvalds în menținerea unui mare proiect de dezvoltare distribuită, cunoștințele sale intime despre performanța sistemului de fișiere și nevoia urgentă de a produce un sistem satisfăcător în cel mai scurt timp. Aceste influențe au condus la următoarele opțiuni de implementare:

Suport puternic pentru dezvoltare neliniară. Git acceptă ramificarea și fuzionarea rapidă și convenabilă și include instrumente specifice pentru vizualizarea și navigarea într-un istoric al dezvoltării neliniare. O presupunere centrală în Git este că o modificare va fi combinată mai des decât este scrisă, deoarece este transmisă prin mâinile diferiților recenzori. Torvalds însuși face majoritatea fuziunilor și o mică parte din codurile directe corecte, așa că el însuși a dovedit că funcționează bine.
Dezvoltare distribuită. Similar cu Bazaar , Darcs , BitKeeper , Mercurial , SVK și Monotone , Git oferă fiecărui dezvoltator o copie locală a întregului istoric al dezvoltării, iar modificările sunt copiate dintr-un depozit în altul. Aceste modificări sunt importate ca ramuri de dezvoltare suplimentare și pot fi combinate în același mod ca o ramură dezvoltată local.
Depozitele pot fi publicate cu ușurință prin HTTP , FTP , ssh , rsync sau un protocol special git. Git are, de asemenea, o emulare a serverului CVS, care vă permite să utilizați clienții CVS și pluginurile IDE existente pentru a accesa depozitele Git.
Gestionarea eficientă a proiectelor mari. Git este foarte rapid și scalabil. Este de obicei un ordin de mărime mai rapid decât alte sisteme de control al versiunilor și două ordine de mărime mai rapide pentru unele operații ^[2] .
Autentificarea criptografică a istoriei. Istoricul Git este stocat în așa fel încât numele unei anumite revizuiri (în terminologia Git, un „commit”) depinde de istoricul complet de dezvoltare care duce la acel commit. Odată ce a fost publicat, nu mai este posibil să modificați versiunile vechi fără ca acest lucru să fie observat. ( Monotone are, de asemenea , această proprietate.)
Proiectarea setului de instrumente. Git este un set de programe de bază scrise în limbajul C și multe scripturi shell care oferă încapsulări convenabile. Este ușor să legați componentele împreună pentru a face alte lucruri utile.
Strategii de fuziune interschimbabile. Ca parte a designului setului de instrumente, Git are un model bine definit al unei îmbinări incomplete și are mai mulți algoritmi pentru a încerca să o finalizeze. Dacă toți algoritmii eșuează, eșecul este raportat utilizatorului și este solicitată o îmbinare manuală. Prin urmare, este ușor să experimentați cu noi algoritmi de amestecare.
Gunoaiele se acumulează până când sunt colectate. Anularea unei comenzi sau eliminarea modificărilor lasă obiecte inutilizabile în baza de date. De obicei, acestea sunt doar o mică parte din istoria în continuă creștere a obiectelor utile, dar comanda git gc --prune , git gc --prune , poate dura mult timp.

O proprietate a lui Git care a produs controverse considerabile este faptul că este nevoie de instantanee de arbori întregi de directoare de fișiere, mai degrabă decât de fișiere individuale. Primele sisteme de control al versiunii codului sursă, SCCS și RCS , au funcționat pe fișiere unice și s-au lăudat cu economiile de spațiu realizabile prin codificarea delta a versiunilor similare. Sistemele de control de versiune ulterioare au păstrat acest concept de identitate a fișierelor ca revizuiri ale unei modificări a proiectului.

Git respinge acest concept și nu înregistrează în mod explicit rapoartele de revizuire a fișierelor la niciun nivel din arborele codului sursă. Acest lucru are consecințe semnificative:

De fapt, este puțin mai scump să examinăm istoricul modificărilor unui singur fișier decât cel al întregului proiect. Pentru a obține istoricul modificărilor care afectează un fișier dat, Git trebuie să treacă peste istoricul general și apoi să determine ce modificări au afectat acel fișier. Cu toate acestea, această metodă de examinare a istoriei permite Git să producă la fel de eficient un singur istoric care să arate modificările unui set arbitrar de fișiere. De exemplu, un subdirector al arborelui sursă plus un fișier de antet global asociat.
Modificările numelui fișierului și directorului sunt tratate implicit mai degrabă decât explicit. O mare reclamație din partea utilizatorilor CVS este că folosește numele unui fișier pentru a-și identifica istoricul de revizuire, deci nu este posibil să mutați un fișier sau să-l redenumiți fără a-i sparge istoricul, precum și să redenumiți istoricul, făcându-l inexact. Majoritatea sistemelor de control al versiunilor după CVS rezolvă această problemă oferind fiecărui fișier un nume intern unic, de lungă durată, care supraviețuiește schimbării numelui. Git nu stochează un astfel de identificator, iar acest lucru este descris ca un avantaj. Fișierele codului sursă sunt uneori rupte sau combinate, precum și pur și simplu redenumite, iar stocarea unor astfel de modificări ca o simplă schimbare de nume ar îngheța pentru totdeauna o descriere inexactă a ceea ce s-a întâmplat în istorie. Git abordează acest lucru prin detectarea modificărilor de nume în timpul navigării istoricului instantaneelor în loc să le stocheze atunci când faceți un instantaneu. (Pe scurt, având în vedere un fișier la revizuirea N, un fișier cu același nume la revizuirea N-1 este strămoșul său implicit. Cu toate acestea, atunci când nu există fișiere cu un nume similar cu versiunea N-1, Git caută un fișier care a existat doar la versiunea N-1 și are un conținut foarte asemănător cu noul fișier.) Acest lucru necesită mai multă funcționare a procesorului de fiecare dată când priviți istoricul și câteva opțiuni pentru calibrarea euristicii.

În plus, utilizatorii sunt uneori deranjați de modelul de stocare:

Ambalarea periodică explicită a obiectelor. Git stochează fiecare obiect nou într-un fișier separat.

Deși acest fișier este într-un format comprimat, poate ocupa mult spațiu și poate fi ineficient. Această problemă este rezolvată prin utilizarea „pachetelor” care stochează multe obiecte într-un singur fișier (sau într-un flux de date prin rețea), care în sine au compresie delta. Pachetele sunt comprimate cu euristica că fișierele cu același nume sunt probabil similare, funcționează bine chiar dacă această ipoteză nu este validă. Obiectele nou create (adică nou adăugate la istoric) sunt încă stocate individual și, pentru a menține eficiența, ar trebui să le împachetați periodic.

Git implementează diverse strategii de fuzionare; în faza de fuziune puteți alege un comportament diferit de cel implicit:

rezolva: Acesta este algoritmul tradițional de îmbinare în 3 direcții.
recursiv (recursiv): Acesta este algoritmul implicit la extragerea sau fuzionarea unei ramuri și este o variantă a algoritmului de fuziune cu 3 căi. „Când există mai mulți strămoși comuni care pot fi folosiți pentru o fuziune cu 3 căi, creează un arbore de fuziune strămoșe comun și îl folosește ca arbore de referință pentru fuziunea cu 3 căi. Acest lucru are ca rezultat mai puține conflicte de fuziune fără a provoca defecțiuni. - fuziuni din testele efectuate pe versiunile reale de fuziuni preluate din istoricul dezvoltării kernel-ului Linux 2.6. De asemenea, acest lucru poate dezvălui și gestiona modificările de nume. "
caracatiță (caracatiță): acesta este algoritmul implicit atunci când fuzionați mai mult de două capete.

Implementare

Primitivele Git nu constituie inerent un sistem de control al versiunilor. De exemplu, git nu oferă numerotarea secvențială a reviziilor software.

Torvalds explică că,

„În multe feluri poate fi considerat un sistem de fișiere git - este adresabil prin conținut și include versiunea conceptului , dar de fapt am planificat să privesc problema din perspectiva unei persoane calificate în sistemul de fișiere (ei bine, nucleele sunt ceea ce Da) și de fapt am un interes absolut zero în crearea unui sistem tradițional de gestionare a configurației software. "

(Rețineți că opinia sa s-a schimbat de atunci.)

Git are două structuri de date , un index modificabil care conține informații despre conținutul următoarei revizuiri și o bază de date de obiecte care poate fi adăugată numai și care conține patru tipuri de obiecte:

Un obiect blob este conținutul unui fișier . Obiectele Blob nu au nume, dată, oră sau alte metadate. Git stochează fiecare revizuire a unui fișier ca un obiect blob separat.
Un obiect arbore este echivalentul unui director: conține o listă de nume de fișiere, fiecare cu niște biți de tip și numele unui obiect blob sau arbore care este fișierul, linkul simbolic sau conținutul directorului. Acest obiect descrie un instantaneu al arborelui sursă.
Un obiect de comitere (revizuire) leagă obiectele de copac dintr-un istoric. Conține numele unui obiect arbore (din directorul sursă de nivel superior), data și ora, un mesaj jurnal și numele a zero sau mai multe obiecte de comitere părinte. Relațiile dintre blob-uri pot fi găsite examinând obiecte de copac și obiecte de comitere.
Un obiect etichetă (etichetă) este un container care conține referințe la un alt obiect, poate conține meta-date suplimentare referitoare la un alt obiect. Cea mai obișnuită utilizare a acestuia este de a stoca o semnătură digitală a unui obiect de validare corespunzător unei anumite eliberări de date gestionate de Git.

Bloburile sunt fișiere binare „care nu vorbesc” care stochează informații eterogene, precum: fișiere textuale sau binare, imagini, cod sursă , arhive . Orice tip de fișier este comprimat într-un fișier binar înainte de a fi salvat în depozitul Git. Git calculează hash-ul cu algoritmul SHA-1 .
Hash-ul este o secvență de 40 de caractere alfanumerice, reprezentând un număr hexazecimal și este utilizat de Git pentru a identifica în mod unic orice commit din depozit, urmărind fișierul de acolo și orice modificări aduse. Hash-ul SHA-1 al unui obiect este unic, făcându-l același indiferent de depozit și computerul utilizat. Git calculează acest cod hash și îl folosește ca nume al obiectului și ca identificator al conținutului său: fișiere cu nume și / sau căi diferite, dar cu conținut identic (blob), partajează același hash. ^[3]

Indexul este un strat intermediar care servește ca o legătură între baza de date obiect și arborele de lucru.

Baza de date are o structură simplă. Obiectul este plasat într-un director care se potrivește cu primele două caractere ale codului său hash; Restul codului este numele fișierului care conține acel obiect. Când adăugați un obiect nou, acesta este stocat integral după ce l-ați comprimat cu zlib .

Acest lucru poate provoca o mulțime de spațiu pe hard disk pentru a fi ocupat într-un timp scurt, astfel încât obiectele pot fi combinate în pachete , care utilizează compresie delta (stocând doar modificările între un blob și alt blob) pentru a economisi spațiu.

Portabilitate

Git este destinat să ruleze pe toate sistemele de operare bazate pe GNU / Linux , dar funcționează și pe alte sisteme asemănătoare unix , inclusiv BSD ,Solaris și Darwin . Git este extrem de rapid pe sistemele bazate pe POSIX, cum ar fi cele de mai sus.

Git poate fi, de asemenea, portat într-un mediu Windows . Există de fapt două posibilități pentru a face acest lucru: cea „oficială” necesită instalarea și utilizarea mediului Cygwin (care este o emulare POSIX ); alternativa este un port nativ, adică o modificare a codului sursă pentru al adapta la Windows. Git pe Windows este semnificativ mai lent, datorită utilizării masive de către Git a funcțiilor sistemului de fișiere POSIX care trebuie emulate într-un mediu Windows. De asemenea, mulți oameni consideră că instalarea Cygwin este prea mare și invazivă pentru un utilizator tipic Windows.

Există multe proiecte open source care au renunțat în mod explicit la utilizarea Git pentru moment din cauza lipsei de compatibilitate cu Windows, inclusiv Mozilla și Ruby .

Un port nativ pentru Windows, denumit „WinGit” care a devenit ulterior „Git pe MSys”, se apropie de finalizare utilizând compilatorul MinGW .

În unele cazuri (în special pentru accesul la distanță anonim), utilizatorii Windows pot fi admiși prin intermediul git-cvsserver (care emulează un server CVS, permițând utilizarea clienților CVS pentru Windows). Alte alternative sunt:

Un client GIT bazat pe EclipseIDE, care folosește o implementare Java pură a funcțiilor interne ale GIT
O extensie Windows Explorer bazată pe libgit + cygwin.dll (un proiect pentru un software similar cu TortoiseCVS a început deja)

Încapsularea operațiilor git de nivel inferior într-o bibliotecă ar permite teoretic reimplementarea componentelor de nivel inferior pentru Windows fără a fi nevoie să rescrieți restul.

Aceste eforturi, în general, ar trebui să contribuie la îmbunătățirea performanței și a ușurinței de instalare pe Windows; cu toate acestea, nu este clar dacă acestea vor ajuta la rezolvarea problemei diferitelor modele de autorizare.

Proiecte asociate

Proiecte care se bazează pe Git

git-gui este un GUI bazat pe Tk pentru cele mai frecvente operațiuni Git. Acest proiect este încorporat în versiunea Git 1.5.0 și ulterioară. (Este lansat cu comanda „git gui”).
Cogito ( pagina principală ) - Petr Baudiš a menținut un set de scripturi numite Cogito (fost git-pasky), care formează un sistem de control al versiunilor care folosește Git ca backend. Dezvoltarea Cogito a fost oprită în aprilie 2007, când funcționalitatea sa a fost considerată redundantă cu instrumentele frontale Git, denumite în mod obișnuit „porțelan”.
StGIT ( pagina de pornire ) - Stacked GIT este o aplicație Python care oferă funcționalitate asemănătoare cu Quilt ( pagina de pornire ) (adică adăugarea / eliminarea patch-urilor din / dintr-o stivă) bazându-se pe Git, pentru a gestiona patch-urile până când acestea sunt îmbinate.
pg (Patchy GIT) este o interfață de script shell pentru Git pentru a ajuta utilizatorul să gestioneze un set de patch-uri de fișiere. pg este oarecum similar cu Quilt sau StGIT, dar are un set ușor diferit de caracteristici. pg nu mai este menținut din 29 aprilie 2007
DarcsGit Arhivat pe 29 septembrie 2007 la Internet Archive . este o extensie a Darcs care îi permite să interacționeze cu depozitele Git.
bzr-git este un plugin Bazaar pentru citirea copacilor Git. În timp ce se află încă în stadiul alfa, oferă suficient suport pentru vizualizarea bzrk .

Interfețe web

Gogs : Un frontend git cu gestionarea utilizatorilor, raportare, furculițe și multe alte caracteristici, scris în go .
Gitea : o furcă comunitară de Gogs.
gitweb ^{[ link rupt ]} - o implementare Perl întreținută de Kay Sievers. Folosit de site-ul kernel.org
wit Arhivat la 19 ianuarie 2008 la Internet Archive . - o implementare Python întreținută de Christian Meder.
gitarella - o implementare Ruby întreținută de Diego Elio Pettenò
git-php - o implementare PHP de către Zack Bartel
cgit - o implementare C de către Lars Hjemli
Bitbucket folosește sisteme de control al versiunilor Git din octombrie 2011.

Vizualizarea istoricului

Gitk este un simplu GUI Tcl / Tk pentru a consulta cu ușurință istoricul depozitelor Git, distribuite cu Git.
QGit ( pagina proiectului SourceForge) este un GUI Qt pentru consultarea istoricului depozitului, similar cu Gitk.
Chicotească este un Gitk-inspirat GTK + GUI.
gitview ^{[ link rupt ]} este un Python și Gtk + GUI, distribuit cu Git.
tig este o interfață de text pe ecran complet bazată pe ncurses pentru Git ".
git-browser este un program de navigare istoric scris în JavaScript care poate fi utilizat într-un browser web. (Se pare că nu vă permite să revizuiți modificările codului, doar descrierile.)

Notă

^ Înțelesul lui git , la wordreference.com . Adus pe 9 iunie 2016.
^ Roland Dreier, Oh ce ușurare este , su digitalvampire.org , 13 noiembrie 2006. , observând că „git log” este de 100 de ori mai rapid decât „svn log”, deoarece acesta din urmă trebuie să contacteze un server la distanță.
^ Ferdinando Santacroce, Git: Ghid pentru a învăța cum să gestioneze, să distribuie și să versioneze codul , Milano, Apogeo, 2017, pp. 47, 52-53, ISBN 9788850334759 ,OCLC 1065376849 . Adus la 10 iulie 2019 ( arhivat la 10 iulie 2019) .