Udforsk versionsstyring ved hjælp af Git

Fuldført

Der er forskellige typer VCS-systemer (Version Control Systems), men generelt kan de kategoriseres som centraliserede og distribuerede. I de senere år (delvist på grund af den voksende popularitet af DevOps), fik sidstnævnte kategori betydelig popularitet, med Git bliver de facto-standarden i moderne softwareudvikling. Denne bestemte VCS er det mest egnede valg for organisationen i vores eksempelscenarie, især i betragtning af at den har til hensigt at bruge GitHub som målplatform for dens DevOps-overgang. I dette undermodul kan du udforske brugen af Git som versionsstyring.

Centraliseret vs. styring af distribuerede versioner

Både CVCS(central version control systems) og distribuerede versionskontrolsystemer (DVCS) giver mulighed for at administrere og spore ændringer i softwareudviklingsprojekter. De primære forskelle mellem dem er relateret til den måde, de implementerer lagre og samarbejde på. Især:

• lagerplacering: I centraliserede systemer er der en enkelt centraliseret forekomst af lageret, der indeholder projektets fulde historik. I distribuerede systemer vil hvert teammedlem typisk have én fuldt funktionel lokal kopi af hele lageret, som muligvis inkluderer hele versionshistorikken.
• Netværksforbindelse: I centraliserede systemer kræves der adgang til den centraliserede forekomst af lageret for at kunne udføre mange handlinger, herunder opdateringer og historikhentning. I distribuerede systemer kan alle aktiviteter udføres i forhold til den lokale kopi af lageret.
• Samarbejdsmodel: I centraliserede systemer tjekker udviklere filer ud fra den centraliserede forekomst af lageret, mens de har forbindelse til det via et netværk, før de foretager ændringer og foretager ændringerne. Dette forhindrer, at andre kan tjekke ændringer ud af filer. I distribuerede systemer foretager og foretager udviklere ændringer af deres lokale kopi af lageret, som på et tidspunkt senere synkroniseres med andre kopier.
• forgrening og fletning af model: I centraliserede systemer kræver forgrening og fletning typisk koordinering med andre. I distribuerede systemer kan forgreninger oprettes uafhængigt i lokale kopier og flettes bagefter.

Det er værd at bemærke, at selvom den distribuerede model ikke er afhængig af at have et centralt lager (i traditionel forstand), er det almindeligt at implementere én kopi af lageret, som hostes af tjenester som GitHub, GitLab eller Bitbucket. Denne forekomst fungerer som omdrejningspunktet for samarbejde og synkronisering.

Git-terminologi

For at kunne arbejde med Git er det vigtigt at blive fortrolig med terminologien. Nogle af begreberne er unikke for Git, adskiller det fra andre DVCS. De mest grundlæggende Git-begreber omfatter:

• arbejdstræ: en mappestruktur, der indeholder alle projektets filer.
• lager (også kaldet lager): den mappe, der er placeret på øverste niveau i et arbejdstræ, og som er vært for alle projektets filer sammen med versionshistorikken for disse filer.
• Klon: Handlingen til oprettelse af en kopi af et fjernlager på en lokal computer for at arbejde på et projekt, som du har adgang til.
• Kopi: Handlingen til oprettelse af en GitHub-hostet kopi af et fjernlager for at arbejde på et projekt, som du ikke har adgang til. En kopi bruges typisk, hvis du vil bidrage til en andens projekt eller oprette din egen version af dette projekt. Selvom du ikke har skriveadgang til det oprindelige lager, kan du administrere din kopi fuldt ud.
• Commit: et øjebliksbillede af de ændringer, der er foretaget af filerne i et lager på et bestemt tidspunkt. Bekræftelser bruges til at registrere og gemme ændringer.
• det midlertidige område en mellemliggende placering (som ikke er en del af lageret), hvor ændringer af filer i arbejdstræet forberedes, før de bekræftes. Det giver udviklere mulighed for at vælge de ændringer, de vil bekræfte.
• Branch: en navngivet række sammenkædede bekræftelser. Kort og godt repræsenterer en forgrening en særskilt version af et projekt. Dette gør det muligt at arbejde på forskellige dele af et projekt på samme tid, uden at det påvirker hovedversionen. Den seneste bekræftelse i en forgrening kaldes head. Den standardgren, der genereres automatisk, når du initialiserer et lager, kaldes primære eller master.
• Flet: processen med at kombinere ændringer fra én forgrening (eller bekræftelse) til en anden. Dette integrerer ændringer fra én forgrening til en anden.
• Objekt: en af fire typer objekter, der er tilgængelige i et lager. Disse objekter omfatter blobs, der repræsenterer individuelle filer, et træ, der repræsenterer et arbejdstræ, en bekræftelse, der repræsenterer en bestemt version af arbejdstræet, og en *-kode, som er en etiket, der er tildelt en individuel bekræftelse.
• Hash: et automatisk genereret entydigt id med fast længde, der repræsenterer indholdet af et objekt. Når objektet ændres, ændres dets hash også. Dette giver Git mulighed for at bestemme, hvilket indhold i et lager der er blevet opdateret.
• Remote: en reference til et andet lager (bortset fra det lokale), der typisk peger på den tjenesteværtede forekomst af lageret. Dette fungerer som standard for push- og pullhandlinger.
• Pull-: den handling, der henter ændringer fra et fjernlager og fletter dem til den aktuelle forgrening.
• Push: Den handling, der sender lokale bekræftelser til et fjernlager, og opdaterer den med de ændringer, der er foretaget lokalt.
• Fetch: den handling, der henter ændringer fra et fjernlager uden automatisk at flette dem. Dette gør det muligt at gennemse dem, før de anvender en fletning.
• Pull-anmodning: en funktion på Git-baserede hostingplatforme (f.eks GitHub), der gør det muligt for udviklere at foreslå ændringer og anmode om, at de flettes til en destinationsforgrening.

Git har også et omfattende sæt kommandoer, som giver mulighed for fuldt ud at implementere og administrere versionsstyring via kommandoshell, f.eks. Linux Bash eller Windows-kommandoprompt. Du kan også administrere Git via skrivebordsprogrammer, f.eks. GitHub Desktop. Git-baserede hostingplatforme leverer en webgrænseflade, der faciliterer interaktion med lagre på tjenestesiden.

Git vs. GitHub

Som beskrevet tidligere er Git en flerplatforms DVCS med åben kildekode, der letter samarbejdet ved hjælp af lokale lagre, som kan synkroniseres med fjernlagre. GitHub er en cloudbaseret tjeneste, der leverer en hostingplatform til Git-lagre. Det udvider rækken af Git-funktioner ved at inkludere understøttelse af:

• fjernlagre: lette interaktionen mellem distribuerede teams.
• Samarbejdsværktøjer: levering af funktioner som problemer, diskussioner, pullanmodninger, meddelelser, mærkater, handlinger, gafler, wikier og projekter.
• webbaserede grænseflade: minimerer behovet for at bruge Git-kommandoer
• Forgreningsbeskyttelse: Gennemtvingelse af betingelser, der skal være opfyldt, før en fletning kan finde sted (f.eks. fuldførte pullanmodningsgennemgange).