Hvordan bruke Git versjonskontrollsystem i Linux [Omfattende veiledning]


Versjonskontroll (revisjonskontroll eller kildekontroll) er en måte å registrere endringer i en fil eller samling av filer over tid, slik at du kan hente frem spesifikke versjoner senere. Et versjonskontrollsystem (eller kort sagt VCS) er et verktøy som registrerer endringer i filer på et filsystem.

Det er mange versjonskontrollsystemer der ute, men Git er for tiden det mest populære og ofte brukte, spesielt for kildekodebehandling. Versjonskontroll kan faktisk brukes for nesten alle typer filer på en datamaskin, ikke bare kildekode.

Versjonskontrollsystemer/verktøy tilbyr flere funksjoner som lar enkeltpersoner eller en gruppe mennesker:

  • lage versjoner av et prosjekt.
  • spore endringer nøyaktig og løse konflikter.
  • slå sammen endringer til en felles versjon.
  • rulle tilbake og angre endringer i valgte filer eller et helt prosjekt.
  • få tilgang til historiske versjoner av et prosjekt for å sammenligne endringer over tid.
  • se hvem som sist endret noe som kan forårsake et problem.
  • lage en sikker ekstern sikkerhetskopi av et prosjekt.
  • bruke flere maskiner for å jobbe med ett enkelt prosjekt og mye mer.

Et prosjekt under et versjonskontrollsystem som Git vil hovedsakelig ha tre seksjoner, nemlig:

  • et arkiv: en database for registrering av tilstanden til eller endringer i prosjektfilene dine. Den inneholder alle nødvendige Git-metadata og objekter for det nye prosjektet. Merk at dette vanligvis er det som kopieres når du kloner et depot fra en annen datamaskin på et nettverk eller en ekstern server.
  • en arbeidskatalog eller et arbeidsområde: lagrer en kopi av prosjektfilene som du kan jobbe med (foreta tillegg, slettinger og andre modifikasjonshandlinger).
  • et iscenesettelsesområde: en fil (kjent som indeks under Git) i Git-katalogen, som lagrer informasjon om endringer, som du er klar til å foreta (lagre tilstanden til en fil eller et sett med filer) til depotet.

Det er to hovedtyper av VCS-er, hvor hovedforskjellen er antall depoter:

  • Sentraliserte versjonskontrollsystemer (CVCSer): her får hvert prosjektteammedlem sin egen lokale arbeidskatalog, men de forplikter endringer til bare ett enkelt sentralt depot.
  • Distribuerte versjonskontrollsystemer (DVCS): under dette får hvert prosjektteammedlem sin egen lokale arbeidskatalog og Git-katalog der de kan foreta forpliktelser. Etter at en person forplikter seg lokalt, kan ikke andre teammedlemmer få tilgang til endringene før han/hun skyver dem til sentrallageret. Git er et eksempel på en DVCS.

I tillegg kan et Git-lager være bart (depot som ikke har en arbeidskatalog) eller ikke-bare (en med en fungerende katalog) katalog). Delte (eller offentlige eller sentrale) depoter skal alltid være nakne – alle Github-lagre er bare.

Lær versjonskontroll med Git

Git er et gratis og åpen kildekode, raskt, kraftig, distribuert, enkelt å bruke og populært versjonskontrollsystem som er veldig effektivt med store prosjekter, og har et bemerkelsesverdig forgrenings- og sammenslåingssystem. Den er designet for å håndtere data mer som en serie øyeblikksbilder av et minifilsystem, som er lagret i en Git-katalog.

Arbeidsflyten under Git er veldig enkel: du gjør endringer i filer i arbeidskatalogen din, og legger deretter selektivt til bare de filene som har endret seg, til iscenesettelsen, for å være en del av din neste forpliktelse.

Når du er klar, foretar du en commit, som tar filene fra oppsamlingsområdet og lagrer det øyeblikksbildet permanent i Git-katalogen.

For å installere Git i Linux, bruk riktig kommando for distribusjonen du ønsker:

sudo apt install git   [On Debian/Ubuntu]
sudo yum install git   [On CentOS/RHEL]

Etter å ha installert Git, anbefales det at du forteller Git hvem du er ved å oppgi ditt fulle navn og e-postadresse, som følger:

git config --global user.name “Aaron Kili”
git config --global user.email “[email ”

For å sjekke Git-innstillingene dine, bruk følgende kommando.

git config --list 

Oppretter et nytt Git-depot

Delte depoter eller sentraliserte arbeidsflyter er veldig vanlige, og det er det vi vil demonstrere her. For eksempel antar vi at du har fått i oppgave å sette opp et eksternt sentrallager for systemadministratorer/programmerere fra ulike avdelinger i din organisasjon, for å jobbe med et prosjekt kalt bashscripts, som vil bli lagret under >/projects/scritpts/ på serveren.

SSH inn på den eksterne serveren og opprett den nødvendige katalogen, opprett en gruppe som heter sysadmins (legg til alle prosjektteammedlemmer i denne gruppen, f.eks. brukeradmin), og sett de riktige tillatelsene på denne katalogen.

mkdir-p /projects/scripts/
groupadd sysadmins
usermod -aG sysadmins admin
chown :sysadmins -R /projects/scripts/
chmod 770 -R /projects/scripts/

Initialiser deretter et bart prosjektlager.

git init --bare /projects/scripts/bashscripts

På dette tidspunktet har du initialisert en bar Git-katalog som er den sentrale lagringsfasiliteten for prosjektet. Prøv å lage en liste over katalogen for å se alle filene og katalogene der:

ls -la /projects/scripts/bashscripts/

Klone et Git-lager

Klon nå det eksterne delte Git-lageret til din lokale datamaskin via SSH (du kan også klone via HTTP/HTTPS hvis du har en nettserver installert og riktig konfigurert, som er tilfelle med de fleste offentlige depoter på Github), for eksempel:

git clone ssh://admin@remote_server_ip:/projects/scripts/bashscripts 

For å klone den til en spesifikk katalog (~/bin/bashscripts), bruk kommandoen nedenfor.

git clone ssh://admin@remote_server_ip:/projects/scripts/bashscripts ~/bin/bashscripts

Du har nå en lokal forekomst av prosjektet i et ikke-bart depot (med en arbeidskatalog), du kan lage den opprinnelige strukturen til prosjektet (dvs. legge til en README.md fil, underkataloger for forskjellige kategorier av skript, for eksempel recon for å lagre rekognoseringsskript, sysadmin ro store sysadmin-skript osv.):

cd ~/bin/bashscripts/
ls -la

Sjekk en Git-statussammendrag

For å vise statusen til arbeidskatalogen din, bruk statuskommandoen som viser deg eventuelle endringer du har gjort; hvilke filer som ikke spores av Git; de endringene som er iscenesatt og så videre.

git status 

Git Stage Changes og Commit

Deretter trinn alle endringene ved å bruke add-kommandoen med -A-bryteren og foreta den første commit. -a-flagget instruerer kommandoen til å automatisk iscenesette filer som har blitt endret, og -m brukes til å spesifisere en commit-melding:

git add -A
git commit -a -m "Initial Commit"

Publiser Local Commits til Remote Git Repository

Som prosjektleder, nå som du har opprettet prosjektstrukturen, kan du publisere endringene til det sentrale depotet ved å bruke push-kommandoen som vist.

git push origin master

Akkurat nå bør det lokale git-depotet ditt være oppdatert med prosjektets sentrale repository (opprinnelse), du kan bekrefte dette ved å kjøre statuskommandoen en gang til.

git status

Du kan også informere kollegene om å begynne å jobbe med prosjektet ved å klone depotet til deres lokale datamaskiner.

Opprett en ny Git-gren

Forgrening lar deg jobbe med en funksjon i prosjektet ditt eller fikse problemer raskt uten å berøre kodebasen (hovedgrenen). For å opprette en ny filial og deretter bytte til den, bruk henholdsvis gren og checkout-kommandoene.

git branch latest
git checkout latest

Alternativt kan du opprette en ny filial og bytte til den i ett trinn ved å bruke checkout-kommandoen med -b-flagget.

git checkout -b latest

Du kan også opprette en ny gren basert på en annen gren, for eksempel.

git checkout -b latest master

For å sjekke hvilken gren du er i, bruk grenkommando (en stjerne indikerer den aktive grenen):

git branch

Etter å ha opprettet og byttet til den nye grenen, gjør noen endringer under den og gjør noen forpliktelser.

vim sysadmin/topprocs.sh
git status
git commit add  sysadmin/topprocs.sh
git commit -a -m 'modified topprocs.sh'

Slå sammen endringer fra en gren til en annen

For å slå sammen endringene under grentesten til hovedgrenen, bytt til hovedgrenen og gjør sammenslåingen.

git checkout master 
git merge test 

Hvis du ikke lenger trenger en bestemt gren, kan du slette den ved å bruke -d-bryteren.

git branch -d test

Last ned endringer fra Remote Central Repository

Forutsatt at teammedlemmene dine har pushet endringer til det sentrale prosjektlageret, kan du laste ned eventuelle endringer til din lokale forekomst av prosjektet ved å bruke pull-kommandoen.

git pull origin
OR
git pull origin master	#if you have switched to another branch

Inspiser Git Repository og utfør sammenligninger

I denne siste delen vil vi dekke noen nyttige Git-funksjoner som holder styr på alle aktiviteter som skjedde i depotet ditt, og dermed lar deg se prosjekthistorikken.

Den første funksjonen er Git-logg, som viser commit-logger:

git log

En annen viktig funksjon er vis kommandoen som viser ulike typer objekter (som forpliktelser, tagger, trær osv..):

git show

Den tredje viktige funksjonen du trenger å vite er diff-kommandoen, som brukes til å sammenligne eller vise forskjeller mellom grener, vise endringer mellom arbeidskatalogen og indeksen, endringer mellom to filer på disken og mye mer.

For å vise forskjellen mellom master og siste gren, kan du for eksempel kjøre følgende kommando.

git diff master latest

Les også: 10 beste Git-alternativer for å være vertskap for åpen kildekode-prosjekter

Sammendrag

Git lar et team av mennesker jobbe sammen ved å bruke samme fil(er), mens de registrerer endringer i filen(e) over tid, slik at de kan hente spesifikke versjoner senere.

På denne måten kan du bruke Git til å administrere kildekode, konfigurasjonsfiler eller hvilken som helst fil som er lagret på en datamaskin. Det kan være lurt å referere til Git Online Documentation for ytterligere dokumentasjon.