Avanserte Git-arbeidsflyter & Bruk

Nylig så vi på det grunnleggende for å komme i gang med å bruke Git for kildekontroll i prosjektene dine. Selv om det er et flott utgangspunkt, er det en haug med andre kommandoer og Git-arbeidsflyter som vil hjelpe deg med å bruke Git i ditt daglige kodingsarbeid.

Git arbeidsflyter

Da jeg begynte å bruke Git, skjønte jeg at jeg visste hvordan jeg skulle bruke det riktig. Min ideelle tilnærming var å gjøre alle endringer på ett sted uten forgreninger og deretter forplikte dem til depotet og fortsette å jobbe.

Selv om det var bedre enn å ikke bruke versjonskontroll, tok det meg en stund å innse at jeg ikke brukte mesteparten av kraften som Git ga. For å få Git til å jobbe for meg, trengte jeg å ha en strategi for å forgrene og slå sammen endringene mine.

Så kom git-flow ut og jeg adopterte det som min strategi. Jeg husker fortsatt følelsen av at jeg kikket bak en gardin til hvor de fantastiske utviklerne var. Jeg hadde nå innsikt i hvordan de fungerte og kunne begynne å bli en av dem.

Men git-flow passer ikke til alle scenarier, så mens vi skal se på det vil vi også ta en titt på noen andre metoder for å holde Git-prosjektene dine organisert, inkludert hvordan jeg administrerer prosjektene mine som en ensom utvikler.

git-flow

Når jeg ser på git-flow nå, erkjenner jeg at programvarelandskapet har endret seg mye på 10 år, og git-flow er kanskje ikke det beste alternativet for teamet ditt. Når git-flow ble skrevet, var det sjelden å distribuere en applikasjon mange ganger på en dag. I stedet har du sannsynligvis laget et stort versjonsnummer og gitt ut med noen måneders eller ukers mellomrom hvis du var på et spesielt smidig team.

La oss ta en titt på hva git-flow er.

I git-flow har to grener en uendelig levetid. Først, hoved som skal gjenspeile kode som er klar til å distribueres til live/produksjonsmiljøet ditt.

Å lese:  Hvordan bruke automatisering av sosiale medier for å redusere markedsføringsinnsatsen på 6 områder

For det andre har vi vår utviklingsgren. Denne grenen skal ha de siste endringene som er klare for neste versjon av programvaren vår. Når endringene i utvikling er klare til å distribueres til live-applikasjonen vår, slår vi dem sammen i hovedgrenen og merker dem med versjonsnummeret som tilsvarer utgivelsesnummeret.

Utenfor de to hovedgrenene er det tre typer støttegrener.

1. Funksjon

En funksjonsgren kan kun lages fra utviklingsgrenen. Den må slås sammen tilbake til utviklingsgrenen. Navngivning kan være hva som helst beskrivende for funksjonen du jobber med.

Når verket er klart for neste utgivelse, blir det slått sammen tilbake til utviklingsgrenen hvor det venter på utgivelsestidspunkt.

2. Slipp

Frigjøringsgrener lages fra utviklegrenen og må smelte tilbake til både utvikle og hoved. Du navngir en utgivelsesgren med release-x-konvensjonen. I praksis betyr det vanligvis at du navngir en filial med utgivelsesnummeret du planlegger å bruke slik: release-2.2

Du bruker en utgivelsesgren som en måte å gjøre den siste forberedelsen for å frigi programvaren din. Dette kan inkludere å bumpe versjonsnummeret til filene, sørge for at oversettelsene dine er ferdige, eller endelige kodesjekker.

3. Hurtigreparasjon

Hurtigreparasjonsgrenen er laget fra hovedgrenen og brukes til å inneholde endringer som må håndteres i live-applikasjonen med en gang. Dette kan være en feil som må fikses eller et sikkerhetsproblem som må håndteres.

Når problemet er løst og distribuert til hovedavdelingen din, vil du merke koden med riktig versjonsnummer.

Den største grunnen til at team ikke bruker git-flow nå, er at måten vi slipper programvare på har endret seg. I stedet for større utgivelser sjeldnere, kan du frigi en endring i en applikasjon et par ganger på en dag. Jeg vet at jeg skyver arbeid til kundens nettsteder mange ganger i uken så snart det er klart. Vi lager ikke versjonsnumre av nettstedet, vi fortsetter å forbedre det.

Standard git-flow er ikke ment å imøtekomme dette.

Github Flow

Det andre alternativet som mange bruker er Github Flow.

Den eneste store regelen for Github Flow er at uansett hvilken kode som er på hovedgrenen kan distribueres når som helst fordi den er produksjonsklar.

Alle grener er laget av hovedgrenen med et beskrivende navn for det du gjør.

Når du har gjort endringene klare, oppretter du en pull forespørsel.

Når du har sendt inn en pull-forespørsel, kan teamet du jobber med gjennomgå endringene og gi tilbakemelding. Hvis pull-forespørselen anses som klar til å slå seg sammen, blir den slått sammen til hovedgrenen for prosjektet ditt.

Å lese:  Slik gjør du nettstedet ditt sikkert i 2024

En ulempe med Github-flyten for en enkelt utvikler eller veldig lite team er at administrasjonen av en pull-forespørsel kan skape ekstra overhead i administrasjonen av prosjektet. Dette er grunnen til at jeg ikke bruker dem i arbeidet mitt.

Hvordan jeg bruker Git Workflows med klientprosjekter

I mitt klientarbeid er jeg vanligvis den eneste som skriver kode daglig for et prosjekt. Min klient kan oppdatere WordPress-plugins eller endre noen CSS, men de gjør ikke noe stort kodingsarbeid. Det betyr at hvis jeg gikk med Github-flyt, ville jeg gjennomgått pull-forespørslene mine som bare skaper ekstra ledelseshodepine. La oss se på systemet jeg bruker, som har en viss likhet med både git-flow og Github flow.

Jeg har to hovedgrener som heter hoved og iscenesettelse. Hovedgrenen sporer med hvilken kode som for øyeblikket kjører på produksjonsstedet. Staging-grenen sporer med det som blir testet på stasjonsstedet vi bruker til å teste endringer før vi skyver dem til live-siden.

Hver gren er opprettet fra hovedgrenen. Nye funksjoner får et navn som dette: feature/32-new-feature. I denne sammenheng tilsvarer tallet 32 ​​billettnummeret i vårt prosjektstyringssystem og ordene etter er en kort beskrivelse av det som jobbes med. Feilrettinger får samme navn, bug/20-bug-name.

Hver gren som opprettes, blir først slått sammen med vår avdelingsgren, og deretter når den er godkjent av klienten eller testet av meg selv, blir den slått sammen til hovedgrenen. Den arbeidsflyten kan se slik ut.

# slå sammen funksjon til iscenesettelsesgren

git merge feature/32-new-feature

# distribuer og test funksjonen

git checkout main

git merge feature/32-new-feature

# distribuer funksjon til live-siden

I prosjektene mine har jeg konfigurert kontinuerlig distribusjon, noe som betyr at hver gang jeg skyver kode til hovedsiden, blir den automatisk sendt til live-siden. Den samme prosessen er satt opp for iscenesettelsesgrenen.

Hvis jeg jobbet med et team som kunne sjekke koden min i en arbeidsflyt for pull-forespørsel, ville jeg brukt dette systemet fordi det fungerer bra i et team. For en utvikler som for det meste jobber på egenhånd, er det rett og slett administrasjonskostnader som vil bremse arbeidsflyten din.

Avanserte Git-kommandoer jeg bruker

Nå som vi har en ide om hvordan vi kan bruke Git i en praktisk arbeidsflyt, la oss ta en titt på mer avanserte kommandoer som vil være nødvendig for å få dette til. Jeg bruker hver av disse kommandoene minst et par ganger i uken når jeg jobber med kundens kode.

Å lese:  PCI-samsvar & Magento 1 EOL – Når du ikke skal trykke på panikkknappen

Selv om du skal bruke en GUI-applikasjon (jeg nevnte noen gode i mitt siste innlegg på Git) er det fortsatt viktig å ha en forståelse av hva som skjer i bakgrunnen. Mange ganger har jeg måttet jobbe via terminal for å fikse et problem som ble opprettet av en Git GUI-applikasjon.

Legge til endringer etter linje

Den ene kommandoen som gjorde at Git ble brukt via terminalklikk for meg var git add -p. Inntil jeg lærte denne kommandoen brukte jeg GUI-applikasjoner fordi jeg ville gjøre endringer i koden min, men ønsker å dele opp spesifikke linjer i forskjellige commits slik at jeg kunne forklare hvorfor jeg hadde gjort en endring. For å gjøre dette brukte jeg en GUI for å velge linjene, men git add -p leder deg gjennom et interaktivt grensesnitt for å legge til endringer i biter.

Jeg bruker denne mange ganger hver dag.

Spor Remote Git Branch

Hvis du trekker ned et eksisterende depot og har grener som hoved og staging som du trenger å holde styr på, men som allerede eksisterer, må du fortelle dine versjoner av grenene om å spore disse versjonene av grenen.

Det er noen måter å gjøre dette på.

# Sett oppstrøms når du skyver til fjernkontrollen

git push -u opprinnelse iscenesettelse

# Sett oppstrøms

# antar at du er på grenen du ønsker å spore med fjernkontrollen

git branch -u opprinnelse/iscenesettelse

git branch –set-upstream-to=origin/staging

# Hvis du ikke er på grenen du vil spore, så spesifiser grenen på slutten

git branch –set-upstream-to=origin/staging staging

Lagre endringer uten å forplikte dem

Noen ganger vil du være midt i noe arbeid som ikke er klar til å bli forpliktet ennå, men du må redde tilstanden. Det er der git stash er nyttig. Denne kommandoen gjemmer endringer for deg ved å fjerne endringene. Du kan få dem tilbake ved å bruke git stash pop. Det er noen få flere kommandoer for å gjøre stash nyttigmen det er de to jeg bruker regelmessig.

Trekk en spesifikk Git Commit

Noen ganger må du trekke en bestemt forpliktelse inn i ditt nåværende arbeid. Med et rent HODE (du har ikke gjort noen endringer ennå) kan du trekke inn en spesifikk commit med git cherry-pick . Du kan finne full dokumentasjon om git cherry-pick her.

Å lese:  Hvordan fungerer WordPress Caching Plugins?

Kast endringer du ikke trenger

På et tidspunkt i ethvert prosjekt kommer vi til å gjøre endringer og så innse at det ikke fungerer, og vi må ganske enkelt skrote dem og begynne på nytt. I stedet for bare å prøve å angre til vi er tilbake der vi ønsker å være, kan vi bruke følgende Git-kommando for å fjerne eventuelle endringer som ikke har blitt sporet ennå.

git reset –hard

Kommandoen ovenfor vil tilbakestille koden din tilbake til den siste commit på grenen du jobber med. Vi kan også bruke en <#commitSHA> med denne kommandoen for å tilbakestille til en spesifikk commit hvis vi ønsket å komme tilbake til en tilstand før den siste commit. Kanskje du ville brukt dette til å tilbakestille til den første avdelingskassen fordi hele grenen verdt arbeid ikke er noe du vil beholde, men du hadde allerede sporet noe av arbeidet.

For å ta det ett skritt videre, kan vi kaste bort alle filer eller kataloger som ikke har blitt sporet i git ennå med git clean-kommandoen.

git clean -fd: flaggene f og d forteller git å kaste filer og kataloger som ikke er sporet.

Fjern grener

Hver eller annen uke ser jeg på resultatene av en git-statuskommando og finner at jeg har alt for mange grener til å forstå hva som skjer i depotet mitt. Det betyr at jeg kan fjerne alle grener som tilsvarer billetter som har blitt løst med følgende kommandoer.

# fjerner den lokale versjonen

git branch -d $branchname

#fjerner grenen på fjernkontrollen min

git push $remotename –slett $branchname

Bruk versjonskontroll

Selv om du kanskje ikke er en ekspert i det hele tatt Git-kommandoene du vil bruke, er en viktig ting å huske at du bør bruke versjonskontroll. Selv om du er den eneste personen som jobber med et prosjekt, vil bruk av Git og en Git-arbeidsflyt hjelpe deg med å holde prosjektene dine organisert. Du trenger ikke å trykke CTRL + Z før du har tilbakestilt arbeidet ditt etter å ha skrevet kode som ikke fungerte.

Du vil kunne stole på systemet ditt og fortsette å produsere arbeid for prosjektene dine.

Prøv Fullt administrert WordPress Hosting

Nye publikasjoner:

Anbefaling