Denne artikkelen introduserer deg for Git, inkludert hvordan du installerer nødvendig programvare for å få tilgang til Git-servere der programvareprosjektet ditt blir lagret.
Konsepter for versjonskontroll
For å forstå Git og begrepet versjonskontroll er det nyttig å se på versjonskontroll fra et historisk perspektiv. Det har vært tre generasjoner med versjonskontrollprogramvare.
Den første generasjonen
Den første generasjonen var veldig enkel. Utviklere jobbet med det samme fysiske systemet og "sjekket ut" en fil om gangen.
Denne generasjonen av versjonskontrollprogramvare brukte en teknikk som heter fillåsing. Når en utvikler sjekket ut en fil, ble den låst, slik at ingen andre utviklere kunne redigere filen.
Eksempler på første generasjons versjonskontrollprogramvare inkluderer Revision Control System (RCS) og Source Code Control System (SCCS).
Andre generasjon
Problemene med den første generasjonen inkluderte følgende:
Bare en utvikler kunne jobbe med en fil om gangen. Dette resulterte i en flaskehals i utviklingsprosessen.
Utviklere måtte logge på direkte til systemet som inneholdt versjonskontrollprogramvaren.
Disse problemene ble løst i andre generasjon versjonskontrollprogramvare. I andre generasjon lagres filer på en sentralisert server i et depot. Utviklere kan sjekke ut separate kopier av en fil. Når utvikleren fullfører arbeidet med en fil, sjekkes filen inn i depotet.
Hvis to utviklere sjekker ut den samme versjonen av en fil, er det potensialet for problemer. Dette håndteres av en prosess som kalles a slå sammen.
Hva er en sammenslåing? Anta at to utviklere, Bob og Sue, sjekker ut versjon 5 av en fil som heter abc.txt. Etter at Bob har fullført arbeidet, sjekker han filen inn igjen. Vanligvis resulterer dette i en ny versjon av filen, versjon 6.
Noe senere sjekker Sue inn filen. Denne nye filen må inneholde endringene og endringene hennes. Dette oppnås gjennom prosessen med en sammenslåing.
Avhengig av hvilken versjonskontrollprogramvare du bruker, kan det være forskjellige måter å håndtere denne sammenslåingen på. I noen tilfeller, for eksempel når Bob og Sue har jobbet med helt forskjellige deler av filen, er sammenslåingsprosessen veldig enkel. I tilfeller der Sue og Bob jobbet med de samme kodelinjene i filen, kan sammenslåingsprosessen imidlertid være mer kompleks. I slike tilfeller må Sue ta avgjørelser, for eksempel om Bobs kode eller hennes kode vil være i den nye versjonen av filen.
Etter at sammenslåingsprosessen er fullført, finner prosessen med å overføre filen til depotet. Å forplikte en fil betyr i hovedsak å opprette en ny versjon i depotet; i dette tilfellet versjon 7 av filen.
Eksempler på andregenerasjons versjonskontrollprogramvare inkluderer Concurrent Versions System (CVS) og Subversion.
Den tredje generasjonen
Den tredje generasjonen er referert til som distribuerte versjonskontrollsystemer (DVCSer). Som med andre generasjon inneholder en sentral depotserver alle filene for prosjektet. Imidlertid sjekker ikke utviklere enkeltfiler fra depotet. I stedet sjekkes hele prosjektet ut, slik at utvikleren kan jobbe med det komplette settet med filer i stedet for bare individuelle filer.
En annen (veldig stor) forskjell mellom andre og tredje generasjon versjonskontrollprogramvare har å gjøre med hvordan fusjons- og forpliktelsesprosessen fungerer. Som tidligere nevnt, er trinnene i andre generasjon å utføre en sammenslåing og deretter forplikte den nye versjonen til depotet.
Med tredjegenerasjons versjonskontrollprogramvare sjekkes inn filer og deretter slås de sammen.
La oss for eksempel si at to utviklere sjekker ut en fil som er basert på den tredje versjonen. Hvis en utvikler sjekker den filen, og resulterer i en versjon 4 av filen, må den andre utvikleren først slå sammen endringene fra den utsjekkede kopien med endringene i versjon 4 (og muligens andre versjoner). Etter at sammenslåingen er fullført, kan den nye versjonen være forpliktet til depotet som versjon 5.
Hvis du fokuserer på det som er i depotet (midtdelen av hver fase), ser du at det er en veldig rett linje for utvikling (ver1, ver2, ver3, ver4, ver5 og så videre). Denne enkle tilnærmingen til programvareutvikling gir noen potensielle problemer:
- Å kreve at en utvikler slår seg sammen før de forplikter seg, fører ofte til at utviklere ikke ønsker å foreta endringene sine med jevne mellomrom. Sammenslåingsprosessen kan være vondt, og utviklere kan bestemme seg for å bare vente til senere og gjøre en sammenslåing i stedet for en haug med vanlige sammenslåinger. Dette har en negativ innvirkning på programvareutvikling da plutselig blir store deler av kode lagt til en fil. I tillegg vil du oppmuntre utviklere til å foreta endringer i depotet, akkurat som du vil oppmuntre noen som skriver et dokument til å lagre med jevne mellomrom.
- Veldig viktig: Versjon 5 i dette eksemplet er ikke nødvendigvis arbeidet som utvikleren opprinnelig fullførte. Under sammenslåingsprosessen kan utvikleren forkaste noe av sitt arbeid for å fullføre sammenslåingsprosessen. Dette er ikke ideelt fordi det resulterer i tap av potensielt god kode.
En bedre, selv om det uten tvil kan være mer kompleks, kan brukes. Det kalles rettet asyklisk graf (DAG).
Se det samme scenariet som ovenfor, der to utviklere sjekker ut versjon 3 av en fil. Her, hvis en utvikler sjekker den filen, resulterer den fremdeles i en versjon 4 av filen. Den andre innsjekkingsprosessen resulterer imidlertid i en versjon 5-fil som ikke er basert på versjon 4, men heller uavhengig av versjon 4. I neste trinn av prosessen blir versjon 4 og 5 av filen slått sammen for å lage en versjon 6.
Selv om denne prosessen er mer kompleks (og potensielt mye mer kompleks hvis du har et stort antall utviklere), gir den noen fordeler i forhold til en enkelt utviklingslinje:
- Utviklere kan foreta endringene sine med jevne mellomrom og ikke trenger å bekymre seg for sammenslåing før på et senere tidspunkt.
- Sammenslåingsprosessen kan delegeres til en bestemt utvikler som har en bedre ide om hele prosjektet eller koden enn de andre utviklerne har.
- Når som helst kan prosjektlederen gå tilbake og se nøyaktig hvilket arbeid hver enkelt utvikler opprettet.
Det eksisterer absolutt et argument for begge metodene. Husk imidlertid at denne artikkelen fokuserer på Git, som bruker den målrettede asykliske grafmetoden til tredjegenerasjons versjonskontrollsystemer.
Installere Git
Du har kanskje allerede Git på systemet fordi det noen ganger er installert som standard (eller en annen administrator kan ha installert det). Hvis du har tilgang til systemet som en vanlig bruker, kan du utføre følgende kommando for å avgjøre om du har Git installert:
ocs @ ubuntu: ~ $ som git / usr / bin / git
Hvis Git er installert, er stien til git kommandoen er gitt, som vist i forrige kommando. Hvis den ikke er installert, får du enten ingen utdata eller en feil 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-basert system kan du bruke dpkg kommando for å avgjøre om Git-pakken er installert:
root @ ubuntu: ~ # dpkg -l git Ønsket = Ukjent / Installer / Fjern / Rens / Hold | Status = Ikke / Inst / Conf-filer / Utpakket / halF-conf / Halv-inst / trig-aVente / rigTrig-pend | / Err? = (Ingen) / Gjenopprett (Status, Err: store bokstaver = dårlig) | | / Navn Versjon Arkitektur Beskrivelse +++ - ======== - ============== - ============== - === ======================================= ii git 1: 1.9.1-1ubun amd64 rask, skalerbar , distribuert ➥revision con
Som administrator på et Red Hat-basert system kan du bruke rpm kommando for å avgjøre om git-pakken er installert:
[root @ centos ~] # rpm -q git git-1.8.3.1-6.el7_2.1.x86_64
Hvis Git ikke er installert på systemet ditt, må du enten logge på som rotbruker eller bruke sudo eller su for å installere programvaren. Hvis du er logget på som rotbruker på et Debian-basert system, kan du bruke følgende kommando for å installere Git:
apt-get install git
Hvis du er logget på som rotbruker på et Red Hat-basert system, kan du bruke følgende kommando til å installere Git:
yum installer git
Få mer enn Git
Vurder å installere programvarepakken git-all. Denne pakken inneholder noen ekstra avhengighetspakker som gir Git mer kraft. Selv om du kanskje ikke bruker disse funksjonene i begynnelsen, vil det være bra å ha dem tilgjengelig når du er klar til å utføre mer avanserte Git-funksjoner.
Git konsepter og funksjoner
En av utfordringene med å bruke Git er bare å forstå konseptene bak den. Hvis du ikke forstår begrepene, virker alle kommandoene bare som en slags svart magi. Denne delen fokuserer på de kritiske Git-konseptene, og introduserer deg til noen av de grunnleggende kommandoene.
Git scener
Det er veldig viktig å huske at du sjekker ut et helt prosjekt, og at det meste av arbeidet du gjør vil være lokalt for systemet du jobber med. Filene du sjekker ut, blir plassert i en katalog under hjemmekatalogen.
For å få en kopi av et prosjekt fra et Git-arkiv, bruker du en prosess som heter kloning. Kloning lager ikke bare en kopi av alle filene fra depotet; den utfører faktisk tre primære funksjoner:
- Oppretter et lokalt depot for prosjektet under prosjektnavn/.git-katalogen i hjemmekatalogen. Filene til prosjektet på dette stedet anses å være sjekket ut fra det sentrale depotet.
- Oppretter en katalog der du kan se filene direkte. Dette kalles arbeidsplass. Endringer som er gjort i arbeidsområdet er ikke versjonskontrollert umiddelbart.
- Skaper et iscenesettingsområde. Stagingområdet er designet for å lagre endringer i filer før du forplikter dem til det lokale depotet.
Dette betyr at hvis du skulle klone et prosjekt som heter Jacumba, ville hele prosjektet bli lagret i Jacumba / .git katalogen under hjemmekatalogen. Du bør ikke prøve å endre disse direkte. Se i stedet direkte i ~ / Jacumba katalog for å se filene fra prosjektet. Dette er filene du bør endre.
Anta at du gjorde en endring i en fil, men du må jobbe med noen andre filer før du var klar til å begå endringer i det lokale depotet. I så fall ville du gjort det scene filen du er ferdig med å jobbe med. Dette vil forberede det på å være forpliktet til det lokale depotet.
Når du har gjort alle endringene og iscenesatt alle filene, forplikter du dem til det lokale depotet.
Innse at å begå de iscenesatte filene bare sender dem til det lokale depotet. Dette betyr at bare du har tilgang til endringene som er gjort. Prosessen med å sjekke inn de nye versjonene til det sentrale depotet kalles a trykk.
Velge Git-depotvert
For det første den gode nyheten: Mange organisasjoner tilbyr Git-hosting - i skrivende stund er det mer enn to dusin valg. Dette betyr at du har mange alternativer å velge mellom. Det er de gode nyhetene ... og de dårlige nyhetene.
Det er bare dårlige nyheter fordi det betyr at du virkelig trenger å bruke litt tid på å undersøke fordeler og ulemper med vertsorganisasjonene. For eksempel koster de fleste ikke for grunnleggende hosting, men tar betalt for store prosjekter. Noen har bare offentlige arkiver (alle kan se arkivet ditt), mens andre lar deg opprette private arkiver. Det er mange andre funksjoner å vurdere.
En funksjon som kan være høyt på listen din er et webgrensesnitt. Selv om du kan gjøre omtrent alle lagringsoperasjoner lokalt på systemet ditt, kan det være veldig nyttig å kunne utføre noen operasjoner via et webgrensesnitt. Utforsk grensesnittet som er gitt før du velger.
I det minste anbefaler jeg å vurdere følgende:
- //bitbucket.org
- //www.cloudforge.com
- //www.codebasehq.com
- //github.com
- //gitlab.com
Merk at jeg valgte Gitlab.com for eksemplene nedenfor. Noen av vertene i den forrige listen hadde fungert like bra; Jeg valgte Gitlab.com bare fordi det tilfeldigvis var den jeg brukte på mitt siste Git-prosjekt.
Konfigurerer Git
Nå som du har fått gjennom all teorien, er det på tide å faktisk gjøre noe med Git. Denne neste delen forutsetter følgende:
- Du har installert
gitellergit-allprogramvarepakke på systemet ditt. - Du har opprettet en konto på en Git-hostingtjeneste.
Det første du vil gjøre er å utføre noen grunnleggende oppsett. Hver gang du utfører en forpliktelse, vil navnet ditt og e-postadressen din være inkludert i metadataene. For å angi denne informasjonen, utfør følgende kommandoer:
ocs @ ubuntu: ~ $ git config - global bruker.navn "Bo Rothwell" ocs @ ubuntu: ~ $ git config - global user.email "[email protected]"
Åpenbart vil du erstatte "Bo Rothwell" med navnet ditt og "[email protected]" med e-postadressen din. Det neste trinnet er å klone prosjektet ditt fra Git-hostingtjenesten. Merk at før kloning er det bare én fil i brukerens hjemmekatalog:
ocs @ ubuntu: ~ $ ls first.sh
Følgende klonet et prosjekt med navnet ocs:
