Her er alle Git-kommandoene jeg brukte forrige uke, og hva de gjør.

Bildekreditt: GitHub Octodex

Som de fleste nybegynnere, begynte jeg å søke StackOverflow etter Git-kommandoer og deretter kopiere og lime inn svar, uten å virkelig forstå hva de gjorde.

Bildekreditt: XKCD

Jeg husker at jeg tenkte: "Ville det ikke være fint hvis det var en liste over de vanligste Git-kommandoene sammen med en forklaring på hvorfor de er nyttige?"

Vel, her er jeg år senere for å sette sammen en slik liste, og legge ut noen beste fremgangsmåter som til og med middels avanserte utviklere bør finne nyttige.

For å holde ting praktisk, baserer jeg denne listen over de faktiske Git-kommandoene jeg brukte den siste uken.

Nesten alle utviklere bruker Git, og mest sannsynlig GitHub. Men den gjennomsnittlige utvikleren bruker sannsynligvis bare disse tre kommandoene 99% av tiden:

git add - alt
git commit -am ""
git push origin master

Det er vel og bra når du jobber med et enmannsteam, en hackathon eller en kast-app, men når stabilitet og vedlikehold begynner å bli en prioritet, rydder du opp, holder deg til en forgreningsstrategi og skriver sammenhengende forpliktelsesmeldinger blir viktig.

Jeg begynner med listen over ofte brukte kommandoer for å gjøre det enklere for nybegynnere å forstå hva som er mulig med Git, for så å gå videre til den mer avanserte funksjonaliteten og beste praksis.

Vanligvis brukte kommandoer

For å initialisere Git i et repository (repo), trenger du bare å skrive inn følgende kommando. Hvis du ikke initialiserer Git, kan du ikke kjøre noen andre Git-kommandoer i den repoen.

git init

Hvis du bruker GitHub og skyver kode til en GitHub-repo som er lagret på nettet, bruker du en ekstern repo. Standardnavnet (også kjent som et alias) for den eksterne repoen er opprinnelse. Hvis du har kopiert et prosjekt fra Github, har det allerede opphav. Du kan se den opprinnelsen med kommandoen git remote -v, som viser URLen til den eksterne repoen.

Hvis du initialiserte din egen Git-repo og vil knytte den til en GitHub-repo, må du opprette en på GitHub, kopiere URLen som følger med og bruke kommandoen git remote add origin , med nettadressen gitt av GitHub erstatter “”. Derfra kan du legge til, forplikte og skyve til din eksterne repo.

Den siste brukes når du trenger å endre det eksterne depotet. La oss si at du kopierte en repo fra noen andre og vil endre det eksterne depotet fra den opprinnelige eierens til din egen GitHub-konto. Følg den samme prosessen som git remote add origin, bortsett fra bruk set-url i stedet for å endre ekstern repo.

git remote -v
git remote legge til opprinnelse 
git ekstern sett-url-opprinnelse 

Den vanligste måten å kopiere en repo er å bruke git-klon, etterfulgt av repo-URLen.

Husk at det eksterne depotet vil være koblet til kontoen du klonet fra repoen fra. Så hvis du klonet en repo som tilhører noen andre, vil du ikke kunne skyve til GitHub før du endrer opprinnelse ved å bruke kommandoene ovenfor.

git klon 

Du finner deg raskt ved å bruke grener. Hvis du ikke forstår hva grener er, er det andre opplæringsprogrammer som er mye mer dyptgående, og du bør lese dem før du fortsetter (her er en).

Kommandogitgrenen lister opp alle grener på din lokale maskin. Hvis du vil opprette en ny gren, kan du bruke git branch , med som representerer navnet på grenen, for eksempel "master".

Git-kassen -kommandoen bytter til en eksisterende gren. Du kan også bruke git checkout -b -kommandoen til å opprette en ny gren og umiddelbart bytte til den. De fleste bruker dette i stedet for separate kommandoer for avdeling og kasse.

git gren
git branch 
git kassa 
git checkout -b 

Hvis du har gjort en mengde endringer i en gren, la oss kalle den "utvikle", og du vil slå den grenen tilbake til hovedgrenen din, bruker du kommandoen git merge . Du vil sjekke mestergrenen, og deretter kjøre git merge ontwikkel for å slå sammen utvikle seg til hovedgrenen.

git merge 

Hvis du jobber med flere personer, finner du deg selv i en posisjon der en repo ble oppdatert på GitHub, men du har ikke endringene lokalt. Hvis det er tilfelle, kan du bruke git pull origin for å trekke de siste endringene fra den eksterne grenen.

git pull opprinnelse 

Hvis du er nysgjerrig på å se hvilke filer som er endret og hva som blir sporet, kan du bruke git-status. Hvis du vil se hvor mye hver fil er endret, kan du bruke git diff for å se antall linjer som er endret i hver fil.

git status
git diff - statisk

Avanserte kommandoer og beste praksis

Snart kommer du til et punkt der du vil at forpliktelsene dine skal se fine ut og være konsekvente. Du kan også være nødt til å fikle med forpliktelseshistorikken din for å gjøre forpliktelsene dine lettere å forstå eller for å komme tilbake en utilsiktet brytende endring.

Git-logg-kommandoen lar deg se engasjementshistorikken. Du vil bruke dette til å se historien til forpliktelsene dine.

Forpliktelsene dine kommer med meldinger og en hasj, som er tilfeldig serie med tall og bokstaver. Et eksempel hash kan se slik ut: c3d882aa1aa4e3d5f18b3890132670fbeac912f7

git logg

La oss si at du presset noe som brøt appen din. I stedet for å fikse det og skyve på noe nytt, vil du heller bare gå tilbake på en forpliktelse og prøve igjen.

Hvis du vil gå tilbake i tid og sjekke appen din fra en tidligere forpliktelse, kan du gjøre dette direkte ved å bruke hasj som grenavn. Dette vil fjerne appen din fra den gjeldende versjonen (fordi du redigerer en historisk post, i stedet for den nåværende versjonen).

git kassa c3d88eaa1aa4e4d5f

Hvis du gjør endringer fra den historiske grenen og vil skyve igjen, må du gjøre et kraftpress.

Forsiktig: Kraftpressing er farlig og bør bare gjøres hvis du absolutt må. Den vil overskrive historikken til appen din, og du vil miste det som kom etter.

git push -f opprinnelsesmester

Andre ganger er det bare ikke praktisk å holde alt i ett. Kanskje du vil redde fremgangen din før du prøvde noe potensielt risikabelt, eller kanskje du gjorde en feil og vil skåne deg flauheten over å ha en feil i versjonshistorien. For det har vi git rebase.

La oss si at du har 4 forpliktelser i din lokale historie (ikke presset til GitHub) der du har gått frem og tilbake. Forpliktelsene dine ser slurvete og ubesluttsomme. Du kan bruke rebase til å kombinere alle disse forpliktelsene til en enkelt, kortfattet forpliktelse.

git rebase -i HEAD ~ 4

Kommandoen ovenfor vil åpne datamaskinens standardredigerer (som er Vim med mindre du har satt den til noe annet), med flere alternativer for hvordan du kan endre forpliktelsene dine. Det vil se ut som koden nedenfor:

velg 130deo9 eldste forpliktelsesmelding
velg 4209fei nest eldste engasjementsmelding
velg 4390gne tredje eldste engasjementsmelding
velg bmo0dne nyeste engasjementmelding

For å kombinere disse, må vi endre “velg” -alternativet til “fiksering” (som dokumentasjonen under koden sier) for å melde forpliktelsene og forkaste engasjementsmeldingene. Merk at i vim må du trykke “a” eller “i” for å kunne redigere teksten, og for å lagre og avslutte, må du skrive flukt-tasten etterfulgt av “shift + z + z”. Ikke spør meg hvorfor, det er bare det.

velg 130deo9 eldste forpliktelsesmelding
fixup 4209fei nest eldste engasjementsmelding
fixup 4390gne tredje eldste engasjementsmelding
fixup bmo0dne nyeste engasjementmelding

Dette vil slå sammen alle forpliktelsene dine til forpliktelsen med meldingen "eldste forpliktelsesmelding".

Neste trinn er å gi nytt navn til din engasjementsmelding. Dette er helt og holdent et spørsmål om mening, men så lenge du følger et konsistent mønster, er alt du gjør greit. Jeg anbefaler å bruke forpliktelsesretningslinjene gitt av Google for Angular.js.

Bruk endringsflagget for å endre engasjementsmeldingen.

git commit - endrer

Dette vil også åpne vim, og regler for tekstredigering og lagring er de samme som ovenfor. Følg reglene fra retningslinjen for å gi et eksempel på en god forpliktelsesmelding:

bragd: legg til stripe checkout-knappen på betalingssiden
- legg til stripe checkout-knapp
- skrive tester for kassa

En fordel med å følge de typene som er oppført i retningslinjen er at det letter skrivingsendringslogger. Du kan også inkludere informasjon i bunnteksten (igjen, spesifisert i retningslinjen) som refererer til problemer.

Merk: Du bør unngå å flasse opp og skvise forpliktelsene dine hvis du samarbeider om et prosjekt, og har kode presset til GitHub. Hvis du begynner å endre versjonshistorikk under folks nese, kan du ende opp med å gjøre alles liv vanskeligere med feil som er vanskelige å spore.

Det er et nesten uendelig antall mulige kommandoer med Git, men disse kommandoene er sannsynligvis de eneste du trenger å kjenne de første årene av programmering.

Sam Corcos er hovedutvikler og medgründer av Sightline Maps, den mest intuitive plattformen for 3D-utskrift av topografiske kart, samt LearnPh Phoenix.io, et mellomavansert veiledningsside for å bygge skalerbare produksjonsapper med Phoenix og React.