Utforske versjonskontroll ved hjelp av Git

  • 5 minutter

Det finnes ulike typer versjonskontrollsystemer (VCS), men generelt kan de kategoriseres som sentraliserte og distribuerte. I de senere årene (delvis på grunn av den økende populariteten til DevOps), den sistnevnte kategorien fikk betydelig popularitet, med Git bli de facto standard i moderne programvareutvikling. Denne bestemte VCS ville være det mest passende valget for organisasjonen i vårt eksempelscenario, spesielt med tanke på intensjonen om å bruke GitHub som målplattform for DevOps-overgangen. I denne enheten kan du utforske bruken av Git som versjonskontroll.

Skjermbilde av en tabell som sammenligner sentraliserte og distribuerte versjonskontrollsystemer.

Sentralisert kontra distribuert versjonskontroll

Både sentraliserte versjonskontrollsystemer (CVCS) og distribuerte versjonskontrollsystemer (DVCS) tilbyr muligheten til å administrere og spore endringer i programvareutviklingsprosjekter. De primære forskjellene mellom dem er relatert til måten de implementerer repositorier og samarbeid på. Spesielt:

  • repositoriumplassering: I sentraliserte systemer finnes det én enkelt sentralisert forekomst av repositoriet som inneholder hele loggen for prosjektet. I distribuerte systemer vil hvert teammedlem vanligvis ha én, fullt funksjonell lokal kopi av hele repositoriet, potensielt inkludert den fullstendige versjonsloggen.
  • Nettverkstilkobling: I sentraliserte systemer kreves tilgang til den sentraliserte forekomsten av repositoriet for å utføre mange handlinger, inkludert oppdateringer og henting av logg. I distribuerte systemer kan alle aktiviteter utføres mot den lokale kopien av repositoriet.
  • samarbeidsmodell: I sentraliserte systemer sjekker utviklere ut filer fra den sentraliserte forekomsten av repositoriet mens de er koblet til det via et nettverk før de foretar endringer og utfører endringene. Dette hindrer at andre sjekker ut filer. I distribuerte systemer gjør og utfører utviklere endringer i den lokale kopien av repositoriet, som på et tidspunkt senere synkroniseres med andre kopier.
  • forgrenings- og sammenslåingsmodell: I sentraliserte systemer krever forgrening og sammenslåing vanligvis koordinering med andre. I distribuerte systemer kan grener opprettes uavhengig i lokale kopier og slås sammen etterpå.

Det er verdt å merke seg at selv om den distribuerte modellen ikke er avhengig av å ha et sentralt repositorium (i tradisjonell forstand), er det vanlig å implementere en kopi av repositoriet, som driftes av tjenester som GitHub, GitLab eller Bitbucket. Denne forekomsten fungerer som fokuspunkt for samarbeid og synkronisering.

Skjermbilde av sentraliserte og distribuerte versjonskontrollsystemer repositorier og samarbeid.

Git terminologi

For å bli dyktig i å jobbe med Git, er det viktig å bli kjent med terminologien. Noen av konseptene er unike for Git, noe som skiller det fra andre DVCS. De mest grunnleggende Git-termene inkluderer:

  • working tree: en katalogstruktur som inneholder alle filene i prosjektet.
  • repositorium (ofte kalt repositorium): katalogen som er plassert på øverste nivå i et fungerende tre, som er vert for alle prosjektets filer sammen med versjonsloggen for disse filene.
  • Klon: handlingen med å opprette en kopi av et eksternt repositorium på en lokal maskin for å arbeide med et prosjekt som du har tilgang til.
  • Fork: handlingen med å opprette en GitHub-vertsbasert kopi av et eksternt repositorium for å arbeide på et prosjekt som du ikke har tilgang til. En forgrening brukes vanligvis hvis du har tenkt å bidra til andres prosjekt eller opprette din egen versjon av et slikt prosjekt. Selv om du ikke har skrivetilgang til det opprinnelige repositoriet, kan du administrere forgreningen fullstendig.
  • Utfør: et øyeblikksbilde av endringene som er gjort i filene i et repositorium på et bestemt tidspunkt. Utføringer brukes til å registrere og lagre endringer.
  • oppsamlingsområde en mellomliggende plassering (som ikke er en del av repositoriet) der endringer i filer i arbeidstreet klargjøres før de utføres. Det gjør det mulig for utviklere å velge endringer de har tenkt å utføre.
  • Branch: en navngitt serie med koblede utføringer. Enkelt sagt representerer en gren en distinkt versjon av et prosjekt. Dette gjør det mulig å arbeide på ulike deler av et prosjekt samtidig uten å påvirke hovedversjonen. Den siste utførelsen i en gren kalles leder. Standardgrenen som genereres automatisk når du initialiserer et repositorium, kalles hoved eller hoved.
  • Slå sammen: prosessen med å kombinere endringer fra én gren (eller utføring) til en annen. Dette integrerer endringer fra én gren til en annen.
  • Object: én av fire typer enheter som er tilgjengelige i et repositorium. Disse enhetene inkluderer blober som representerer individuelle filer, et tre som representerer et fungerende tre, en utføring som representerer en bestemt versjon av arbeidstreet, og en *tag, som er en etikett som er tilordnet en individuell utførelse.
  • Hash-: en automatisk generert, unik identifikator med fast lengde som representerer innholdet i et objekt. Når objektet endres, endres også hash-koden. Dette gjør det mulig for Git å finne ut hvilket innhold i et repositorium som er oppdatert.
  • Ekstern: en referanse til et annet repositorium (annet enn det lokale), som vanligvis peker til den tjenestebaserte forekomsten av repositoriet. Dette fungerer som standard for push- og pull-operasjoner.
  • Dra: handlingen som henter endringer fra et eksternt repositorium og slår dem sammen til gjeldende gren.
  • Push: handlingen som sender lokale forplikter seg til et eksternt repositorium, og oppdaterer det med endringene som er gjort lokalt.
  • Hent: handlingen som henter endringer fra et eksternt repositorium uten automatisk å slå dem sammen. Dette gjør det mulig for deres gjennomgang før du bruker en fletting.
  • Pull-forespørsel: en funksjon i Git-baserte vertsplattformer (for eksempel GitHub) som gjør det mulig for utviklere å foreslå endringer og be om at de slås sammen til en målgren.

Git har også et omfattende sett med kommandoer, som gir muligheten til å implementere og administrere versjonskontroll fullt ut gjennom kommandoskallet, for eksempel Linux Bash eller Windows-ledetekst. Alternativt kan du administrere Git gjennom skrivebordsprogrammer som GitHub Desktop. Git-baserte vertsplattformer gir et nettgrensesnitt som forenkler samhandling med repositorier på tjenestesiden.

Git vs GitHub

Som beskrevet tidligere, git er en multi-plattform, åpen kildekode DVCS som forenkler samarbeid ved hjelp av lokale repositorier, som kan synkroniseres med eksterne repositorier. GitHub er en skybasert tjeneste som leverer en vertsplattform for Git-repositorier. Det utvider utvalget av Git-funksjoner ved å inkludere støtte for:

  • Eksterne repositorier: tilrettelegge samhandling mellom distribuerte team.
  • samarbeidsverktøy: levere funksjoner som problemer, diskusjoner, pull-forespørsler, varsler, etiketter, handlinger, gafler, wikier og prosjekter.
  • webbasert grensesnitt: minimere behovet for å bruke Git-kommandoer
  • branch protection: fremtvinge betingelser som må tilfredsstilles før en fletting kan finne sted (for eksempel fullførte pull-forespørselsvurderinger).