Jeg lærer for øyeblikket å bruke Git ved å lese Pro Git . Akkurat nå lærer jeg om forgrening og tagger. Spørsmålet mitt er når skal jeg bruke en gren og når skal jeg bruke en tag?
La oss for eksempel si at jeg oppretter en gren for versjon 1.1 av et prosjekt. Når jeg er ferdig og slipper denne versjonen, skal jeg forlate grenen for å merke utgivelsesversjonen? Eller skal jeg legge til en tag? Hvis jeg legger til en tag, skal jeg slette versjonsgrenen (forutsatt at den er slått sammen til master eller en annen gren )?
Svar
Kort sagt: Beste fremgangsmåten er gren ut, flett ofte og hold alltid synkronisert .
Det er ganske klare konvensjoner om å holde koden din i separate grener fra hovedgren:
- Du er i ferd med å implementere større eller forstyrrende endringer
- Du handler om for å gjøre noen endringer som kanskje ikke blir brukt
- Du vil eksperimentere med noe du ikke er sikker på at det vil fungere
- Når du blir bedt om å forgrene deg, kan andre ha noe de trenger å gjøre i master
Tommelfingerregelen er etter at du har forgrenet deg. gren. For til slutt må du slå det sammen til mesteren. For å unngå et enormt komplisert rot av konflikter når du smelter sammen, bør du begå ofte, slå sammen ofte.
God praksis å følge
En vellykket Git-forgreningsmodell av Vincent Driessen har gode forslag. Hvis denne forgreningsmodellen appellerer til deg, bør du vurdere flytutvidelsen til git . Andre har kommentert om flyt .
Merkingsmetoder
Som du allerede vet, gir Git deg kommisjonsidentifikatorer som 1.0 -2-g1ab3183 men det er ikke koder! Merking gjøres med git-taggen, og kodene som opprettes ved hjelp av git-taggen, er basen for forpliktelsesidentifikatorene som git beskriver oppretter. Med andre ord, i Git merker du ikke grener. Du merker forpliktelser. Det er riktig å si at taggen bare er en kommentert peker til en forpliktelse.
La oss se på praktisk eksempel som demonstrerte det,
/-- [v1.0] v ---.---.---.---S---.---A <-- master \ \-.---B <-- test
La «s begå» S «bli begått pekt av tag» v1.0 «. Denne forpliktelsen er både på gren «master» og på gren «test». Hvis du kjører " git beskriv " på toppen av commit » En «(toppen av» master «-grenen) vil du få noe sånt som v1.0-2-g9c116e9. Hvis du kjører " git beskriver " på toppen av begå «B» (også kalt «test» -grenen) vil du få noe som v1.0-2-g3f55e41, det er tilfellet med standard git-beskriv konfigurasjon. Merk at dette resultatet er litt annerledes. v1.0-2-g9c116e9 betyr at vi er på commit med sortert SHA-1 id på 9c116e9, 2 forplikter etter tag v1.0. Det er ingen tag v1.0-2!
Hvis du vil at taggen din skal vises bare på grenen «master», kan du opprette ny kommisjon (f.eks. Bare oppdatere standard / reserve versjonsinformasjon i GIT-VERSION-FILE) etter forgreningspunkt for «test» -gren. Hvis du tagger forplikter seg til «test» -gren med f.eks. «v1.0.3` det ville bare være synlig fra» test «.
Referanser
Jeg har funnet mange, mange nyttige blogger og innlegg å lære av. Imidlertid de som er profesjonelt illustrerte er sjeldne. Dermed vil jeg anbefale et innlegg – En vellykket Git-forgreningsmodell av @nvie. Jeg har lånt illustrasjonen hans:)
Kommentarer
- 1.0-2-g1ab3183 er en identifikator konstruert av git, beskriver fra informasjon tilgjengelig fra git, men å kalle det en git-identifikator er litt for mye. Git identifiserer ved SHA-hash; koder og grener er menneskelige konstruksjoner som git hjelper med å holde oversikt over. Som sådan lager du en tag når du tror at et menneske en dag vil finne et praktisk bokmerke for en forpliktelse.
- en fantastisk illustrasjon av flerdimensjonalitet i gituniverset. vakker. takk
- Det er verdt og bemerker at mange prosjekter ikke har behov for noen av banene vist i dette diagrammet. Noen prosjekter trenger bare det som ' heter utviklet og inneholder her. Dette gjelder ofte for webapper som kan distribueres etter eget ønske.
- Selv forfatteren av git flow anbefaler ikke lenger det for mange prosjekttyper, for eksempel nettutvikling. Mange tror det er mye mer komplekst enn de aller fleste prosjekter trenger, noe som gjør det vanskelig å gjennomføre og lett å ta feil.I den andre enden av spekteret bruker noen avanserte utøvere advokatlag ' trunkbasert utvikling ', som nesten aldri bruker grener i det hele tatt, og levere vellykkede prosjekter som det. For noe mellomliggende, bør du vurdere " anti-gitflow '
Svar
En gren brukes hvis du har to forskjellige versjoner av depot samtidig. En tag er en måte å markere et tidspunkt i depotet ditt.
Du bør legge til en tag for å markere en utgitt versjon. Hvis du da trenger å lage feilrettinger til den utgivelsen, vil du opprette en gren ved taggen.
Du vil bare slette grener som er slått sammen i HEAD [eller en annen gren].
Kommentarer
- oh … og jeg antar at du mener at grenen blir slått sammen til en annen gren, for eksempel master. HEAD beveger seg hver gang jeg gjør en kasse, ikke sant?
- HEAD peker vanligvis på en gren (med mindre du ' er i frittliggende HEAD-modus), så HEAD beveger seg med grenen den peker på