Git

Git (udtales "git" [7] ) er et distribueret versionskontrolsystem . Projektet blev skabt af Linus Torvalds for at styre udviklingen af ​​Linux-kernen , den første version blev udgivet den 7. april 2005 . Til dato er han støttet af Junio ​​​​Hamano .

Projekter, der bruger Git, inkluderer Linux-kernen , Swift , Android , Drupal , Cairo , GNU Core Utilities , Mesa , Wine , Chromium , Compiz Fusion , FlightGear , jQuery , PHP , NASM , MediaWiki , DokuWiki , Qt , en række Linux- distributioner .

Programmet er gratis og udgivet under GNU GPL version 2. Standarden er TCP-port 9418.

Historie

Udviklingen af ​​Linux-kernen blev udført på det proprietære system BitKeeper [8] , som forfatteren - Larry McVoy , selv Linux-udvikler - leverede projektet under en gratis licens. Udviklere, programmører af høj klasse, skrev adskillige hjælpeprogrammer, og for det første, Andrew Tridgell omvendt udviklede BitKeeper-dataoverførselsformatet. Som svar anklagede McVoy udviklerne for at overtræde aftalen og tilbagekaldte licensen, og Torvalds påtog sig et nyt system: ingen af ​​de åbne systemer tillod tusindvis af programmører at samarbejde i deres bestræbelser (den samme konflikt førte til skrivningen af ​​Mercurial ). Ideologien var enkel: Tag CVS -tilgangen og vend den på hovedet [9] , og tilføj samtidig pålidelighed.

Den indledende udvikling tog mindre end en uge: den 3. april 2005 begyndte udviklingen, og den 7. april blev Git-koden administreret af et ufærdigt system. Den 16. juni blev Linux migreret til Git, og den 25. juli trådte Torvalds tilbage som hovedudvikler.

Torvalds var så sarkastisk over sit valg af navnet git (som betyder "slyngel" på engelsk):

	Jeg er en egoistisk bastard, så jeg opkalder alle mine projekter efter mig selv. Først Linux, nu git.		Jeg er en egoistisk bastard, og derfor opkalder jeg alle mine projekter efter mig selv. Først Linux , nu git.
[10] [11]

Funktioner

Systemet er designet som et sæt programmer, der er specielt designet til brug i scenarier . Dette gør det nemt at skabe brugerdefinerede Git-baserede versionskontrolsystemer eller brugergrænseflader. For eksempel er Cogito netop sådan et eksempel på en wrapper omkring Git repositories, og StGit bruger Git til at administrere en samling af rettelser ( patches ).

Git understøtter hurtig versionsopdeling og fletning og inkluderer værktøjer til at visualisere og navigere i en ikke-lineær udviklingshistorie. Ligesom Darcs , BitKeeper , Mercurial , Bazaar og Monotone , giver Git hver udvikler en lokal kopi af hele udviklingshistorien, ændringer kopieres fra et lager til et andet.

Fjernadgang til Git repositories leveres af git daemon , SSH eller HTTP -serveren. Git-daemon TCP-tjenesten er en del af Git-distributionen og er sammen med SSH den mest almindelige og pålidelige adgangsmetode. HTTP-adgangsmetoden er på trods af en række begrænsninger meget populær i kontrollerede netværk, fordi den tillader brugen af ​​eksisterende netværksfilterkonfigurationer.

Implementeringsfunktioner

Git core er et sæt kommandolinjeværktøjer med muligheder. Alle indstillinger gemmes i tekstkonfigurationsfiler. Denne implementering gør Git let portabel til enhver platform og gør det nemt at integrere Git i andre systemer (især opret grafiske git-klienter med enhver ønsket grænseflade).

Et Git-lager er en mappe på filsystemet, der indeholder lagerkonfigurationsfiler, logfiler, der gemmer operationer udført på lageret, et indeks, der beskriver placeringen af ​​filerne, og et lager, der indeholder de faktiske filer. Strukturen af ​​fillageret afspejler ikke den reelle struktur af filtræet, der er gemt i depotet; det er fokuseret på at øge hastigheden for at udføre operationer med lageret. Når kernen behandler en ændringskommando (hvad enten det er ved lokale ændringer eller når den modtager en patch fra en anden node), opretter den nye filer i depotet svarende til de ændrede filers nye tilstande. Det er vigtigt, at ingen handlinger ændrer indholdet af filer, der allerede findes i boksen.

Som standard er lageret gemt i en undermappe med navnet " .git " i rodmappen i arbejdskopien af ​​filtræet, der er gemt i lageret. Ethvert filtræ i systemet kan omdannes til et git-lager ved at udstede kommandoen til at oprette et lager fra rodmappen i dette træ (eller ved at angive rodmappen i programindstillingerne). Lagret kan importeres fra en anden node, der er tilgængelig via netværket. Import af et nyt lager opretter automatisk en arbejdskopi, der svarer til den seneste commit-tilstand for det importerede lager (det vil sige, at det ikke kopierer ændringer til kildenodens arbejdskopi, som ikke har fået udstedt en commit -kommando på den node ).

Arkitektur

Det nederste niveau af git er det såkaldte indholdsadresserede filsystem . Git kommandolinjeværktøjet indeholder en række kommandoer til direkte at manipulere dette lager på et lavt niveau. Disse kommandoer er ikke nødvendige for normalt arbejde med git som et versionskontrolsystem, men er nødvendige for at implementere komplekse operationer (reparation af et beskadiget depot, og så videre), og også gøre det muligt at oprette din egen applikation baseret på git-depotet.

For hvert objekt i depotet beregnes en SHA-1- hash, og det er denne hash, der bliver navnet på filen, der indeholder dette objekt i .git/objects- mappen . For at optimere filsystemer, der ikke bruger mappetræer, bliver den første byte af hashen navnet på undermappen, og resten bliver navnet på filen i den, hvilket reducerer antallet af filer i én mappe (den begrænsende ydeevnefaktor på sådanne ældre filsystemer).

Alle referencer til lagerobjekter, inklusive referencer til et objekt i et andet objekt, er SHA-1- hash.

Derudover er der en refs -mappe i depotet , som giver dig mulighed for at indstille menneskelæselige navne for nogle Git-objekter. I Git-kommandoer er både menneskelæselige referencer fra refs og underliggende SHA-1 fuldstændigt udskiftelige.

I det klassiske normale scenarie er der tre typer objekter i et git-lager - en fil, et træ og  en commit .  En fil er en version af en brugerfil, et træ er en samling af filer fra forskellige undermapper, en "commit" er et træ og nogle yderligere oplysninger (f.eks. overordnede commits, såvel som en kommentar).

Depotet udfører nogle gange skraldopsamling, hvor forældede filer erstattes med deltaer mellem dem og de faktiske filer (det vil sige, at den aktuelle version af filen gemmes ikke-trinvist, inkrementer bruges kun til at vende tilbage til tidligere versioner), hvorefter deltadataene føjes til én stor fil, som indekset er bygget til. Dette reducerer kravene til lagerkapacitet.

Et Git-lager kan være lokalt eller eksternt. Det lokale lager er en undermappe af .git , oprettet (tom) af git init og (ikke-tom, kopierer straks indholdet af det overordnede fjernlager og linker til det overordnede) af git clone .

Næsten alle normale versionskontroloperationer, såsom commits og merges, udføres kun på det lokale lager. Et fjernlager kan kun synkroniseres med et lokalt både op ( tryk ) og ned ( træk ).

At have hele projektlageret lokalt for hver udvikler giver Git en række fordele i forhold til SVN . Så for eksempel kan alle operationer, undtagen push and pull , udføres uden internetforbindelse.

En meget kraftfuld funktion ved git er branches, som er meget mere fuldt implementeret end i SVN: faktisk er en git-gren ikke andet end et navngivet link, der peger på en commit i depotet (ved hjælp af en refs -undermappe ). En commit uden at oprette en ny gren flytter bare dette link til sig selv, og en commit med at oprette en gren efterlader det gamle link på plads, men opretter et nyt på det nye commit og erklærer det aktuelt. At erstatte lokale udviklingsfiler med et sæt filer fra en anden gren, og derved skifte til at arbejde med det, er lige så trivielt.

Underlagre understøttes også med synkronisering af aktuelle filialer i dem.

Push - kommandoen overfører alle nye data (dem der endnu ikke er i fjernlageret) fra det lokale lager til fjernlageret. For at udføre denne kommando er det nødvendigt, at fjernlageret ikke har nye commits til sig selv fra andre klienter, ellers mislykkes pushet , og du skal foretage et pull og flette.

Træk- kommandoen  er det modsatte af push- kommandoen . Hvis den samme filial har en uafhængig historie i den lokale og eksterne kopi, fortsætter pull straks for at flette.

Sammenfletning inden for forskellige filer udføres automatisk (al denne adfærd kan konfigureres) og inden for en enkelt fil - ved en standard filsammenligning med tre ruder. Efter fusionen skal du erklære konflikter som løst.

Resultatet af alt dette er en ny tilstand i de lokale filer for udvikleren, der foretog fusionen. Han skal straks foretage en commit, mens der i dette commit-objekt i repository vil være information om, at commit er resultatet af en sammensmeltning af to brancher og har to overordnede commits.

Udover at fusionere , understøtter Git også rebase-operationen .  Denne operation får et sæt af alle ændringer i gren A, med deres efterfølgende "rulning frem" til gren B. Som et resultat bliver gren B forfremmet til tilstand AB. I modsætning til en fusion vil der ikke være nogen mellemliggende forpligtelser for gren A i gren AB's historie (kun historien om gren B og en registrering af selve rebasen, dette forenkler integrationen af ​​store og meget store projekter).

Git har også et midlertidigt lokalt filindeks. Dette er en mellemlagring mellem de faktiske filer og den næste commit (en commit laves kun fra dette indeks). Ved hjælp af dette indeks tilføjes nye filer ( git add tilføjer dem til indekset, de vil falde ind i den næste commit), ligesom ikke alle ændrede filer er committede (kun de filer, der blev lavet af git add er committede ). Efter git add , kan du redigere filen yderligere, du vil få tre kopier af den samme fil - den sidste, i indekset (den der var på tidspunktet for git add ), og i den sidste commit.

Standard filialnavn: master . Navnet på standard fjernlageret oprettet af git clone under en typisk "træk et eksisterende projekt fra serveren til din maskine" operation: origin .

Det lokale arkiv har således altid en mastergren , som er den seneste lokale commit, og en oprindelse/mastergren , som er den seneste tilstand af fjernlageret på det tidspunkt, hvor sidste pull eller push fuldførte .

Hent - kommandoen (partial pull ) - henter alle ændringer i oprindelse/master fra fjernserveren og omskriver dem til det lokale lager, hvilket fremmer oprindelse/master -tagget .

Hvis master og oprindelse/master efter det er divergeret, så skal du flette ved at indstille master til resultatet af fletningen ( trækkommandoen er hent+flet ). Yderligere er det muligt at pushe ved at sende resultatet af fletningen til serveren og indstille oprindelse/master til den .

Implementeringsdetaljer på Windows

Windows-versionen (den officielle Windows-version kaldes mSysGit) bruger mSys- pakken  , en port på en POSIX -kompatibel Windows-kommandolinje fra MinGW -projektet . Alle biblioteker og værktøjer, der er nødvendige for Git, såvel som Git selv, er blevet flyttet under mSys. Når du arbejder med fjernlagre over SSL , bruges certifikatlageret fra mSys, ikke fra Windows.

Der er mange GUI'er til Git til Windows, såsom TortoiseGit . Alle implementeres gennem opkald til mSysGit og kræver, at det er installeret på maskinen. SourceTree, Atlassians løsning , er ingen undtagelse, men den indeholder mSysGit, som har sine fordele og ulemper (da installation i en dyb undermappe gør det vanskeligt at tilføje de nødvendige SSL-certifikater til mSys).

Fordi Windows bruger en anden end-of-line-karakter end de fleste Unix-lignende systemer , er der muligheder (både på klient- og lagerniveau) for teams på tværs af operativsystemer for at give en ensartet end-of-line repræsentation.

Netværks- og serverløsninger

Git bruger kun netværket til at dele operationer med fjernlager.

Følgende protokoller kan bruges:

• git-protokol (URI-skema - git: ) er en åben protokol [12] der kræver en kørende git-dæmon [13] på serveren (leveret med Git), protokollen har ikke brugergodkendelsesværktøjer;
• SSH ( ssh: ) - bruger brugergodkendelse ved hjælp af nøglepar, samt "hoved" SSH-serveren (sshd) indbygget i Unix-systemet, oprettelsen af ​​konti med git som shell er påkrævet fra serversiden;
• HTTP og HTTPS ( http: , https: ) - bruger curl - værktøjet (til Windows - leveres med git) og dets HTTP-godkendelsesfunktioner, samt dets understøttelse af SSL og certifikater.

I sidstnævnte tilfælde skal du arbejde på serversiden af ​​en webapplikation, der fungerer som et lag mellem Git-kommandoerne på serveren og HTTP-serveren (blandt dem er WebGitNet, udviklet på ASP.NET MVC 4). Ud over at understøtte push- og pull-kommandoer på serversiden, kan sådanne webapplikationer også give skrivebeskyttet adgang til lageret via en webbrowser.

Grafiske grænseflader

Mange grafiske grænseflader er blevet udviklet til systemet, blandt dem - GitKraken (en cross-platform shareware Git-klient), SmartGit (en cross-platform-grænseflade i Java), gitk (et enkelt og hurtigt program skrevet i Tcl / Tk distribueret med Git sig selv), Giggle (en variant i Gtk+ ), TortoiseGit (en grænseflade implementeret som en Windows Explorer -udvidelse ), SourceTree (en gratis Git-klient til Windows og Mac), en Github- klient og en række andre.

Derudover er der udviklet mange web-frontends, herunder GitWebAdmin, GitLab , Gitblit, Gerrit , Gitweb, Kallithea, Gitea .

Git hosting

En række tjenester leverer hosting til git-repositories, blandt de mest berømte er GitHub , Codebase , SourceForge , SourceHut , Gitea , Bitbucket , GitLab .

Interaktion med andre versionskontrolsystemer

Standarddistributionen af ​​Git understøtter interaktion med CVS (import og eksport, CVS server emulering) og Subversion (delvis understøttelse af import og eksport). Standard import- og eksportværktøj i økosystemet er arkiver af en række versionerede filer i .tar.gz- og .tar.bz2-formater.

Noter

1. ↑ https://github.com/git/git/graphs/contributors
2. ↑ Re: Trivia: Hvornår var git selvvært?
3. ↑ [ ANNONCER Git v2.38.1 og andre] - 2022.
4. ↑ Git Open Source-projektet på Open Hub: Languages-side - 2006.
5. ↑ 1 2 3 4 5 6 Git-pakkeformat
6. ↑ Kopiering  _
7. ↑ git . Hentet 19. juni 2009. Arkiveret fra originalen 14. april 2010. (ubestemt)
8. ↑ BitKeeper og Linux: End of the road? (utilgængeligt link) . Hentet 7. november 2017. Arkiveret fra originalen 8. juni 2017. (ubestemt) 
9. ↑ Torvalds tale . Hentet 28. september 2017. Arkiveret fra originalen 28. maj 2007. (ubestemt)
10. ↑ GitFaq: Hvorfor 'Git'-navnet . Hentet 7. november 2017. Arkiveret fra originalen 23. juli 2012. (ubestemt)
11. ↑ Efter kontroverser begynder Torvalds arbejdet med 'git' . PC verden. Hentet 7. november 2017. Arkiveret fra originalen 1. februar 2011. (ubestemt) Originaltekst  (engelsk)[ Visskjule] Da han blev spurgt, hvorfor han kaldte den nye software "git", sagde han, at engelsk slang betyder "en rådden person". "Jeg er en egoistisk bastard, så jeg opkalder alle mine projekter efter mig selv. Først Linux, nu git."
12. ↑ Git - Transfer Protocols . Dato for adgang: 28. oktober 2013. Arkiveret fra originalen 29. oktober 2013. (ubestemt)
13. ↑ Git på serveren - Git daemon . Hentet 9. maj 2022. Arkiveret fra originalen 20. april 2017. (ubestemt)

Links