| git | ||
|---|---|---|
| Generell informasjon | ||
| programtype | Versjonskontroll | |
| Forfatter | Linus Torvalds | |
| utvikler | June Hamano, Linus Torvalds | |
| Utviklingsmodell | Gratis programvare | |
| Første utgivelse | 19. oktober 2007 | |
| Tillatelse | GNU GPL v2 | |
| Teknisk informasjon | ||
| Planlagt inn | C , Bourne Shell , Perl [ 1 ] | |
| Versjoner | ||
| Siste stabile versjon | 2.35.1 ( info ) (19. januar 2022 (8 måneder og 26 dager)) | |
| lesbare filer | ||
| ||
| redigerbare filer | ||
| ||
| Lenker | ||
| Offesiell nettside Blogg kodelager | ||
Git er versjonskontrollprogramvare designet av Linus Torvalds med effektiviteten, påliteligheten og kompatibiliteten til applikasjonsversjon i tankene når applikasjoner har et stort antall kildekodefiler . Formålet er å holde styr på endringer i datafiler, inkludert å koordinere arbeidet som flere personer gjør med delte filer i et kodelager.
Git var opprinnelig ment som en motor på lavt nivå som andre kunne skrive brukergrensesnittet eller grensesnittet på, som Cogito eller StGIT . [ 2 ] Imidlertid har Git siden utviklet seg til et fullt funksjonelt versjonskontrollsystem. [ 3 ] Det er noen svært fremtredende prosjekter som allerede bruker Git, spesielt Linux - kjerneprogrammeringsgruppen .
Git- programvarevedlikehold er for tiden (2009) overvåket av Junio Hamano, som mottar kodebidrag fra rundt 280 programmerere. Angående opphavsrett Git er gratis programvare som kan distribueres under vilkårene i versjon 2 av GNU General Public License .
Gits design var basert på BitKeeper og Monotone . [ 4 ] [ 5 ] Den ble opprinnelig designet som en versjonskontrollsystemmotor på lavt nivå som andre kunne kode grensesnitt på, som Cogito eller StGIT . [ 6 ] Fra da til nå har kjernen i Git-prosjektet blitt et komplett, direkte brukbart versjonskontrollsystem. [ 7 ]
Linus Torvalds lette etter et distribuert system som han kunne bruke på en lignende måte som BitKeeper, men ingen av de tilgjengelige gratis programvaresystemene oppfylte kravene hans, spesielt når det gjelder ytelse. Gits design holder en enorm mengde kode distribuert og administrert av mange mennesker, noe som påvirker mange ytelsesdetaljer og behovet for hastighet i en første implementering.
Blant de mest relevante funksjonene er:
Dette oppretter en ny underkatalog kalt .git, som inneholder alle nødvendige depotfiler – et skjelett av et Git-depot. Ingenting i prosjektet ditt spores ennå.
Last ned endringene som er gjort i det eksterne depotet.
Grenen du står på er påvirket av endringer som er gjort i grenen "branch_name".
Den forener hente- og flettekommandoene til en enkelt kommando.
Bekreft endringene som er gjort. "Meldingen" brukes vanligvis for å knytte en kort beskrivelse av endringene som er gjort i forpliktelsen .
Skyv grenen "branch_name" til den eksterne serveren.
Viser gjeldende tilstand for grenen, for eksempel ukommitterte endringer.
Begynn å spore filen "filnavn".
Lag en gren som du står fra med navnet "new_branch_name", og hopp deretter inn på den nye grenen, slik at du står på den nye grenen.
Hvis det finnes en ekstern gren med navnet "branch_name", vil kjøring av denne kommandoen opprette en lokal gren med navnet "branch_name" for å holde styr på den eksterne grenen med samme navn.
List opp alle lokale avdelinger.
Liste over alle lokale og eksterne filialer.
Slett den lokale filialen med navnet "branch_name".
Bekreft endringer fra den lokale opprinnelsesgrenen til grenen "branch_name".
Oppdater det eksterne depotet i tilfelle en annen utvikler fjernet en ekstern gren.
Fjerner endringer som ikke er foretatt ennå .
Tilbakestiller forpliktelsen som er gjort, identifisert av "hash_commit".
Git utgjør en stor frihet i måten å jobbe rundt et prosjekt på. Men for å koordinere arbeidet til en gruppe mennesker rundt et prosjekt, er det nødvendig å bli enige om hvordan man jobber med Git. Disse avtalene kalles arbeidsflyter . [ 8 ] En Git-arbeidsflyt er en formel eller anbefaling for å bruke Git for å få arbeidet gjort på en konsistent og produktiv måte. [ 9 ] De mest populære arbeidsflytene er git-flow, GitHub-flow, GitLab Flow og One Flow. [ 10 ]
Laget i 2010 av Vincent Driessen. [ 10 ] Det er den mest kjente arbeidsflyten. Den er beregnet på de prosjektene som har veldefinerte leveranser og utviklingssykluser. [ 8 ] Den er basert på to store grener med uendelig levetid (master- og utviklingsgrener) og flere støttegrener, noen orientert mot utvikling av nye funksjoner (funksjon-* grener), andre til å fikse feil (hurtigreparasjon-* ) og andre orientert mot utarbeidelse av nye produksjonsversjoner (utgivelse-* grener). Gitflow-verktøyet [1] gjør det enkelt å automatisere oppgavene som er involvert i denne arbeidsflyten [ 10 ]
MasterDet er hovedgrenen. Den inneholder depotet som er publisert i produksjon, så det må alltid være stabilt.
UtviklingDet er en gren hentet fra Master . Det er integrasjonsgrenen, alle nye funksjoner må integreres i denne grenen. Etter at integrasjonen er utført og feilene er rettet (hvis det er noen), det vil si at grenen er stabil, kan en utviklingssammenslåing gjøres på Master -grenen .
FunksjonerHver ny funksjon må lages i en ny gren, spesifikk for den funksjonen. Disse bør tas ut av Utvikling . Når funksjonen er utviklet, blir grenen slått sammen til Development , hvor den vil bli integrert med de andre funksjonene.
HurtigreparasjonDet er programvarefeil som oppstår i produksjonen, så de må fikses og publiseres snarest. Det er derfor de er grener hentet fra Mester . Når feilen er rettet, må en forening av grenen gjøres på Master . Til slutt, slik at det ikke blir utdatert, bør foreningen av Master over Development gjøres .
SlippUtgivelsesgrener støtter utarbeidelse av nye produksjonsversjoner. Mange mindre feil er fikset for dem og metadata er riktig forberedt. De stammer vanligvis fra utviklingsgrenen og bør slås sammen til master- og utviklegrenene. [ 10 ]
Laget i 2011 av GitHub [ 10 ] og det er måten å jobbe på foreslått av GitHubs egne funksjoner. Den er sentrert om en iterativ utviklingsmodell og konstant distribusjon. Den er basert på fire prinsipper: [ 8 ] [ 10 ]
GitHub prøver å forenkle filialadministrasjonen, jobber direkte på hovedgrenen og genererer ved å integrere de forskjellige funksjonene direkte til denne grenen [ 11 ]
Laget i 2014 av Gitlab. [ 10 ] Det er en slags utvidelse av GitHub Flow ledsaget av et sett med retningslinjer og beste praksis som tar sikte på å standardisere prosessen ytterligere. I likhet med GitHub Flow, foreslår den bruk av funksjonalitetsgrener (funksjon) som stammer fra mastergrenen og som når den er ferdig blandes med mastergrenen. Den introduserer også tre andre typer grener: [ 12 ]
Laget i 2015 av Adam Ruka. I den er hver nye produksjonsversjon basert på den forrige produksjonsversjonen. Den største forskjellen mellom One Flow og Git Flow er at One Flow ikke har en utviklingsgren. [ 10 ]
Git har blitt brukt som basisprogramvare som andre prosjekter har blitt utviklet på.