Share
Har du noen gang jobbet med et prosjekt som var så uhåndterlig, var du redd for å oppdatere en fil eller legge til en funksjon? Kanskje problemet var at du ikke brukte et versjonskontrollsystem. I dagens veiledning lærer vi grunnleggende om hva som muligens kan være den beste VCS i verden: Git.
Git er et open source kode managemen verktøy; Det ble opprettet av Linus Torvalds da han bygde Linux-kjernen. På grunn av disse røttene måtte det være veldig fort; at det er, og lett å få tak i også. Git gjør det mulig for deg å jobbe med koden din med fred i at alt du gjør er reversible. Det gjør det enkelt å eksperimentere med nye ideer i et prosjekt og ikke bekymre deg for å bryte noe. Git Parable, av Tom Preston-Werner, er en god introduksjon til vilkårene og ideene bak Git.
Du bør definitivt bruke et revisjonskontrollsystem; Som vi allerede har sagt, gir dette deg friheten til å gjøre hva du vil med koden din og ikke bekymre deg for å bryte den. Så hvis du har innsett fordelene ved å bruke et revisjonskontrollsystem, hvorfor skal du bruke git? Hvorfor ikke SVN eller Perforce eller en annen? For å være ærlig har jeg ikke studert forskjellene for nært; sjekk ut WhyGitIsBetterThanX.com for litt nyttig info.
Git er ganske enkelt å få: på en Mac er det sannsynligvis enklest å bruke git-osx-installatøren. Hvis du har MacPorts installert, vil du kanskje få Git gjennom det; Du finner instruksjoner på GitHubs hjelpeside. (Og ja, vi snakker om GitHub). På Windows, er den enkleste måten å begynne å rulle å bruke msysgit installasjonsprogrammet. Men hvis du har Cygwin, kan du også gi Git gjennom det.
Nå skal du ha Git installert; hvis du er på en Mac, åpne en terminal; Hvis du er på Windows, åpner du Git Bash (fra msysgit) eller Cygwin-ledeteksten. Herfra bør det ikke være noen OS forskjeller.
Vi starter med å gjøre litt konfigurasjon. Hver forplikte deg til å gjøre, vil ha ditt navn og din e-postadresse for å identifisere «eier» av forplikten, så du bør begynne med å gi de disse verdiene. For å gjøre det, kjør disse kommandoene:
git config --global user.name "Ditt navn" git config --global user.email "[email protected]"
Det er også hyggelig å aktivere litt tekstfarging, bare for lettere lesing i terminalen.
git config - global color.diff auto git config - global color.status auto git config - global color.branch auto
Nå som Git vet hvem du er, la oss forestille oss at vi lager en enkel PHP webapp. (Selvfølgelig, jo større er prosjektet, lysere Git skinner, men vi lærer bare verktøyene, ikke sant?) Vi har en tom katalog kalt 'mySite'. Første fokus på den katalogen (ved hjelp av cd-kommandoen). For å komme i gang med Git, må du kjøre kommandoen git init; som du kanskje gjetter, initialiserer dette et Git-lager i den mappen, og legger til en .git-mappe i den. Et depot er litt som en kodehistoriebok. Den vil holde alle tidligere versjoner av koden din, så vel som den nåværende.
Legg merke til at din terminalbane er vedlagt (master). Det er filialen du jobber for. Gren? Tenk på prosjektet ditt som et tre; Du kan opprette forskjellige funksjoner på forskjellige grener, og alt vil være skilt og sikkert.
Vi har begynt å jobbe med vår søknad.
Før vi går videre, bør vi gjøre vår første forpliktelse. En forpliktelse er rett og slett en pointer til et sted på kodehistorikken din. Før vi kan gjøre det, må vi imidlertid flytte alle filer vi ønsker å være en del av denne forpliktelsen til staging-området. Staging-området er et sted å holde filer for ditt neste engasjement; kanskje du ikke vil forpligte alle dine nåværende endringer, så du legger litt i staging-området. Vi kan gjøre det ved å bruke add-kommandoen
git add .
Den. betyr ganske enkelt å legge til alt. Du kan være mer spesifikk hvis du vil.
git legg til * .js git legg til index.php
Nå som vi har satt opp våre filer, la oss begå dem. Dette gjøres med kommandoen
git commit
Dette tar alle filene i vårt staging-område og merker som koden som et punkt i prosjektets historie. Hvis du ikke legger til noen alternativer til kommandoen ovenfor, får du noe slikt.
Hver forpliktelse skal ha en medfølgende melding, så du vet hvorfor denne koden var forpliktet. Denne redaktøren lar deg skrive meldingen din, samt se hva som er i denne forpliktelsen. Fra bildet over kan du se at dette commitet består av fire nye filer. Redaktøren du bruker til å skrive meldingen, er Vim; Hvis du ikke er kjent med vim, vet du at du må trykke på jeg (for Sett inn) før du kan skrive inn meldingen. I bildet ovenfor har jeg lagt til meldingen "Initial Commit." Når du har skrevet meldingen, treffer du flukt og skriver inn: wq (for å lagre og avslutte). Du ser da at du er forpliktet til å finne sted.
Du kan bruke noen få muligheter til å gjøre forpliktelser raskere. For det første, -m lar deg legge til meldingen din i tråd.
git commit -m "initial commit"
Deretter kan du hoppe over oppsamlingsområdet; Vel, egentlig ikke. Git vil automatisk arrangere og begå alle endrede filer når du bruker dette alternativet. (Husk, det vil ikke legge til noen nye filer). Sammen kan du bruke disse kommandoene slik:
git commit -am 'oppdatering til index.php'
Så hvordan forteller Git seg fra hverandre? I stedet for å nummerere dem, bruker Git kodenes innhold i commit for å lage en SHA1-hash på 40 tegn. Den ryddige delen om dette er at siden det bruker koden for å lage hasen, vil ingen to hashes i prosjektet være den samme uten at koden i forbudene er identisk.
De git status kommandoen lar deg se den nåværende tilstanden til koden din. Vi har nettopp gjort en forpliktelse, så git status vil vise oss at det ikke er noe nytt.
Hvis vi fortsetter å jobbe med vårt imaginære prosjekt, vil du se at vår status endres. Jeg skal redigere vår index.php og legge til en annen fil. Nå, kjører git status gir oss dette:
Oppdateringen er delt inn i to kategorier: "Endret, men ikke oppdatert" og "Usporte filer." Hvis vi kjører
git add userAuthentication.php git status
Du vil se at vi nå har en "endringer å være forpliktet" -delen. Dette lister opp filer lagt til staging-området. Jeg skal forplikte disse endringene med dette:
git commit -am 'brukerautentiseringskode lagt til'
Nå kjører git status viser oss en ren arbeidskatalog.
Her er et scenario: Vi jobber lykkelig med vårt prosjekt når vi plutselig har en grand ide. Denne ideen er så revolusjonerende, det vil forandre prosjektet drastisk. Vi må prøve, men vi ønsker ikke å kaste denne usikre, første utkastskoden med vår testede og sanne kode. Hva å gjøre? Dette er hvor git grenen vil være utrolig nyttig. La oss forgrene vårt prosjekt slik at hvis vår store ide ikke trener, er det ingen skade gjort.
git grenen
Bare kjører grenkommandoen sans Alternativer vil liste våre grener; akkurat nå har vi bare master-grenen, som er hva noen git-repository starter med. For å faktisk opprette en ny filial, legg til navnet på den nye grenen etter kommandoen.
git grenen bigIdea
Når du oppretter en ny avdeling, blir du ikke automatisk skiftet til den. Legg merke til at terminalen vår fortsatt sier (master). Det er her vi bruker grener kamerat kommando git kassen.
git kassen bigIdea
(Tips: Du kan opprette en filial og bytte til den i ett fall med denne kommandoen: git checkout -b filnavn.) Som du kan se, er vi nå på bigIdea-avdelingen. La oss kode opp en storm. Git status vil vise vårt arbeid.
La oss begå våre endringer:
git add. git commit -m 'The Kiler Feature lagt til'
Ok, nok av denne funksjonen for nå; la oss gå tilbake til vår hovedgren men før vi gjør det, vil jeg vise deg vår nåværende prosjektmappe.
Bytt nå tilbake til hovedgrenen; du vet hvordan:git checkout mester. Se på prosjektmappen vår igjen.
Nei, jeg gjorde ikke noe; disse to filene er bare en del av bigIdea-avdelingen, så vi vet ikke engang at de eksisterer fra hovedgrenen. Dette fungerer ikke bare for komplette filer, men også for selv de minste endringene i filene.
Ok, så vi har jobbet hardt på den store filialen på fritiden vår. Faktisk, etter en annen forpliktelse, ser det så søtt ut at vi har bestemt at det er bra nok til å bli med i hovedgrenen. Så hvordan gjør vi det?
De git fusjon kommandoen er laget for akkurat dette formålet. Mens du er på hovedgrenen, gi dette et forsøk:
git flette bigIdea
Det er så enkelt; Nå er alt på storia-avdelingen en del av hovedgrenen. Du kan bli kvitt bigIdea-avdelingen nå, hvis du vil.
Git grenen -d bigIdea
Jeg bør nevne at hvis du ikke har slått sammen en filial, vil Git ikke la deg slette den med denne kommandoen; du må bruke en stor bokstav D i alternativet. Dette er bare et sikkerhetsmål.
Du vil nok se på din forlovelseshistorikk på et tidspunkt under prosjektet ditt. Dette kan enkelt gjøres med loggkommandoen.
git logg
Dette vil utgjøre en liste over alle forpliktelsene du har gjort i et prosjekt, og viser dem i omvendt rekkefølge. Du kan få på ganske ryddig del av info her:
Definitivt informativ, men ganske tørr, nei? Vi kan lyse ting litt med grafalternativet.
git logg - graf
Nå kan vi se trestrukturen, slags. Selv om vi ikke får navnene sine, kan vi se hver av grenene og hvilke forpliktelser som ble gjort på dem. Hvis du er vant til å jobbe i en terminal, kan det hende du har det bra. Men hvis (tidligere til denne erfaringen) ordet terminal slår deg først som noe dødelig, puster lett: det er en app for det. Prøv dette:
gitk --all
Dette er den grafiske repository-nettleseren. Du kan bla gjennom dine forpliktelser, se nøyaktig hva som ble endret i hver fil under en forlovelse, og så mye mer. (Du vil legge merke til at jeg har lagt til noen få tilsagn før fusjonering, bare for å gjøre trestrukturen mer gjenkjennelig.)
Nå som du har en fornuftig kunnskap om Git under beltet, kan vi se på noen av Gits samarbeidspartnere. Git er en fin måte å dele kode med andre og jobbe sammen med prosjekter. Det finnes en rekke Git repository hosting nettsteder. Vi ser bare på en: GitHub.
Gå over til GitHub registreringsside og opprett en konto. Du trenger en SSH-nøkkel, så la oss lage det akkurat nå! (Merk: du trenger ikke nøkkelen mens du logger på, du kan legge den til senere.)
Åpne opp din terminal og skriv inn dette:
ssh-keygen -t rsa -C "[email protected]"
T-alternativet tilordner en type, og C-alternativet legger til en kommentar, tradisjonelt e-postadressen din. Deretter blir du spurt hvor du skal lagre nøkkelen; bare treffer enter vil gjøre (som lagrer filen til standardplasseringen). Skriv deretter inn en passord, to ganger. Nå har du en nøkkel; la oss gi den til GitHub.
Først får du nøkkelen fra filen; terminalen vil ha fortalt deg hvor nøkkelen ble lagret; åpne filen, kopier nøkkelen (vær forsiktig så du ikke legger til nye linjer eller hvite mellomrom). Åpne din GitHub-kontoside, bla til SSH Public Keys, og klikk "Legg til en annen offentlig nøkkel." Lim inn i nøkkelen og lagre den. Du er god å gå! Du kan teste din godkjenning ved å kjøre dette:
ssh [email protected]
Du blir bedt om passordet ditt. For å unngå å måtte skrive dette hver gang du kobler til GitHub, kan du automatisere dette. Jeg kunne fortelle deg hvordan du gjør dette, men jeg vil sannsynligvis plutiere ved et uhell: GitHub Hjelp har en vanlig engelsk artikkel om hvordan du gjør det.
Så nå er du satt opp med GitHub; la oss ta et prosjekt. Hva med jQuery? Hvis du går til jQuery GitHub-prosjektet, finner du URL-adressen til git-klonen. Kjør dette:
git klone git: //github.com/jquery/jquery.git
Dette lager en jquery-mappe og kopierer hele jquery-depotet til datamaskinen. Nå har du en komplett historie om prosjektet; sjekk den ut med gitk -all.
Så la oss si at du har jobbet med et prosjekt, administrerer det med git lokalt. Nå vil du dele den med en venn, eller verden. Logg inn på GitHub og opprett et nytt lager. GitHub vil gi deg en offentlig klonadresse (for andre som ønsker å laste ned prosjektet) og en personlig klonadresse (for deg selv).
Så kom tilbake til prosjektet ditt i terminalen og gi dette en virvel:
git remote add opprinnelse [email protected]: andrew8088 / Shazam.git
En fjernkontroll er et prosjektregister i en ekstern plassering. I dette tilfellet gir vi denne fjernkontrollen et opprinnelsesnavn og leverer det til vår private klonadresse. (Selvfølgelig må du erstatte nettadressen din for din egen.) Nå som prosjektet vet hvor det skal gå ...
git push origin master
Dette skyver hovedgrenen til opprinnelses fjernkontrollen. Nå er ditt prosjekt tilgjengelig for verden! Gå tilbake til prosjektsiden din og se prosjektet ditt.
Du kan være på den andre enden av et prosjekt: du er en bidragsyter i stedet for eieren. Når eieren skyver et nytt forpliktelse til depotet, kan du bruke det git pull for å få oppdateringene. Git pull er faktisk et kombinationsverktøy: det kjører git hente (får endringene) og git fusjon (slå sammen dem med din nåværende kopi).
git pull
Vel, det er så mye mer du kan lære om Git; forhåpentligvis har du lært nok kommandoer for å hjelpe deg med å administrere ditt neste prosjekt mer smart. Men stopp ikke her; sjekk ut disse ressursene for å bli en Git-mester!
Accentsconagua