Git

Git
Autor inițial	Linus Torvalds
Dezvoltator	Linus Torvalds Junio Hamano[*]​ Software Freedom Conservancy[*][[Software Freedom Conservancy (non-profit organization in the US that provides a non-profit home and infrastructure support, including legal services, for free/open source software projects)|​]]
Versiune inițială	2005
Ultima versiune	2.54.0   (20 aprilie 2026)
Repo	git.kernel.org/pub/scm/git/git.git
Scris în	C Perl Tcl/TK Python shell script[*][[shell script (limbaj de programare)|​]] Rust
Sistem de operare	GNU/Linux BSD[*]​ Mac operating system Microsoft Windows Unix-like multiplatformă
Disponibil în	limba engleză limba bulgară limba catalană limba franceză indoneziană limba suedeză limba turcă limba ucraineană limba vietnameză chineză simplificată[*]​
Licență	GPLv2
Prezență online
site web oficial

Git (/ɡɪt/) este un sistem software^⁠(d) de control distribuit al versiunilor^⁠(d) capabil să gestioneze versiunile codului sursă sau datelor în general. Este adesea utilizat pentru gestiunea codului sursă de către programatorii care dezvoltă software într-o manieră colaborativă^⁠(d).

Printre obiectivele de design ale lui Git se numără viteza, integritatea datelor^⁠(d), și suportul pentru fluxuri de lucru distribuite și neliniare^⁠(d)—cu mii de ramuri^⁠(d) rulând în paralel pe calculatoare diferite.

Ca și în cazul celor mai multe sisteme distribuite de control al versiunilor, și spre deosebire de cele mai multe sisteme client–server, Git menține o copie locală a întregului repository, denumit pe scurt „repo”, cu tot cu istoricul și cu toate capabilitățile de urmărire a versiunilor, independent de accesul la rețea sau la un server central. Pe fiecare calculator, repoul se stochează într-un director standard care conține fișiere ascunse^⁠(d) suplimentare în care se țin date legate de controlul versiunilor. Git furnizează facilități de sincronizare între repouri care au un istoric comun; pentru colaborarea asincronă, aceasta se extinde la repouri aflate pe alte mașini. Deși toate repourile (care au același istoric) au un statut egal între ele, dezvoltatorii mențin adesea un server central al cărui repo menține o copie integrată.

Git este software liber cu sursă deschisă partajat exclusiv sub licența GPL-2.0.

Git a fost creat de către Linus Torvalds pentru controlul versiunilor în procesul de dezvoltare al kernelului Linux. Marca „Git” este înregistrată de către Software Freedom Conservancy^⁠(d).

Astăzi, Git este sistemul de control al versiunilor cel mai utilizat de către dezvoltatorii de software. Este cel mai popular astfel de sistem: în 2022, aproape 95% din dezvoltatori îl declarau ca fiind sistemul principal de control al versiunilor pe care îl foloseau la acea dată. Există și oferte de servicii de întreținere a repourilor Git, între care GitHub, SourceForge, Bitbucket și GitLab^⁠(d).

Istorie

Torvalds a început să dezvolte Git în aprilie 2005 după revocarea licenței de BitKeeper^⁠(d), un sistem de control al versiunilor (SCM) pe care kernelul Linux îl folosea din 2002. Deținătorul drepturilor de autor ale lui BitKeeper, Larry McVoy^⁠(d), a susținut că Andrew Tridgell^⁠(d) ar fi creat SourcePuller^⁠(d) prin inginerie inversă pe baza protocoalelor din BitKeeper. Același incident a dus și la crearea lui Mercurial, un alt sistem de control al versiunilor.

Torvalds dore un sistem distribuit pe care îl dorea folosit la fel ca BitKeeper, dar niciunul din cele disponibile nu îi satisfăcea necesitățile. El a dar ca exemplu faptul că un sistem de gestiune a surselor are nevoie de 30 de secunde pentru a aplica un patch și a actualiza toate metadatele asociate, arătând că asemenea performanță nu scalează la nevoile comunității care dezvoltă kernelul Linux, unde sincronizarea cu alți colegi necesită uneori rularea a până la 250 de astfel de acțiuni simultan. Drept criteriu de design, el a specificat că operațiunea de patch trebuie să nu dureze mai mult de trei secunde, adăugând încă alte trei obiective:

• Se va lua Concurrent Versions System (CVS) ca exemplu de cum să nu; dacă ai îndoieli, ia decizia exact inversă decât cea luată de dezvoltatorii lui CVS.
• Suportă un flux de lucru distribuit, în stilul BitKeeper.
• Include mecanisme foarte puternice de protecție împotriva coruperii, fie malițioase, fie accidentale.

Aceste criterii eliminau toate sistemele de control al versiunilor utilizate la acea dată, așa că, imediat după lanarea versiunii de dezvoltare 2.6.12-rc2 a kernelului de Linux, Torvalds a început lucrul la propriul sistem.

Dezvoltarea lui Git a început pe 3 aprilie 2005. Torvalds a anunțat proiectul pe 6 aprilie, iar a doua zi era deja self-hosting^⁠(d). Prima operațiune de merge a mai multor branch-uri a avut loc pe 18 aprilie. După doar două săptămâni de lucru, Torvalds își îndeplinise deja obiectivele de performanță; pe 29 aprilie, la un test de performanță Git a reușit să aplice patch-uri pe arborele kernelului de Linux într-un ritm de 6,7 patch-uri pe secundă. Pe 16 iunie 2005, Git a fost trecut în producție, la gestionarea release-ului 2.6.12 al kernelului.

Pe 26 iulie 2005, Torvalds a predat activitatea de mentenanță^⁠(d) lui Junio Hamano, unul din principalii contribuitori la proiect. Hamano s-a ocupat de release-ul 1.0 care a fost lansat pe 21 decembrie 2005.

Denumirea

Despre numele git (care în engleza britanică este un termen argotic pentru o persoană neplăcută sau ridicolă) Torvalds a glumit: „eu sunt un nesuferit egoist, și îmi numesc toate proiectele dypă mine. Întâi «Linux», acum «git».” Pagina de manual^⁠(d) îl descrie pe Git „trackerul tâmpit de conținut”.

Fișierul read-me al surselor elaborează:

Codul sursă pentru Git îl denumește the information manager from hell.

Caracteristici

Design

Designul lui Git este o sinteză între experiența lui Torvalds cu Linux la întreținerea unui proiect mare, distribuit, și cunoștințele lui detaliate despre performanța sistemelor de fișiere, pe care a dobândit-o din același proiect și din nevoia stringentă de a produce un sistem funcțional într-un tip scurt. Aceste influențe au condus la următoarele decizii de implementare:

Suport puternic pentru dezvoltarea neliniară

Git oferă operațiuni rapide de branch și merge, și include unelte specifice pentru visualizarea și navigarea unui istoric neliniar. În Git, o presupunere centrală este aceea că unei modificări va ajunge să i se facă merge de mai multe ori decât este scrisă, pe măsură ce se răspândește la mai mulți revieweri. În Git, branch-urile sunt foarte mici: un branch este doar o referință la un commit.

Dezvoltare distribuită

Ca și Darcs^⁠(d), BitKeeper^⁠(d), Mercurial, Bazaar^⁠(d), și Monotone^⁠(d), Git oferă fiecărui dezvoltator o copie locală a întregului istoric de dezvoltare, iar modificările se copiază de la un astfel de repo la altul. Aceste schimbări se importă ca branch-uri suplimentare de dezvoltare, și li se poate face merge în același fel ca și unui branch dezvoltat local.

Compatibilitate cu sistemele și protocoalele existente

Repourile se pot publica prin Hypertext Transfer Protocol Secure (HTTPS), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), sau printr-un protocol Git rulat peste o coneziune socket simplă sau peste Secure Shell (ssh). Git are și un emulator de server CVS, care i-a permis utilizarea clienților existenți și a pluginurilor de IDE pentru CVS în vederea accesării repourilor de Git. Repourile de Subversion pot fi folosite direc prin git-svn.

Tratarea eficientă a proiectelor mari

Torvalds l-a descris pe Git drept foarte rapid și scalabil, iar testele de performanță efectuate de Mozilla au arătat că este cu un ordin de mărime mai rapid la compararea unor repouri mari decât Mercurial și GNU Bazaar; aducerea istoricului de versiuni dintr-un repo stocat local poate fi de o sută de ori mai rapidă decât aducerea ei de pe un server diferit.

Autentificare criptografică a istoricului

Istoricul este stocat de Git în așa fel încât ID-ul unei versiuni particulare (un commit în terminologie Git) depinde de istoricul complet de dezvoltare de până la acel commit. Odată publicată, versiunile vechi nu se mai pot schimba fără a fi observate. Structura este similară unui arbore Merkle, dar cu date adăugate la noduri și frunze. (această proprietate o au și Mercurial și Monotone^⁠(d).)

Design bazat pe toolkit

Git a fost proiectat ca un set de programe scrise în C și câteva scripturi de shell care oferă wrappere în jurul acestor programe. Deși majoritatea acestor scripturi au fost între timp rescrise în C pentru viteză și portabilitate, designul rămâne, și componentele se pot înlănțui ușor una cu celelalte.

Strategii de merge cuplabile

Ca parte a designului de toolkit, Git are un model bine definit al unui merge incomplet, și are mai mulți algoritmi care îl completează, culminând cu informarea utilizatorului că merge-ul nu poate fi efectuat automat și că este nevoie de editare manuală.

Garbage^⁠(d) se acumuleaza până când este strâns

Operațiunile abandonate și schimbările la care s-a renunțat lasă obiecte inutile prin baza de date. Ele sunt în general o mica parte din istoricul de obiecte dorite, în creștere constantă. Git efectuează garbage collection^⁠(d) automat când se atinge un prag de obiecte neconectate prin repo. Operațiunea se poate apela și explicit, cu git gc.

Împachetarea explicită și periodică a obiectelor

Git stochează fiecare obiect nou-creat într-un fișier separat. Deși sunt comprimate individual, acestea ocupă mult spațiu și sunt ineficiente. Problema este rezolvată prin utilizarea pachetelor care stochează multe obiecte delta-comprimate^⁠(d) între ele într-un singur fișier (sau flux de date prin rețea) numit packfile. Pachetele sunt comprimate folosind euristica că fișierele cu același nume sunt probabil similare; această presupunere este utilizată pentru eficiență, nu pentru corectitudine. Pentru fiecare pachet se creează un fișier index corespunzător, unde se consemnează offsetul la care începe fiecare obiect în pachet. Obiectele nou-create (cu istoric recent adăugat) sunt stocate tot ca obiecte individuale, iar reîmpachetarea se face periodic pentru a întreține eficiența utilizării spațiului de stocare. Procesul de împachetare a repoului poate fi foarte costisitor din punct de vedere computațional. Permițând obiectelor să existe în repo într-un format liber dar rapid generat, Git permite amânarea costisitoarei operațiuni de împachetare pentru un moment când durata ei contează mai puțin, cum ar fi la sfârșitul zilei de lucru. Git efectuează automat reîmpachetări, dar este posibilă și declanșarea uneia manuale, cu comanda git gc. Pentru integritatea datelor, atât pachetul cât și indexul mențin în interior o sumă de control SHA-1^⁠(d), și numele fișierului pachet conține și el o sumă de control SHA-1. Pentru a verifica integritatea unui repo, se poate rula comanda git fsck.

O altă proprietate a lui Git este că înregistrează arbori de directoare de fișiere. Primele sisteme de evidență a versiunilor codului sursă, ca Source Code Control System^⁠(d) (SCCS) și Revision Control System (RCS), lucrau cu fișiere individuale și puneau accent pe economia de spațiu care se obține prin deltauri intercalate^⁠(d) (SCCS) sau prin codificarea delta^⁠(d) (RCS) a versiunilor similare. Sistemele ulterioare au conservat această noțiune că un fișier are o anume identitate prin mai multe versiuni ale unui proiect. Torvalds a respins însă acest concept. Ca urmare, Git nu înregistrează explicit relații la nivel de versiune de fișier la niciun nivel mai jos de cel al arborelui de cod sursă.

Dezavantaje

Aceste relații implicite au câteva consecințe importante:

• Este puțin mai costisitoare examinarea istoriei modificărilor unui singur fișier față de cele pe tot proiectul. Pentru a obține un istoric al modificărilor care afectează un fișier dat, Git trebuie să parcurgă istoria globală și să determine pentru fiecare schimbare dacă a modificat sau nu acel fișier. Această metodă de examinare a istoricului îi permite însă lui Git să producă cu eficiență egală un istoric al modificărilor operate pe un set arbitrar de fișiere. De exemplu, un caz comun este un subdirector al arborelui de surse plus un fișier header global asociat.
• Redenumirile sunt tratate implicit și nu explicit. O nemulțumire comună față de CVS este aceea că folosește numele unui fișier pentru a-i identifica istoricul versiunilor, astfel că mutarea sau schimbarea numelui unui fișier nu este posibilă fără a-i întrerupe istoricul, sau fără redenumirea istoricului, ceea ce face ca istoricul să fie imprecis. Cele mai multe sisteme de control al versiunilor post-CVS rezolvă această problemă atribuind fișierului un nume unic și persistent (similar unui număr de inod^⁠(d)) care persistă dincolo de redenumire. Git nu înregistrează un astfel de identificator, declarând aceasta un avantaj. Fișierele de cod sursă sunt adesea divizate sau unite, sau doar redenumite, iar înregistrarea acesteia ca o simplă redenumire ar înscrie în istoricul imuabil o descriere inexactă a ceea ce s-a întâmplat. Git tratează problema detectând redenumirile atunci când navighează istoricul de snapshoturi ale arborelui. (Pe scurt, dat fiind un fișier din versiunea N, un fișier cu același nume din versiunea N − 1 este strămoșul lui implicit. Atunci când însă nu există un fișier cu același nume în versiunea N − 1, Git caută un fișier care a existat doar în versiunea N − 1 și este foarte similar cu cel nou.) Aceasta necesită însă sarcini mai intense pe CPU de fiecare dată când se revizuiește istoricul, și sunt disponibile câteva opțiuni de ajustarea euristicii. Acest mecanism nu funcționează mereu; uneori, un fișiere care a fost și modificate și redenumit în același commit este interpretat ca ștergerea fișierului vechi și crearea unuia nou. Dezvoltatorii pot ocoli această limitare punând redenumirea și modificarea în commituri separate.

Strategiile de merge

Git implementează mai multe strategii de merge; la momentul merge-ului se poate selecta o altă strategie decât cea implicită:

• resolve: algoritmul tradițional de three-way merge^⁠(d).
• recursiv: Aceasta este strategia implicită la pull sau la merge-ul unui singur branch, și este o variantă a algoritmului three-way.  

  Când sunt mai mulți strămoși comuni ce pot fi folosiți pentru un three-way merge, se creează un arbore unificat al strămoșilor comuni și se folosește acela drept arbore de referință la three-way merge. Aceasta a avut ca rezultat mai puține conflicte de merge fără a cauza merge-uri eșuate. S-a confirmat prin teste efectuate asupra commiturilor de merge anterioare, extrase din istoricul de dezvoltare al kernelului Linux 2.6. Aceasta poate și detecta și trata merge-uri care implică redenumiri.

  — Linus Torvalds
• octopus: Aceasta este strategia implicită atunci când se face merge la mai mult de două ramuri.

Structuri de date

Tipurile primitive de date ale lui Git nu sunt interent un sistem de gestiune a codului sursă. Torvalds explică:

În multe sensuri, putem privi git ca pe un sistem de fișiere—este adresabil prin conținut^⁠(d), și are o noțiune de versionare, dar l-am proiectat de fapt abordând problema din punctul de vedere al unui expert în „sisteme de fișiere” (că eu de kerneluri mă ocup), și nu am absolut niciun interes să creez un sistem tradițional de control al versiunilor.

Din această abordare inițială de proiectare, Git și-a dezvoltat tot setul de funcționalități așteptate de la un sistem de control al versiunilor tradițional, funcționalitățile fiind mai ales create la un nivel limitat, apoi rafinate și extinse în timp.

Unele fluxuri de date și niveluri de stocare în sistemul de control al versiunilor Git

Git are două structuri de date: un index modificabil (numit și stage sau cache) care păstrează temporar informația despre directorul de lucru^⁠(d) și următoarea versiune ce va fi commitată; și o bază de date de obiecte care stochează obiecte imuabile.

Indexul servește drept punct de legătură între baza de date de obiecte^⁠(d) și arborele de lucru.

În baza de date de obiecte se stochează cinci tipuri de obiecte:

• Un blob este conținutul unui fișier. Bloburile nu au nume de fișier, mărci temporale sau alte metadate (intern, numele unui blob este un hash al conținutului său). În Git, fiecare blob este o versiune a unui fișier, în care se află datele din fișier.
• Un obiect arbore care este echivalentul unui director. El conține o listă de nume de fișiere, fiecare cu câțiva biți de tip și o referință la obiectul blob sau arbore care este acel fișier, acea legătură simbolică, sau acel conținut de director. Aceste obiecte sunt un snapshot al arborelui de surse. (În ansamblu, aceasta compune un arbore Merkle, ceea ce înseamnă că este nevoie doar de un singur hash al arborelui rădăcină pentru a identifica cu precizie starea exactă a unor întregi structuri arborescente ce conțin oricâte subdirectoare și fișiere.)
• Un obiect commit leagă împreună obiecte arbore în istoric. El conține numele unui obiect arbore (sau al directorului rădăcină al surselor), o marcă temporală, un mesaj de jurnal, și numele a zero sau mai multe commituri părinte.
• Un obiect tag este un container ce conține referința la alt obiect și poate ține metadate adăugate despre alt obiect. Cel mai comun, el este folosit pentru a stoca o semnătură digitală a unui obiect commit corespunzător unei anume versiuni a datelor gestionate de Git.
• Un obiect packfile (pachet) colectează diferite alte obiecte într-o structură unică, comprimată cu zlib^⁠(d), pentru a o menține compactă și ușor de transportat peste protocoalele de rețea.

Fiecare obiect este identificat printr-un hash^⁠(d) SHA-1 al conținutului său. Git calculează hash-ul și utilizează valoarea lui pentru numele obiectului. Obiectul este pus într-un director care se potrivește cu primele două caractere ale hash-ului său. Restul hash-ului este folosit drept numele de fișier al acelui obiect.

Git stochează fiecare versiune a unui fișier ca un blob unic. Relația dintre bloburi poate fi găsită examinând arborele și obiectele commit. Obiectele nou adăugate sunt stocate în întregime folosind compresia zlib. Aceasta poate consuma rapid cantități mari de spațiu de stocare, așa că fișierele sunt combinate în pachete, care folosesc delta compresia^⁠(d) pentru a economisi spațiu, stocând bloburile drept modificări relative la alte bloburi.

Git stochează etichete denumite refuri (prescurtare de la referințe) pentru a indica locațiile diferitelor commituri. Ele sunt stocate în baza de date de referințe și sunt, respectiv:

• Headuri (branch-uri): Referințe cu nume care sunt schimbate automat la un nou commit atunci când se face un commit peste ele.
• HEAD: Un anume head rezervat care va fi comparat cu arborele de lucru la crearea unui commit.
• Taguri: Ca și referințele de tip branch, dar sunt fixate la un anume commit. Se folosesc pentru a eticheta momente importante din istoric.

Comenzi

Printre comenzile frecvent folosite pentru interfața prin linie de comandă a lui git se numără:

• git init, folosit pentru crearea unui repo nou.
• git clone [URL], care clonează, sau duplică, un repo gitde la un URL extern.
• git add [fișier], care adaugă un fișier la directorul de lucru (fișierele ce urmează a fi commitate) al lui Git.
• git commit -m [mesaj], care commitează fișierele din directorul actual de lucru (ca ele să devină parte din istoricul repoului).

Se poate crea un fișier .gitignore ca fișier text. Fișierele listate în .gitignore nu vor fi urmărite de Git. Această funcționalitate poate fi folosită pentru a ignora fișiere cu chei sau parole, diferite alte fișiere temporare, precum și fișierele foarte mari (pe care unele servicii de repo Git refuză să le primească la upload).

Referințe Git

Fiecare obiect din baza de date Git care nu este referit poate fi curățat automat sau prin folosirea unei comenzi de garbage collection. Un obiect poate fi referențiat de alt obiect sau de o referință explicită. Git are diferite tipuri de referințe. Comenzile pentru crearea, mutarea și ștergerea referințelor pot varia. git show-ref listează toate referințele. Unele tipuri sunt:

• head: se referă la un obiect local,
• remote: se referă la un obiect care există într-un repo diferit,
• stash: se referă la un obiect necommitat încă,
• meta: de exemplu, o configurare într-un repo simplu, drepturi de utilizator; spațiul de nume refs/meta/config a fost introdus retrospectiv,
• tag: vezi mai sus.

Implementări

gitg este un front-end grafic ce folosește GTK+.

Git (principala implementare în C) este dezvoltată în principal pe Linux, dar suportă și alte sisteme majore de operare, inclusiv familia BSD (DragonFly BSD, FreeBSD, NetBSD, și OpenBSD), Solaris, macOS, și Windows.

Prima portare^⁠(d) a lui Git pe Windows era în principal un framework de emulare de Linux pe care rula versiunea de Linux. Instalarea lui Git sub Windows creează un director cu nume similar în Program Files, conținând portarea pe Mingw-w64^⁠(d) a lui GNU Compiler Collection, Perl 5, MSYS2^⁠(d) (el însuși un fork de Cygwin^⁠(d), un mediu de emulare Unix-like pentru Windows) și diferite alte portări pe Windows sau emulări ale unor utilitare și biblioteci de Linux. Actualmente, se distribuie builduri native de Git pe Windows ca installer pe 32 sau 64 de biți. Website-ul oficial Git întreține un build de Git pentru Windows, tot cu mediul MSYS2.

Implementarea JGit este o bibliotecă software pentru Java^⁠(d), proiectată pentru a fi înglobată în orice aplicație Java. JGit este utilizată în unealta de code review Gerrit, și în EGit, un client de Git pentru IDE-ul Eclipse.

Go-git este o implementare open-source de Git scrisă în Go. Ea este folosită actualmente pentru sprijinirea unor proiecte ca interfață SQL pentru repouri de cod Git și pentru furnizarea de criptare pentru Git.

Dulwich este o implementare de Git scrisă în Python cu suport pentru CPython 3.6 și versiunile ulterioare, precum și pentru Pypy.

Implementarea libgit2 este o bibliotecă de software ANSI C fără dependențe, care poate fi compilată pe multiple platforme, inclusiv Windows, Linux, macOS, și BSD. Are bindinguri pentru multe limbaje de programare, inclusiv Ruby, Python, și Haskell.

Alte implementări de Git sunt JS-Git (o implementare în JavaScript a unui subset al lui Git), Game of Trees (o implementare open-source de Git pentru proiectul OpenBSD), git9 (o implementare independentă de Git pentru Plan 9^⁠(d) utilizând abstracții native de sistem), și gitoxide (o implementare de Git scrisă în Rust).

Git server

Captură de ecran a interfeței gitweb care prezintă un diff^⁠(d) de commit

Întrucât Git este un sistem distribuit de control al versiunilor, el poate fi folosit și direct ca server. El vine cu o comandă git daemon care pornește un server TCP simplu care rulează pe protocolul Git. Serverele HTTP dedicate lui Git ajută (printre altele) la adăugarea controlului accesului, afișarea conținutului unui repo Git prin interfețele web, și gestionarea mai multor repouri. Repourile Git deja existente pot fi clonate și partajate pentru a fi utilizate ca repo centralizat. El poate fi și accesat prin shell la distanță doar prin instalarea software-ului Git și permiterea utilizatorilor să se autentifice. Serverele Git ascultă de regulă pe portul TCP 9418.

Pentru navigarea repourilor de pe web, Git vine și cu gitweb, o interfață bazată pe CGI pentru vizualizarea conținuturilor repourilor peste HTTP.

Open source

• Rularea unui Git server folosind Git Binary.
• Gerrit, un server de Git configurabil care oferă suport pentru code review-uri și furnizează acces prin ssh, un Apache MINA^⁠(d) integrat, sau OpenSSH, sau un server web Jetty^⁠(d) integrat. Gerrit oferă integrare pentru LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, certificate X509 de client HTTPS. Cu Gerrit 3.0, toate configurațiile se stochează ca repouri Git, și nu este necesară nicio bază de date pentru a-l rula. Gerrit poate trata pull-requesturi printr-o funcționalitate implementată în core, dar nu are un GUI pentru ea.
• Phabricator^⁠(d), un spin-off din Facebook. Cum Facebook rulează în principal Mercurial, suportul pentru Git nu este foarte important.
• RhodeCode^⁠(d) Community Edition (CE) suportă Git, Mercurial și Subversion sub o licență AGPLv3 license^⁠(d).
• Kallithea^⁠(d) suportă Git și Mercurial, este dezvoltat în Python cu licență GPL.
• Proiecte externe ca gitolite, care oferă scripturi peste software-ul Git pentru control fin al accesului.
• Există mai multe soluții libere pentru găzduire, între care Gogs, Gitea^⁠(d), un fork al lui Gogs, precum și Forgejo^⁠(d), care este, la rândul lui, un fork de Gitea. Gogs și derivatele lui sunt dezvoltate în Go. Toate cele trei soluții sunt disponibile sub licența MIT^⁠(d).

Interfețe grafice

Clienții Git GUI oferă o interfață grafică pentru utilizatori pentru a simplifica interacțiunea cu repourile Git.

Aceste GUI-uri furnizează reprezentări vizuale ale istoricului proiectului, inclusiv branch-uri, commituri și modificări pe fișiere. Ele simplifică acțiuni ca indexarea unor modificări, crearea de commituri și gestiunea branch-urilor. Uneltele vizuale de diff ajută la rezolvarea conflictelor de merge ce rezultă din dezvoltări concurente.

Git vine cu un GUI în Tcl/Tk^⁠(d), care permite utilizatorilor să efectueze acțiuni ca crearea și modificarea commiturilor, crearea și merge-ul branch-urilor, și interacțiunea cu repouri de la distanță.

Pe lângă interfața grafică oficială, există multe alte interfețe create de terți, care oferă funcționalități similare celei oficiale distribuite cu Git.

Clienții GUI fac Git să fie mai ușor de învățat și folosit, îmbunătățind eficiența fluxului de lucru și reducând erorile.

Adopție

Fundația Eclipse^⁠(d) raporta în mai 2014 că Git este cea mai folosită unealtă de management al codului sursă, 42,9% din dezvoltatorii profesioniști declarând că Git este sistemul lor principal de control al surselor, o creștere față de 36,3% în 2013 și 32% în 2012; și excluzând utilizarea GitHub: 33,3% în 2014, 30,3% în 2013, 27,6% în 2012 și 12,8% în 2011. Registrul open-source Open Hub^⁠(d) raportează o creștere similară în rândul proiectelor open-source.

Stack Overflow a inclus controlul versiunilor în sondajul pe care îl organizează anual în rândul dezvoltatorilor în 2015 (16.694 de răspunsuri), 2017 (30.730 de răspunsuri), 2018 (74.298 de răspunsuri) și 2022 (71.379 de răspunsuri). Git a fost favoritul dezvoltatorilor care au răspuns în toate aceste ediții, cu cifre ca 93,9% în 2022.

Sistemele de control al versiunilor utilizate de respondenți:

Name	2015	2017	2018	2022
Git	69.3%	69.2%	87.2%	93.9%
Subversion	36.9%	9.1%	16.1%	5.2%
TFVC⁠(d)	12.2%	7.3%	10.9%
Mercurial	7.9%	1.9%	3.6%	1.1%
CVS	4.2%
Perforce⁠(d)	3.3%
VSS⁠(d)		0.6%
IBM DevOps Code ClearCase⁠(d)		0.4%
Backup de zipuri		2.0%	7.9%
Share în rețea		1.7%	7.9%
Altele	5.8%	3.0%
Niciunul	9.3%	4.8%	4.8%	4.3%

Site-ul web itjobswatch.co.uk de joburi în IT în Regatul Unit raporta în septembrie 2016 că 29,27% din anunțurile de joburi permanente în industria software britanică cereau Git, mai mult decât 12,17% pentru Microsoft Team Foundation Server^⁠(d), 10,60% Subversion, 1,30% Mercurial, și 0,48% Visual SourceSafe^⁠(d).

Extensii

Există multe extensii de Git, cum ar fi Git LFS, care a început în comunitatea GitHub și este acum foarte folosit de alte repouri. Extensiile sunt de obicei dezvoltate independent și întreținute de persoane diferite, dar o extensie foarte folosită poate fi la un moment dat adusă în interiorul lui Git.

Printre extensiile de Git open-source se numără:

• git-annex^⁠(d), un sistem distribuit de sincronizare a fișierelor bazat pe Git
• git-flow, un set de extensii Git care oferă operațiuni de nivel înalt pe repouri pentru modelul de branching al lui Vincent Driessen
• git-machete, un organizator de repouri, unealtă pentru automatizarea operațiunilor de rebase/merge/pull/push

Microsoft a dezvoltat extensia Virtual File System for Git^⁠(d) (VFS for Git; fost Git Virtual File System sau GVFS) pentru a trata dimensiunea arborelui de cod sursă al lui Windows în contextul migrării lor în 2017 la Perforce^⁠(d). VFS for Git permite care repourile clonate să folosească placeholdere în care conținutul este descărcat doar după ce se accesează un fișier.

Convenții

Git poate fi folosit într-o multitudine de moduri diferite, dar sunt adoptate unele convenții frecvente.

• Comanda de creare a unui repo local, git init, creează un branch numit master. Adesea, el este utilizat ca branch de integrare în care se aduc modificările făcute în cod. Unele unelte, ca GitHub și GitLab, au ales ca nume implicit main; Git folosește și el main începând cu release-ul 3.0, care va fi lansat la sfârșitul lui 2026. Întrucât remote-ul implicit se numește origin, branch-ul implicit din remote-ul implicit este origin/master. Utilizatorii pot adăuga sau șterge branch-uri și pot alege orice branch pentru integrare.
• Commiturile cărora li s-a făcut push într-un remote nu se mai suprascriu, ele pot fi anulate doar prin revert, un commit suplimentar care anulează schimbările făcute în cel inițial. Aceasta împiedică invalidarea unor commituri deja distribuite din cauza dispariției commitului pe care se bazează. Dacă commiturile conțin informații sensibile, ele trebuie însă înlăturate, ceea ce implică o procedură mai complexă de rescriere a istoricului.
• Se adoptă adesea workflow-ul git-flow și convențiile de denumire pentru a face distincția între istoricuri instabile dedicate unei singure funcționalități (feature/*), istoricurile instabile partajate (develop), istoricurile gata de producție (main), și patch-urile de urgență pe produse lansate (hotfix).
• Un pull request, sau merge request, este o cerere a unui utilizator de a se face merge unui branch în alt branch. Git nu oferă funcționalitate de pull request, dar aceasta este una comună pentru serviciile de cloud cu git. Funcționalitatea pe care se bazează un pull request este în esență faptul că un administrator al unui repo face pull la modificările dintr-un alt remote (repoul sursă al pull requestului). pull requestul este însă un tichet gestionat de serverul de hosting, unde se desfășoară aceste acțiuni, nu o funcționalitate a sistemului Git.

Securitate

Git nu oferă mecanisme de control al accesului, dar a fost gândit pentru a opera cu alte unelte specializate în controlul accesului.

În decembrie 2014, s-a găsit un exploit care afecta versiunile de Windows și macOS ale clientului de Git. Un atacator putea efectua execuții de cod arbitrar^⁠(d) pe un calculator țintă care are instalat Git prin crearea unui arbore Git malițios denumit .git (un director în repourile Git unde se stochează toate datele repoului) cu unele litere mari (cum ar fi .GIT sau .Git, deoarece Git nu permite ca versiunea lui .git cu litere mici să fie creată manual) conținând fișiere malițioase în subdirectorul .git/hooks (un director în care rulează fișierele executabile pe care le execută Git) pe un repo creat de atacator sau într-unul pe care atacatorul îl poate modifica. Dacă un user de Windows sau Mac face pull (descarcă) la o versiune a repoului cu directorul malițios, apoi comută la acel director, directorul .git va fi suprascris (din cauză că sistemele de fișiere Windows și Mac sunt case-insensitive) și s-ar putea rula executabilele malițioase din .git/hooks, adică comenzile scrise de atacator. Un atacator ar putea astfel modifica și fișierul de configurație .git/config, care i-ar permite să creeze aliasuri de comenzi Git malițioase sau să modifice aliasuri existente pentru a executa comenzi malițioase la rulare. Vulnerabilitatea a fost reparată în versiunea 2.2.1 de Git, lansată chiar în aceeași zi și anunțată a doua zi.

Git versiunea 2.6.1, din septembrie 2015, conține un patch pentru o vulnerabilitate de securitate (CVE-2015-7545) ce permitea execuția de cod arbitrar. Ea putea fi exploatată dacă un atacator convingea o victimă să cloneze un anume URL având comenzile arbitrare în el. Un atacator putea folosi exploitul printr-un atac man-in-the-middle^⁠(d) pe o conexiune necriptată, întrucât puteau redirecta utilizatorul la un URL ales de ei. Erau vulnerabile și clonele recursive, întrucât puteau permite controllerului unui repo să specifice URL-uri arbitrare prin fișierul gitmodules.

Git utilizează intern hash-uri SHA-1^⁠(d). Linus Torvalds a răspuns că acest hash are în principal rolul de a păzi împotriva coruperii accidentale a datelor, și că utilizarea unui hash criptografic^⁠(d) dă un spor de securitate doar ca efect secundar, principala metodă de securitate fiind semnarea. De la demonstrarea unui atac SHAttered împotriva lui Git în 2017, Git a fost modificat să folosească o versiune de SHA-1 rezistentă la acest atac. Există un plan de tranziție la alte funcții hash, întocmit din februarie 2020.

Marca înregistrată

„Git” este cuvânt-marcă înregistrată de Software Freedom Conservancy^⁠(d), înregistrat la United States Patent and Trademark Office^⁠(d) cu numărul 4680534 din 2015-02-03.