Versionskontrol: Hvorfor du ikke kan leve uden det

Hvis du bruger en computer, er du sandsynligvis blevet konfronteret med spørgsmålet om forskellige versioner af filer. Uanset om det drejer sig om tekstfiler, datafiler eller programkode, du har skrevet, vil du altid blive konfronteret med beslutningen om at gemme og erstatte den forrige version eller gemme ud over den forrige version.


For enkeltudviklere er det allerede en udfordring at holde styr på forskellige versioner af et program, for ikke at nævne alle de forskellige sikkerhedskopier, du muligvis laver.

Forestil dig nu, at du arbejder som en del af et team på et projekt, der involverer tekst, multimedia og kodning – kort sagt en lang række informationer i værkerne.

Forestil dig yderligere: Lad os sige, at alle data eller programfiler arbejdes med af flere personer (”samtidighed”) – hver person tilføjer, gemmer, redigerer og gemmer igen. Hvordan i alverden vil du vide, hvem der gjorde hvad, hvornår og hvorfor og være i stand til at spore alle disse ændringer?

Du har brug for versionskontrol (VC).

I denne artikel skal vi se på, hvad versionskontrol er, og hvordan den har udviklet sig i årenes løb op til den nyeste generation.

Især ser vi på Git, den stadig mere populære versionskontrolapplikation fra de mennesker, der lavede Linux, og se nogle eksempler på, hvordan du ville bruge Git til at genvinde kontrol over alle disse forskellige revisioner af dine filer.

En primer til VC Jargon

Versionskontrol har sit eget sprog. Når du har angivet, hvilke mapper eller gruppe af filer der skal spores deres ændringer, kendes, kendes mapper eller filer som et arkiv, eller repo.

Ændringer spores automatisk, men de registreres kun som en enkelt samling af handlinger, kaldet en engagement, og registreres som et ændringssæt med et unikt revisionsnummer. Dette sikrer, at du kan hente den seneste version af en fil.

Hvis du vil sammenligne to revisioner (for eksempel hvis en fejl sneg sig ind i din kode på et tidspunkt), skal versionskontrolværktøjet lade dig adskille to filer, hvilket betyder at se forskellene mellem de to.

For at eksperimentere med en repo uden at risikere problemer eller skade, kan du oprette en gren, hvilket betyder en kopi af repoen, du kan derefter ændre parallelt. Hvis ændringerne i grenen er tilfredsstillende, kan du derefter flette grenen med hovedrepoen (master) eller endda en anden gren.

Ved sammenlægning er moderne versionskontrolsystemer normalt smarte nok til at finde ud af, hvilke ændringer der skal inkluderes fra hvilken filial eller repo, i henhold til den ændringshistorik, der opretholdes for hver enkelt. Hvis et versionskontrolsystem ikke kan beslutte, skal du muligvis manuelt løse en konflikt.

Version Control Systems Evolution

Versionsstyringsværktøjer er hidtil vist i tre generationer, idet hver generation tilføjer fleksibilitet og muligheder for samtidig.

Første generation

Med originale versionskontrolsystemer, selvom flere personer kunne arbejde på den samme fil, kunne de ikke gøre det samtidig. Filen blev låst for at forhindre andre i at få adgang til den på samme tid.

Et eksempel på et sådant værktøj er SCCS (Source Code Control System) til softwareudvikling fra 1972 og fremover. RCS (Revision Control System) blev oprettet som det gratis alternativ til SCCS og tilbød hurtigere drift, filialer og sammenlægning (stadig kun tillader en udvikler at arbejde på en fil på et givet tidspunkt).

Anden generation

Mange versionskontroller, der er i drift i dag, er i denne kategori. Samtidige ændringer på filer er mulige, skønt brugere skal flette aktuelle revisioner i deres arbejde, før de kan begå.

CVS (Concurrent Versions System) er en forekomst og tillader klient / server interaktion med brugen af ​​et lager. SVN (eller Apache Subversion fuldt ud) er muligvis det mest populære af alle versionskontrolsystemer, der bruges i dag.

SVN kan betragtes som en redesign af CVN med et moderne fundament og løsninger til tidligere CVS-begrænsninger.

Tredje generation

Et af de bedst kendte eksempler er også kendt som DVCS (Distribuerede versionskontrolsystemer), med muligheden for at adskille flette og begå operationer..

Der er ikke længere en central base for filer; forskellige grene har forskellige dele, hvilket også åbner døren til at arbejde på revisioner offline.

Et ægte eksempel ved hjælp af Git

Hvordan ser de operationer, der er beskrevet ovenfor, ud, når du bruger et virkelighedslivversionsstyringssystem?

Vi tager Git som et eksempel her ved hjælp af Linux-kommandolinjen. Først opretter vi et Git-arkiv til det bibliotek, vi er i i øjeblikket. Vi bruger kommandoen pwd for at se, hvor vi er:

1
2

$ pwd

/ Brugere / HJ / Desktop / repoer / apps

Derefter bruger vi git init-kommandoen til at oprette depotet (“master” -lageret) og få bekræftelse tilbage fra Git:

1
2

$ git init

Initialiseret tomt Git-lager i /Users/HJ/Desktop/repos/apps/.git

Antag, at vi tilføjer en ny fil, main.c, til vores arbejdsmappe. Brug af git status kommandoen giver os følgende information:

1
2
3
4
5
6
7
8
9

$ git-status

# På grenmester
#
# Første engagement
#
# Usporede filer:
# (brug "git tilføje …" at medtage i det, der vil blive forpligtet)
#
# Main.c

Vi bruger git add til at spore filen main.c

1 $ git tilføj main.c

Vi bruger git commit med en meddelelse (-m mulighed) om, hvad vi gør for at begå ændringer i main.c-filen.

1 $ git commit -m "tilføjelse af main.c til depotet"

Nu kan vi oprette en gren (f.eks. “Test”) med kommandoen git branch:

1 $ git gren test

Brug af git branch-kommandoen igen på egen hånd viser bare de lagre, vi nu har:

1
2
3

$ git gren

prøve

* mester

Til sidst, for at begynde at arbejde i “test” -grenen på kopien af ​​main.c nu i den gren, bruger vi git checkout-kommandoen for at få bekræftelse af, at vi nu arbejder i “test” -grenen.

1
2

$ git checkout test

Skiftet til gren "prøve"

For at komme tilbage til “master” grenen skal du blot bruge git checkout kommandoen igen:

1
2

$ git checkout master

Skiftet til gren "mestre"

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me