Programmering

Git-tutorial: Kom godt i gang med Git-versionskontrol

Denne artikel introducerer dig til Git, herunder hvordan du installerer den nødvendige software for at få adgang til Git-servere, hvor dit softwareprojekt vil blive gemt.

Begreber til versionskontrol

For at forstå Git og begrebet versionskontrol er det nyttigt at se på versionskontrol fra et historisk perspektiv. Der har været tre generationer software til versionskontrol.

Den første generation

Den første generation var meget enkel. Udviklere arbejdede på det samme fysiske system og "tjekket ud" en fil ad gangen.

Denne generation af versionskontrolsoftware brugte en teknik kaldet fillåsning. Da en udvikler tjekkede en fil ud, blev den låst, så ingen anden udvikler kunne redigere filen.

Eksempler på første generations versionskontrolsoftware inkluderer Revision Control System (RCS) og Source Code Control System (SCCS).

Anden generation

Problemer med den første generation omfattede følgende:

  • Kun en udvikler kunne arbejde på en fil ad gangen. Dette resulterede i en flaskehals i udviklingsprocessen.

  • Udviklere skulle logge ind direkte på systemet, der indeholdt versionskontrolsoftwaren.

Disse problemer blev løst i anden generation af versionskontrolsoftware. I anden generation lagres filer på en central server i et lager. Udviklere kan tjekke separate kopier af en fil. Når udvikleren afslutter arbejdet med en fil, checkes filen ind i arkivet.

Hvis to udviklere tjekker den samme version af en fil, eksisterer potentialet for problemer. Dette håndteres af en proces kaldet a fusionere.

Hvad er en fusion? Antag at to udviklere, Bob og Sue, tjekker version 5 af en fil med navnet abc.txt. Når Bob har afsluttet sit arbejde, kontrollerer han filen igen. Dette resulterer typisk i en ny version af filen, version 6.

Nogen tid senere tjekker Sue sin fil. Denne nye fil skal omfatte hendes ændringer og Bob's ændringer. Dette opnås gennem en fusionsproces.

Afhængigt af den versionskontrolsoftware, du bruger, kan der være forskellige måder at håndtere denne fletning på. I nogle tilfælde, som når Bob og Sue har arbejdet på helt forskellige dele af filen, er fletningsprocessen meget enkel. I tilfælde, hvor Sue og Bob arbejdede på de samme kodelinjer i filen, kan fusionsprocessen imidlertid være mere kompleks. I disse tilfælde bliver Sue nødt til at træffe beslutninger, f.eks. Om Bobs kode eller hendes kode vil være i den nye version af filen.

Når fletningsprocessen er afsluttet, finder processen med at overføre filen til lageret sted. At forpligte en fil betyder i det væsentlige at oprette en ny version i lageret; i dette tilfælde version 7 af filen.

Eksempler på anden generation af versionskontrolsoftware inkluderer Concurrent Versions System (CVS) og Subversion.

Den tredje generation

Den tredje generation kaldes distribuerede versionskontrolsystemer (DVCS'er). Som med anden generation indeholder en central repository server alle filerne til projektet. Imidlertid tjekker udviklere ikke individuelle filer fra lageret. I stedet tjekkes hele projektet ud, så udvikleren kan arbejde på det komplette sæt filer i stedet for kun individuelle filer.

En anden (meget stor) forskel mellem anden og tredje generation af versionskontrolsoftware har at gøre med, hvordan fusions- og forpligtelsesprocessen fungerer. Som tidligere nævnt er trinene i anden generation at udføre en fusion og derefter forpligte den nye version til lageret.

Med tredjegenerations versionskontrolsoftware kontrolleres filer og derefter flettes de.

Lad os for eksempel sige, at to udviklere tjekker en fil, der er baseret på den tredje version. Hvis en udvikler kontrollerer den pågældende fil, hvilket resulterer i en version 4 af filen, skal den anden udvikler først flette ændringerne fra sin udcheckede kopi med ændringerne i version 4 (og muligvis andre versioner). Når fletningen er afsluttet, kan den nye version forpligtes til lageret som version 5.

Hvis du fokuserer på, hvad der er i lageret (den midterste del af hver fase), ser du, at der er en meget lige udviklingslinje (ver1, ver2, ver3, ver4, ver5 osv.). Denne enkle tilgang til softwareudvikling giver nogle potentielle problemer:

  • At kræve, at en udvikler fusionerer, inden de forpligter sig, resulterer ofte i, at udviklere ikke ønsker at foretage deres ændringer regelmæssigt. Fletningsprocessen kan være en smerte, og udviklere kan beslutte at bare vente til senere og foretage en fusion i stedet for en flok regelmæssige fusioner. Dette har en negativ indvirkning på softwareudvikling, da der pludselig føjes enorme klumper med kode til en fil. Derudover vil du tilskynde udviklere til at foretage ændringer i arkivet, ligesom du vil opmuntre en person, der skriver et dokument til at gemme regelmæssigt.
  • Meget vigtigt: Version 5 i dette eksempel er ikke nødvendigvis det arbejde, som udvikleren oprindeligt gennemførte. Under sammenlægningsprocessen kan udvikleren muligvis kassere noget af sit arbejde for at afslutte sammenlægningsprocessen. Dette er ikke ideelt, fordi det resulterer i tab af potentielt god kode.

En bedre, selvom det uden tvivl mere kompleks, teknik kan bruges. Det kaldes rettet acyklisk graf (DAG).

Se det samme scenarie som ovenfor, hvor to udviklere tjekker version 3 af en fil. Her, hvis en udvikler kontrollerer den pågældende fil, resulterer den stadig i en version 4 af filen. Den anden check-in-proces resulterer imidlertid i en version 5-fil, der ikke er baseret på version 4, men snarere uafhængig af version 4. I det næste trin i processen flettes version 4 og 5 af filen for at oprette en version 6.

Selvom denne proces er mere kompleks (og potentielt meget mere kompleks, hvis du har et stort antal udviklere), giver den nogle fordele i forhold til en enkelt udviklingslinje:

  • Udviklere kan foretage deres ændringer regelmæssigt og ikke behøver at bekymre sig om at fusionere før på et senere tidspunkt.
  • Fusionsprocessen kan delegeres til en bestemt udvikler, der har en bedre idé om hele projektet eller koden end de andre udviklere har.
  • Når som helst kan projektlederen gå tilbage og se nøjagtigt, hvilket arbejde hver enkelt udvikler oprettede.

Bestemt findes der et argument for begge metoder. Husk dog, at denne artikel fokuserer på Git, der bruger den dirigerede acykliske grafmetode til tredjegenerations versionskontrolsystemer.

Installation af Git

Du har muligvis allerede Git på dit system, fordi det nogle gange er installeret som standard (eller en anden administrator har muligvis installeret det). Hvis du har adgang til systemet som en almindelig bruger, kan du udføre følgende kommando for at afgøre, om du har Git installeret:

ocs @ ubuntu: ~ $ hvilken git / usr / bin / git

Hvis Git er installeret, så er stien til git kommando leveres som vist i den foregående kommando. Hvis den ikke er installeret, får du enten ingen output eller en fejl som følgende:

[ocs @ centos ~] # hvilken git / usr / bin / hvilken: ingen git i (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin: / usr / sbin: / bin: / sbin: / root / bin)

Som administrator på et Debian-baseret system kan du bruge dpkg kommando for at afgøre, om Git-pakken er installeret:

root @ ubuntu: ~ # dpkg -l git Ønsket = Ukendt / Installer / Fjern / Rens / Hold | Status = Ikke / Inst / Conf-filer / Udpakket / halF-conf / Halv-inst / trig-aVente / rigTrig-pend | / Err? = (Ingen) / Geninstallation krævet (Status, Fejl: store bogstaver = dårlig) | | / Navn Version Arkitektur Beskrivelse +++ - ======== - ============== - ============== - === ======================================= ii git 1: 1.9.1-1ubun amd64 hurtig, skalerbar , distribueret ➥revision con

Som administrator på et Red Hat-baseret system kan du bruge omdrejningstal kommando for at afgøre, om git-pakken er installeret:

[root @ centos ~] # rpm -q git git-1.8.3.1-6.el7_2.1.x86_64

Hvis Git ikke er installeret på dit system, skal du enten logge ind som rodbruger eller bruge sudo eller su for at installere softwaren. Hvis du er logget ind som rodbruger på et Debian-baseret system, kan du bruge følgende kommando til at installere Git:

apt-get install git

Hvis du er logget ind som rodbruger på et Red Hat-baseret system, kan du bruge følgende kommando til at installere Git:

yum installere git

Få mere end Git

Overvej at installere softwarepakken git-all. Denne pakke indeholder nogle ekstra afhængighedspakker, der tilføjer Git mere strøm. Selvom du muligvis ikke bruger disse funktioner i starten, vil det være godt at have dem tilgængelige, når du er klar til at udføre mere avancerede Git-funktioner.

Git koncepter og funktioner

En af udfordringerne ved at bruge Git er bare at forstå begreberne bag det. Hvis du ikke forstår begreberne, virker alle kommandoer bare som en slags sort magi. Dette afsnit fokuserer på de kritiske Git-begreber samt introducerer dig til nogle af de grundlæggende kommandoer.

Git faser

Det er meget vigtigt at huske, at du tjekker et helt projekt, og at det meste af det arbejde, du laver, vil være lokalt for det system, du arbejder på. De filer, du tjekker ud, placeres i et bibliotek under dit hjemmekatalog.

For at få en kopi af et projekt fra et Git-arkiv bruger du en proces kaldet kloning. Kloning opretter ikke bare en kopi af alle filerne fra lageret; det udfører faktisk tre primære funktioner:

  • Opretter et lokalt lager af projektet under Projekt navn/.git-bibliotek i dit hjemmekatalog. Projektets filer på dette sted anses for at være tjekket ud fra det centrale lager.
  • Opretter et bibliotek, hvor du direkte kan se filerne. Dette kaldes arbejdsområde. Ændringer foretaget i arbejdsområdet er ikke straks versionskontrolleret.
  • Opretter et mellemstationer. Iscenesættelsesområdet er designet til at gemme ændringer i filer, før du forpligter dem til det lokale arkiv.

Dette betyder, at hvis du kloner et projekt kaldet Jacumba, vil hele projektet blive gemt i Jacumba / .git bibliotek under dit hjemmekatalog. Du bør ikke prøve at ændre disse direkte. Se i stedet direkte i ~ / Jacumba katalog for at se filerne fra projektet. Dette er de filer, du skal ændre.

Antag, at du har foretaget en ændring af en fil, men du skal arbejde på nogle andre filer, før du var klar til at foretage ændringer i det lokale lager. I så fald ville du gøre det scene den fil, du er færdig med at arbejde på. Dette ville forberede det på at blive forpligtet til det lokale arkiv.

Når du har foretaget alle ændringer og iscenesat alle filer, forpligter du dem til det lokale arkiv.

Indse, at det at indsætte de iscenesatte filer kun sender dem til det lokale lager. Dette betyder, at kun du har adgang til de ændringer, der er foretaget. Processen med at kontrollere de nye versioner til det centrale lager kaldes a skubbe.

Valg af din Git-repository-vært

For det første den gode nyhed: Mange organisationer leverer Git-hosting - i skrivende stund er der mere end to dusin valg. Dette betyder, at du har mange muligheder at vælge imellem. Det er den gode nyhed ... og de dårlige nyheder.

Det er kun dårlige nyheder, fordi det betyder, at du virkelig skal bruge lidt tid på at undersøge fordele og ulemper ved værtsorganisationerne. For eksempel opkræver de fleste ikke grundlæggende hosting, men opkræver betaling for store projekter. Nogle leverer kun offentlige opbevaringssteder (alle kan se dit arkiv), mens andre giver dig mulighed for at oprette private opbevaringssteder. Der er mange andre funktioner at overveje.

En funktion, der måske står højt på din liste, er en webgrænseflade. Selvom du kan udføre næsten alle arkivhandlinger lokalt på dit system, kan det være meget nyttigt at kunne udføre nogle operationer via en webgrænseflade. Udforsk den interface, der leveres, inden du foretager dit valg.

I det mindste anbefaler jeg at overveje følgende:

  • //bitbucket.org
  • //www.cloudforge.com
  • //www.codebasehq.com
  • //github.com
  • //gitlab.com

Bemærk, at jeg valgte Gitlab.com til eksemplerne nedenfor. Enhver af værterne på den foregående liste ville have fungeret lige så godt; Jeg valgte Gitlab.com simpelthen fordi det tilfældigvis var den, jeg brugte på mit sidste Git-projekt.

Konfiguration af Git

Nu hvor du har gennemgået al teorien, er det tid til faktisk at gøre noget med Git. Dette næste afsnit antager følgende:

  • Du har installeret git eller git-all softwarepakke på dit system.
  • Du har oprettet en konto på en Git-hostingtjeneste.

Den første ting, du vil gøre, er at udføre nogle grundlæggende opsætninger. Hver gang du udfører en forpligtelseshandling, vil dit navn og din e-mail-adresse blive inkluderet i metadataene. For at indstille disse oplysninger skal du udføre følgende kommandoer:

ocs @ ubuntu: ~ $ git config - global bruger.navn "Bo Rothwell" ocs @ ubuntu: ~ $ git config - global user.email "[email protected]"

Det er klart, at du vil erstatte det "Bo Rothwell" med dit navn og "[email protected]" med din e-mail-adresse. Det næste trin er at klone dit projekt fra Git-hostingtjenesten. Bemærk, at der kun er én fil i klientens hjemmekatalog før kloning:

ocs @ ubuntu: ~ $ ls first.sh

Følgende klonede et projekt med navnet ocs: