jeg brukte mye tid på å tenke på om å skrive en på Git eller bare la det, siden det tar ganske mye tid på å forklare Git og det er funksjoner. Men likevel, jeg har gitt en detaljert fremgangsmåte på sikt av installasjon /bruk noen som ikke er dokumentert noe annet sted. Dette er for brukere som virkelig ønsker å lære det i dybden, rask og enkel. Sørg for å tømme dere fra begrepet andre verktøy som svn, cvs, etc .. Hvis du ikke er klar over slike verktøy, vel og bra .. La oss komme i gang.
Så, hva er Git? Anmeldelser Det er en forutsetning, hvis du ønsker å være en kjerne hacker
Fra Wikipedia:.
I programvareutvikling, Git
er et distribuert revisjonskontroll og kildekoden management (SCM) system med vekt på hastighet. Git ble opprinnelig designet og utviklet av Linus Torvalds for Linux-kjernen utvikling i 2005. Basert på en fersk undersøkelse av Eclipse IDE brukere, er Git rapportert å ha 30% adopsjon fra og med 2013.
I enkle ord, det er et verktøy for å kraftfullt administrere /organisere kildekoden til ethvert prosjekt.
Som du kanskje vet, er Linux kernel et prosjekt med så mange bidragsytere og dermed etterspørselen øker for et verktøy for å effektivt håndtere kildekoden til det, og dermed, Linus Torvalds bygge dette opp, etter å ha blitt lei opp med andre verktøy som svn, cvs etc ..
Det er en distribuert revisjonskontroll Hotell og kildekoden ledelse. Hva distribuert innebærer her?
Dette er hva som gjør Git awesome. Det er ingen sentral repo du har tilgang til å gjøre arbeidet. Du kan begå, gren og fest på din egen repo på din lokale maskin selv uten internettilgang. Deretter, når du har en tilkobling igjen, kan du presse dine endringer i noen annen git repo du har tilgang til.
Hvordan Git fungerer?
Se på dette selvforklarende diagram.
I Git, er alt lagres som et øyeblikksbilde. I tilfelle, hvis den aktuelle filen ikke gjennomgått noen endringer, så Git skaper bare en peker til å referere den forrige snapshot
i diagrammet over, etter Versjon 1 -. inneholder 3 filer. (Merk at filene kan være alt - Coding eller bare bare en "README" -fil)
Versjon 2 - A og C har gjennomgått endringer, mens B er akkurat det samme
Som nevnt tidligere, her, er nesten hver operasjon lokale.
Alt i Git er innsjekking summert før den er lagret, og blir deretter henvist til ved at sjekksummen. Den checksumming mekanisme som Git bruker er SHA-1 hash.
Lokale Operations
Følgende bilde viser hvordan det fungerer i din maskin. Senere alle disse endringene kan helt skyves til den eksterne repo. Legg merke til at, er her fjern repo hva alle har tilgang til. Og bortsett fra at alle har en lokal repo også, der de forplikter endringer, som er å bli presset til å fjern repo når de kobles til nettverket, eller bare når de vil.
Her er arbeidsmappen der Git butikker metadata (data om data. Detaljer om hva som er begått, og den versjonen av filen som er engasjert og slikt) og objekt database for prosjektet.
arbeidsflyten er som dette.
è Du modifisere noen filer
è Du iscenesette disse filene
è Du begå alle de iscenesatt endringer samtidig.
Installasjon
# yum install git-coreYou skal installere det ved hjelp av kildekode som godt og senere oppdatering ved å kjøre . git klone
Nå som du har installert Git, du skal klone fjern repo slik at du skal oppdatere Git lett & rask
# git -version /* For å sjekke den installerte versjonen av Git * /# git klone git. //git.kernel.org/pub/scm/git/git.git /* Du er kloning git prosjekt sammen * /
Dette vil skape en katalog som heter git i hjemmekatalogen.
# cd /root /git /
# git tag /* Dette vil liste opp alle versjoner av Git * /
# git checkout v1.8.4 /* Jeg ønsker å oppdatere til versjon 1.8.4 * /
# autoconf /* yum install autoconf, hvis kommandoen ikke funnet. Denne kommandoen er å generere konfigurere skript fra configure.ac * /
# ./configure -prefix = /usr; gjøre; make install
# git --versiongit versjon 1.8.4Now at du har installert Git og oppdatert det også, la oss gå med det første oppsettet
. Forsiktig: Fortsett videre som en vanlig bruker, bare i tilfelle, for å unngå risikoen for å rote ting opp
Første gang Git oppsett
Det er flere parametere som må settes
# git config --global user.name "Gokul Kannan" # git config.. - -Global user.email [email protected]# git config --global core.editor vim /* Standard redaktør som skal brukes i git ex: når du begår * /# git config --global merge.tool vimdiff /* Standard verktøy for å løse flette konflikter * /# git config --list /* for å sjekke config * /Dette skaper en .gitconfig i ditt hjemmeområde med parametrene som er satt. Merk at disse parameterne er spesifikke for denne brukeren alene. I tilfelle, hvis du ønsker å sette parametre for alle brukere av dette systemet, og deretter bruke -systemet istedenfor -Global. Dette vil skape en gitconfig fil under /usr /etc /
Tilgang hjelp
# git hjelp. ≪ verb > /* Ex: Bruk begår i stedet for verb, hvis du trenger hjelp til å begå * /# git < verb > --help # mann git- < verb > Får en git repository & arbeider
# mkdir myfirstproject # cd myfirstproject # pwd /root /myfirstproject # git init /* Dette vil initial git repository i /root/myfirstproject/.git/* /Kjenn forskjellen mellom arbeidsmappen og depotet. Her er mitt arbeidskatalog /root /myfirstproject Hotell og depotet er /root/myfirstproject/.git/.
Arbeide katalogen er der jeg holde mine filer og oppbevaringssted er der det blir spores.
Lifecycle av status av filene dine
Dette kan være litt forvirrende. Så, lese nøye. Ignorer den midtre delen av den ovenfor pic. Si, du har nettopp lagt til en fil. Nå er det i untracked scenen. La oss iscenesette /begå den. Nå, hva skjer? Untracked - > Iscenesatt - > Begått. "Umodifisert og modifisert" kommer inn i bildet når du gjør endringer i den engasjerte filen og ikke nå.
Her notat som forplikte pilen går rett til venstre. Hva betyr dette? Begår er noe annet enn å samle inn dine øyeblikksbilde (lagt /lagret filene i arbeids dir) til historien.
Nå, si at du endrer den ekstra fil. Nå kan du se hele bilde, sammen med den midterste delen.
Når du fjerner en fil, er prosessflyten samme. Si, har du fjernet en fil. Som nå, selv om du har fjernet det, endringer har ikke blitt begått enda. Så, for å begå det, trenger du å iscenesette fjerning, og deretter forplikte. Untracked - > Iscenesatt - > Engasjerte
Opptak forandringer til depotet
# vim READMEThis er en test project.Save og exit
Les alle utgangene # git status
nøye og du skal lære angre (unstaging /forkaste endringer etc ..) selv.
# git status /* Dette gir gjeldende status for prosjektet. Utgangen er selvforklarende * /
# På gren mester ## Initial begå ## Usporede filer: # (bruk "git legge < fil > ..." å ta med i hva som vil være forpliktet) ## READMEnothing lagt til forplikte men untracked filer til stede (bruk "git legge til" å spore) # På gren mester - Ikke bekymre deg for dette nå. Per nå har vi bare har én hovedgren dvs.) mester # Initial forplikte -. Per nå har vi ikke begår noe ennå # Usporede filer - Jeg har opprettet en ny fil, som ikke er iscenesatt ennå. Henvis Lifecycle av status av dine filer picStaging og begår
# git legge README /* Dette er å iscenesette filen "README" * /
# git status
# På gren mester ## Initial forplikte ## Endringer være begått: # (bruk "git rm --cached < fil > ..." for å unstage) ## nye filen: README #
Nå, som du har iscenesatt filen "README", kommer det under "Endringer skal begått".
# git commit -m "Min første begå" /* -m å nevne begå msg * /
en fil endret, en innsetting (+) skape modus 100644 README
# git status /* som vi ikke legge til /endre noe etter innlegging, arbeid dir ren nå * /
# På gren masternothing å begå, arbeidsmappen cleanNote at du kan hoppe klargjøringsområdet ved å gi -a alternativ til git commit
kommando
Ser forplikte historie
# git log /* viser forplikte gjort i depotet * /
begå bfae2f77c96615d46035602d87a84d755ad62e5d
Forfatter: Gokul Kannan < [email protected]> Date: Sun 29 september 06:22:36 2013 + 0530My første forplikte
Sifrene etter forplikte er sjekksum. Som nevnt tidligere, er alt i Git innsjekking summert før den er lagret, og blir deretter henvist til ved at sjekksummen.
Staging endrede filer
Nå kan endre README og også legge til en annen fil.
# vim README
Dette er en test project.Testing furtherSave og exit
# berørings prøven
# git status
# På gren Master # Endringer ikke iscenesatt for innsending:. # (bruk "git Legg til < fil > ... "for å oppdatere hva som vil være forpliktet) # (bruk" git checkout - < fil > ... "for å forkaste endringer i arbeidsmappen) ## modifiserte: README ## Usporede filer: # (bruk "git legge < fil > ..." å ta med i hva som vil være forpliktet) ## sampleno endringer legges forplikte (bruk "git legge til" og /eller "git commit a") Merk at README spores , men de siste endringene ikke er iscenesatt. . Mens prøven ikke engang spores
Du kan forkaste endringene du mjød til README ved å kjøre kommandoen # git checkout - README (se ovenfor utgang Les andre utganger nøye.)
# git legge til. /* Spor /scene alt vedlike dir * /
# git status
# På avdelings Master # Endringer være begått: # (bruk "reset git HEAD < fil > ... "til unstage) ## endret: README # ny fil: sample #
# git commit /* dette vil åpne en fil, hvor du kan skrive inn din begå meldingen og lagre den til å begå * /
Redaktøren der filen vil bli åpnet er redaktør du nevnte innledningsvis mens du konfigurerer # Oppgi forplikte meldingen for endringene. Linjer som starter # med '#' vil bli ignorert, og en tom melding avbryter begå # På gren Master # Endringer være begått. # (Bruk "git reset HEAD ^ 1 < fil > ..." for å unstage) # # endret: README # ny fil: sample # Lagt noen linjer til Viktig-fil og lagt til en ny fil "sample" ~~~~~~~~ ".git /COMMIT_EDITMSG" 11L, 310CSave og exit
. # git log
begå 4a966bbdf759dda15bf3ae524ca95e8d3a523062Author: Gokul Kannan < [email protected]> Dato: Søn Sep 29 06:36:40 2013 +0530 lagt noen linjer til Viktig-fil og lagt til en ny fil "sample" forplikte bfae2f77c96615d46035602d87a84d755ad62e5dAuthor : Gokul Kannan < [email protected]> Date: Sun 29 september 06:22:36 2013 0530 Min første forplikte
# git logge -p
begå 4a966bbdf759dda15bf3ae524ca95e8d3a523062 Forfatter: Gokul Kannan < gokul. [email protected]> Dato: Sun 29 september 06:36:40 2 013 + 0530Added noen linjer til Viktig-fil og lagt til en ny fil "sample"
diff --git a /README b /README index 3ac131b..1494579 100644 -. - a /README +++ b /README@@-1 +1,3@@Dette er et prøveprosjekt. + Testing videre. + Diff --git a /sample b /sample ny fil modus 100 644 indeksen 0000000..e69de29commit bfae2f77c96615d46035602d87a84d755ad62e5d Forfatter: Gokul Kannan < [email protected]> Date: Sun 29 september 06:22:36 2 013 0530 Min første forplikte
# git log --pretty = oneline
ea54cffd13d09ea75f96308ddf02d38a7149914b Lagt noen linjer til Viktig-filen og Adde bfae2f77c96615d46035602d87a84d755ad62e5d Min første commitThere finnes flere andre alternativer som kan være brukes sammen med git log (se #man git-log
).
Du kan bruke # git commit -amend hvis du ønsker å endre forrige begå meldingen.
Fra utgangen av tidligere # git status , etter at du kan være oppmerksom på angre visse ting.
Ignorerer filer
Nå, når du bygger din kode (her har jeg bare brukt tekstfiler som README /prøven og ingen koder),. o eller .en - objekt Hotell og arkiv
filer kan være et produkt av å bygge koden din. Nå er det et behov for å se bort fra disse filer (biprodukt), og for å bevare koden alene. Hvis du ikke ignorere disse filene, vil # git status gå på notering disse filene som untracked.
# vi .gitignore
*. [OA] Lagre og avslutte.
Du må iscenesette /begå denne filen, slik at, fremover, skal du ignorere .o og .a filer.
# git legge .gitignore # git commit -m "" Lagt til en .gitignore filer å ignorere .o og. en filer "Nå, etter
# vi test.o
Dette er et testobjekt FilLagre og avslutte.
# git status
# På gren mester ingenting å begå, arbeidsmappen cleanNow, som du kan se, har git ignorert test.o, siden vi har begått en .gitignore fil, hvor vi har bedt om å ignorere .o og .a filer. Når du ønsker å ignorere noen type filer, redigere den samme .gitignore og begår den.
Vise iscenesatt og unstaged endringer
Noen ganger vil du vite nøyaktig hva du endret, ikke bare hvilke filer som ble endret. For å sjekke filer som ble endret, kan du bruke # git status kommando . Men for å vite nøyaktig hva du har forandret seg, bruk # git diff kommandoen.
For å være presis, etter # git diff /* for å vise unstaged endringer. Dette sammenarbeidskatalogen og oppstallingsplass * /
# git diff --cached /* for å vise iscenesatt endringer. Dette sammen din klargjøringsområdet og tidligere har begått. * /Nå gjøre dette selv. Lag 2 filer. Stage bare en fil alene (# git legge filnavn å iscenesette den) og løpe # git diff og # git diff -cached og du kunne se at kommandoer fungerer slik jeg nevnte ovenfor.
Fjerne og flytte filer
si: for eksempel, du ønsker å fjerne filen prøven.
# git rm prøven /* for å legge til filene vi brukte git legge til, her for å fjerne, derav rm. Dette sletter filen prøven og også iscenesetter fil fjerning for å begå. Du trenger ikke kjøre en # rm prøve separat * /
# git commit -m "slettet eksempelfilen" Nå har du fjernet den "sample" filen fra arbeidsmappen.
Tilsvarende for å endre navn på filer, bruk mv i stedet for rm.
Bruke GUI til å visualisere historien
Hvis du liker å bruke et grafisk verktøy for visning din begå historie, kan du bruke gitk kommandoen. Det er i utgangspunktet en visuell git log verktøy, og det aksepterer nesten alle filtreringsalternativene som git log godtar.
Skal diskutere videre på Git /Remote Git /Tagging /Forgrening /Public Git server (som github) i min neste artikkel. Følg med.
Takk for lesing. Cheers!
Git (Distributed Version Control System) - Detaljert, Men Simpler
Previous:CentOS 6.5 er offisielt lansert!