Git () este un de 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ă .
Printre obiectivele de design ale lui Git se numără viteza, , și suportul pentru fluxuri de lucru distribuite și —cu mii de 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 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 .
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 .
Istorie Torvalds a început să dezvolte Git în aprilie 2005 după revocarea licenței de , un sistem de control al versiunilor (SCM) pe care kernelul Linux îl folosea din 2002. Deținătorul drepturilor de autor ale lui BitKeeper, , a susținut că ar fi creat 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 . Torvalds a anunțat proiectul pe , iar a doua zi era deja . Prima operațiune de a mai multor branch-uri a avut loc pe . După doar două săptămâni de lucru, Torvalds își îndeplinise deja obiectivele de performanță; pe , 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 , Git a fost trecut în producție, la gestionarea release-ului 2.6.12 al kernelului.
Pe , Torvalds a predat activitatea de lui Junio Hamano, unul din principalii contribuitori la proiect. Hamano s-a ocupat de release-ul 1.0 care a fost lansat pe .
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 îl descrie pe Git „trackerul tâmpit de conținut”.
Fișierul read-me al surselor elaborează:
Codul sursă pentru Git îl denumește .
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 , , Mercurial, , și , 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 MozillaJst's Blog on Mozillazine 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 î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 .) 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ă. se acumulează 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ă 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 între ele într-un singur fișier (sau flux de date prin rețea) numit . 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 , ș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 (SCCS) și Revision Control System (RCS), lucrau cu fișiere individuale și puneau accent pe economia de spațiu care se obține prin (SCCS) sau prin (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.