Git

Git (pronunțat „git” [7] ) este un sistem de control al versiunilor distribuit . Proiectul a fost creat de Linus Torvalds pentru a gestiona dezvoltarea nucleului Linux , prima versiune a fost lansată pe 7 aprilie 2005 . Până în prezent, el este susținut de Junio ​​Hamano .

Proiectele care utilizează Git includ nucleul Linux , Swift , Android , Drupal , Cairo , GNU Core Utilities , Mesa , Wine , Chromium , Compiz Fusion , FlightGear , jQuery , PHP , NASM , MediaWiki , DokuWiki , Qt , o serie de distribuții Linux .

Programul este gratuit și este lansat sub versiunea 2 GNU GPL . Implicit este portul TCP 9418.

Istorie

Dezvoltarea nucleului Linux a fost realizată pe sistemul proprietar BitKeeper [8] , pe care autorul - Larry McVoy , el însuși un dezvoltator Linux - a furnizat proiectul sub o licență gratuită. Dezvoltatorii, programatori de înaltă clasă, au scris mai multe utilitare și, pentru unul, Andrew Tridgell a proiectat formatul de transfer de date BitKeeper. Ca răspuns, McVoy i-a acuzat pe dezvoltatori că au încălcat acordul și a revocat licența, iar Torvalds a preluat un nou sistem: niciunul dintre sistemele deschise nu a permis miilor de programatori să coopereze în eforturile lor (același conflict a dus la scrierea lui Mercurial ). Ideologia era simplă: luați abordarea CVS și întoarceți-o pe cap [9] , și, în același timp, adăugați fiabilitate.

Dezvoltarea inițială a durat mai puțin de o săptămână: pe 3 aprilie 2005, a început dezvoltarea, iar până pe 7 aprilie, codul Git era gestionat de un sistem neterminat. Pe 16 iunie, Linux a fost migrat la Git, iar pe 25 iulie, Torvalds a demisionat din funcția de dezvoltator principal.

Torvalds a fost atât de sarcastic în ceea ce privește alegerea numelui git (care înseamnă „sticlă” în engleză):

	Sunt un ticălos egoist, așa că îmi numesc toate proiectele după mine. Mai întâi Linux, acum git.		Sunt un ticălos egoist și de aceea îmi numesc toate proiectele după mine. Mai întâi Linux , acum git.
[10] [11]

Caracteristici

Sistemul este conceput ca un set de programe special concepute pentru a fi utilizate în scenarii . Acest lucru facilitează crearea unor sisteme personalizate de control al versiunilor sau interfețe de utilizator bazate pe Git. De exemplu, Cogito este doar un astfel de exemplu de wrapper în jurul depozitelor Git, iar StGit folosește Git pentru a gestiona o colecție de corecții ( patch-uri ).

Git acceptă împărțirea și îmbinarea rapidă a versiunilor și include instrumente pentru vizualizarea și navigarea unui istoric de dezvoltare neliniar. La fel ca Darcs , BitKeeper , Mercurial , Bazaar și Monotone , Git oferă fiecărui dezvoltator o copie locală a întregului istoric de dezvoltare, modificările sunt copiate dintr-un depozit în altul.

Accesul de la distanță la depozitele Git este oferit de demonul git , serverul SSH sau HTTP . Serviciul TCP git-daemon face parte din distribuția Git și, împreună cu SSH, este cea mai comună și mai fiabilă metodă de acces. Metoda de acces HTTP, în ciuda unui număr de limitări, este foarte populară în rețelele controlate, deoarece permite utilizarea configurațiilor existente ale filtrului de rețea.

Caracteristici de implementare

Git core este un set de utilitare de linie de comandă cu opțiuni. Toate setările sunt stocate în fișiere de configurare text. Această implementare face Git ușor de portat pe orice platformă și facilitează integrarea Git în alte sisteme (în special, creați clienți grafici git cu orice interfață dorită).

Un depozit Git este un director din sistemul de fișiere care conține fișiere de configurare a depozitului, fișiere jurnal care stochează operațiunile efectuate în depozit, un index care descrie locația fișierelor și un depozit care conține fișierele reale. Structura stocării fișierelor nu reflectă structura reală a arborelui de fișiere stocat în depozit, ci se concentrează pe creșterea vitezei de efectuare a operațiunilor cu depozitul. Când nucleul procesează o comandă de modificare (fie că este vorba despre modificări locale sau când primește un patch de la un alt nod), acesta creează noi fișiere în depozit corespunzătoare noilor stări ale fișierelor modificate. Este important ca nicio operațiune să modifice conținutul fișierelor care există deja în seif.

În mod implicit, depozitul este stocat într-un subdirector numit „ .git ” în directorul rădăcină al copiei de lucru a arborelui de fișiere stocat în depozit. Orice arbore de fișiere din sistem poate fi transformat într-un depozit git prin lansarea comenzii de a crea un depozit din directorul rădăcină al acestui arbore (sau prin specificarea directorului rădăcină în opțiunile programului). Depozitul poate fi importat dintr-un alt nod accesibil prin rețea. Importul unui nou depozit creează automat o copie de lucru corespunzătoare celei mai recente stări de comitere a depozitului importat (adică nu copiază modificările aduse copiei de lucru a nodului sursă care nu au primit o comandă de commit pe acel nod ).

Arhitectură

Nivelul inferior al git este așa-numitul sistem de fișiere adresat conținutului . Instrumentul de linie de comandă git conține o serie de comenzi pentru a manipula direct acest depozit la un nivel scăzut. Aceste comenzi nu sunt necesare pentru lucrul normal cu git ca sistem de control al versiunilor, dar sunt necesare pentru a implementa operațiuni complexe (repararea unui depozit deteriorat și așa mai departe) și, de asemenea, face posibilă crearea propriei aplicații bazate pe depozitul git.

Pentru fiecare obiect din depozit, se calculează un hash SHA-1 , iar acest hash devine numele fișierului care conține acest obiect în directorul .git/objects . Pentru a optimiza sistemele de fișiere care nu folosesc arbori de directoare, primul octet al hash-ului devine numele subdirectorului, iar restul devine numele fișierului din acesta, ceea ce reduce numărul de fișiere dintr-un director (factorul limitator de performanță pe astfel de sisteme de fișiere moștenite).

Toate referințele la obiecte din depozit, inclusiv referințele la un obiect din alt obiect, sunt hash-uri SHA-1 .

În plus, există un director refs în depozit , care vă permite să setați nume care pot fi citite de om pentru unele obiecte Git. În comenzile Git, atât referințele care pot fi citite de om de la referințe, cât și SHA -1 subiacent sunt complet interschimbabile.

În scenariul normal clasic, există trei tipuri de obiecte într-un depozit git - un fișier, un arbore și  un commit .  Un fișier este o versiune a unui fișier utilizator, un arbore este o colecție de fișiere din diferite subdirectoare, un „commit” este un arbore și câteva informații suplimentare (de exemplu, comiterea părintelui, precum și un comentariu).

Depozitul efectuează uneori colectarea gunoiului, timp în care fișierele învechite sunt înlocuite cu delte între ele și fișierele reale (adică versiunea curentă a fișierului este stocată non-incremental, incrementele sunt folosite doar pentru a reveni la versiunile anterioare), după care datele delta sunt adăugate la un fișier mare în care este construit indexul. Acest lucru reduce cerințele privind capacitatea de stocare.

Un depozit Git poate fi local sau la distanță. Depozitul local este un subdirector al .git , creat (gol) de git init și (nevid, copierea imediată a conținutului depozitului de la distanță părinte și conectarea la părinte) de git clone .

Aproape toate operațiunile obișnuite de control al versiunilor, cum ar fi comitările și îmbinările, sunt efectuate numai în depozitul local. Un depozit de la distanță poate fi sincronizat doar cu unul local atât în ​​sus ( împingere ) cât și în jos ( trage ).

Având întregul depozit de proiect la nivel local pentru fiecare dezvoltator, oferă Git o serie de avantaje față de SVN . Deci, de exemplu, toate operațiunile, cu excepția push și pull , pot fi efectuate fără o conexiune la internet.

O caracteristică foarte puternică a git sunt ramurile, care sunt mult mai complet implementate decât în ​​SVN: de fapt, o ramură git nu este altceva decât o legătură numită care indică un commit în depozit (folosind un subdirector refs ). O comitere fără a crea o nouă ramură doar mută această legătură către sine, iar o comitere cu crearea unei ramuri lasă vechea legătură pe loc, dar creează una nouă pe noua comitere și o declară actuală. Înlocuirea fișierelor de dezvoltare locală cu un set de fișiere dintr-o altă ramură, trecând astfel la lucrul cu aceasta, este la fel de banală.

Sub-depozitele sunt, de asemenea, acceptate cu sincronizarea ramurilor curente din ele.

Comanda push transferă toate datele noi (cele care nu se află încă în depozitul de la distanță) din depozitul local în depozitul de la distanță. Pentru a executa această comandă, este necesar ca depozitul de la distanță să nu aibă noi comiteri către sine de la alți clienți, altfel push- ul nu reușește și trebuie să faceți un pull and merge.

Comanda de tragere  este opusul comenzii de împingere . În cazul în care aceeași ramură are un istoric independent în copia locală și la distanță, pull trece imediat la fuzionare.

Îmbinarea în diferite fișiere se realizează automat (tot acest comportament este configurabil) și într-un singur fișier - printr-o comparație standard de fișiere cu trei panouri. După îmbinare, trebuie să declarați conflictele ca fiind rezolvate.

Rezultatul tuturor acestor lucruri este o nouă stare în fișierele locale ale dezvoltatorului care a făcut fuziunea. El trebuie să facă imediat un commit, în timp ce în acest obiect commit din depozit vor exista informații că commit-ul este rezultatul unei îmbinări a două ramuri și are două commit-uri părinte.

Pe lângă fuziune , Git acceptă și operația de rebase .  Această operațiune primește un set de toate modificările în ramura A, cu „rularea” ulterioară a acestora către ramura B. Ca urmare, ramura B este promovată în starea AB. Spre deosebire de o fuziune, nu vor exista comiteri intermediare ale ramului A în istoria ramului AB (doar istoria ramului B și o înregistrare a rebazei în sine, acest lucru simplifică integrarea proiectelor mari și foarte mari).

Git are, de asemenea, un index de fișier local temporar. Aceasta este o stocare intermediară între fișierele reale și următoarea comitere (o comitere se face numai din acest index). Cu ajutorul acestui index, se adaugă fișiere noi ( git add le adaugă la index, vor cădea în următorul commit), precum și nu toate fișierele modificate sunt comite (se comite doar acele fișiere care au fost făcute de git add ). După git add , puteți edita fișierul în continuare, veți obține trei copii ale aceluiași fișier - ultima, în index (cel care era la momentul git add ) și în ultimul commit.

Nume implicit de ramură: master . Numele depozitului de la distanță implicit creat de git clone în timpul unei operațiuni tipice „trageți un proiect existent de pe server pe mașina dvs.”: origin .

Astfel, depozitul local are întotdeauna o ramură principală , care este cea mai recentă comitere locală, și o ramură origin/master , care este cea mai recentă stare a depozitului de la distanță la momentul finalizării ultimului pull sau push .

Comanda fetch ( extragere parțială ) - preia toate modificările de origine/master de la serverul la distanță și le rescrie în depozitul local, promovând eticheta origin/master .

Dacă după ce master și origine/master s-au separat, atunci trebuie să fuzionați setând master la rezultatul îmbinării ( comanda pull este fetch+merge ). În plus, este posibil să împingeți trimițând rezultatul îmbinării către server și setând origin/master la acesta .

Detalii de implementare pe Windows

Versiunea Windows (versiunea oficială Windows se numește mSysGit) utilizează pachetul mSys  , un port al unei linii de comandă Windows compatibile cu POSIX din proiectul MinGW . Toate bibliotecile și instrumentele necesare pentru Git, precum și Git în sine, au fost mutate în mSys. Când lucrați cu depozite de la distanță prin SSL , se utilizează depozitul de certificate de la mSys, nu de la Windows.

Există multe GUI-uri pentru Git pentru Windows, cum ar fi TortoiseGit . Toate sunt implementate prin apeluri la mSysGit și necesită instalarea acestuia pe mașină. SourceTree, soluția lui Atlassian , nu face excepție, dar conține mSysGit, care are avantajele și dezavantajele sale (deoarece instalarea într-un subdirector profund face dificilă adăugarea certificatelor SSL necesare la mSys).

Deoarece Windows folosește un caracter de final de linie diferit de majoritatea sistemelor asemănătoare Unix , există opțiuni (atât la nivel de client, cât și la nivel de depozit) pentru echipele din sistemele de operare pentru a oferi o reprezentare uniformă de final de linie.

Soluții de rețea și server

Git folosește rețeaua doar pentru partajarea operațiunilor cu depozitele de la distanță.

Se pot utiliza următoarele protocoale:

• protocolul git (schema URI - git: ) este un protocol deschis [12] care necesită un daemon git [13] care rulează pe server (furnizat cu Git), protocolul nu are instrumente de autentificare a utilizatorului;
• SSH ( ssh: ) - folosește autentificarea utilizatorului folosind perechi de chei, precum și serverul SSH „principal” (sshd) încorporat în sistemul Unix, crearea de conturi cu git ca shell este necesară din partea serverului;
• HTTP și HTTPS ( http: , https: ) - utilizează instrumentul curl (pentru Windows - vine cu git) și capabilitățile sale de autentificare HTTP, precum și suportul pentru SSL și certificate.

În acest din urmă caz, trebuie să lucrați pe partea de server a unei aplicații web care acționează ca un strat între comenzile Git de pe server și serverul HTTP (printre acestea se numără și WebGitNet, dezvoltat pe ASP.NET MVC 4). În plus față de suportul comenzilor push și pull pe partea de server, astfel de aplicații web pot oferi și acces numai în citire la depozit printr-un browser web.

Interfețe grafice

Pentru sistem au fost dezvoltate multe interfețe grafice, printre care - GitKraken (un client Git shareware multiplatform), SmartGit (o interfață multiplatformă în Java), gitk (un program simplu și rapid scris în Tcl / Tk distribuit cu Git în sine), Giggle (o variantă în Gtk+ ), TortoiseGit (o interfață implementată ca extensie Windows Explorer ), SourceTree (un client Git gratuit pentru Windows și Mac), un client Github și o serie de altele.

În plus, au fost dezvoltate multe frontend-uri web, inclusiv GitWebAdmin, GitLab , Gitblit, Gerrit , Gitweb, Kallithea, Gitea .

Gazduire Git

O serie de servicii oferă găzduire pentru depozitele git, printre cele mai cunoscute sunt GitHub , Codebase , SourceForge , SourceHut , Gitea , Bitbucket , GitLab .

Interacțiunea cu alte sisteme de control al versiunilor

Distribuția standard a Git acceptă interacțiunea cu CVS (import și export, emulare server CVS) și Subversion (suport parțial pentru import și export). Instrumentul standard de import și export în cadrul ecosistemului este arhivele unei serii de fișiere versionate în formatele .tar.gz și .tar.bz2.

Note

1. ↑ https://github.com/git/git/graphs/contributors
2. ↑ Re: Trivia: Când git self-host?
3. ↑ [ANUNȚĂ Git v2.38.1 și altele] - 2022.
4. ↑ Proiectul git Open Source pe Open Hub: Pagina de limbi - 2006.
5. ↑ 1 2 3 4 5 6 Format pachet Git
6. ↑ Copierea  _
7. ↑ git . Consultat la 19 iunie 2009. Arhivat din original la 14 aprilie 2010. (nedefinit)
8. ↑ BitKeeper și Linux: Sfârșitul drumului? (link indisponibil) . Consultat la 7 noiembrie 2017. Arhivat din original la 8 iunie 2017. (nedefinit) 
9. ↑ Discursul lui Torvald . Consultat la 28 septembrie 2017. Arhivat din original pe 28 mai 2007. (nedefinit)
10. ↑ GitFaq: De ce numele „Git” . Consultat la 7 noiembrie 2017. Arhivat din original la 23 iulie 2012. (nedefinit)
11. ↑ După controverse, Torvalds începe să lucreze la „git” . Lumea PC-urilor. Consultat la 7 noiembrie 2017. Arhivat din original la 1 februarie 2011. (nedefinit) Text original  (engleză)[ arataascunde] Când a fost întrebat de ce a numit noul software, „git”, argou britanic care înseamnă „o persoană putredă”, a spus el. "Sunt un nenorocit egoist, așa că numesc toate proiectele mele după mine. Mai întâi Linux, acum git."
12. ↑ Git - Transfer Protocols . Data accesului: 28 octombrie 2013. Arhivat din original pe 29 octombrie 2013. (nedefinit)
13. ↑ Git pe server - Git daemon . Preluat la 9 mai 2022. Arhivat din original la 20 aprilie 2017. (nedefinit)

Link -uri