Kort sagt: Bedste praksis er gren ud, flet ofte og hold altid synkroniseret .

Der er ret klare konventioner om at opbevare din kode i separate grene fra hovedfilialen:

1. Du er ved at implementere større eller forstyrrende ændringer
2. Du handler om for at foretage nogle ændringer, der muligvis ikke bruges
3. Du vil eksperimentere med noget, som du ikke er sikker på, at det fungerer
4. Når du bliver bedt om at forgrene dig, kan andre have noget, de skal gøre i master

Tommelfingerregel er, når du har forgrenet dig, du skal holde dig synkroniseret med master afdeling. Fordi til sidst skal du flette det tilbage til mesteren. For at undgå et enormt kompliceret rod af konflikter, når du fusionerer tilbage, skal du begå ofte, fusionere ofte.

God praksis at følge

En vellykket Git-forgreningsmodel af Vincent Driessen har gode forslag. Hvis denne forgreningsmodel appellerer til dig, skal du overveje flowudvidelsen til git . Andre har kommenteret om flow .

Mærkningspraksis

Som du allerede ved, giver Git dig forpligtelsesidentifikatorer som 1.0 -2-g1ab3183 men det er ikke tags! Mærkning udføres med git-tag, og de tags, der oprettes ved hjælp af git-tag, er basen for de forpligtelsesidentifikatorer, som git beskriver skaber. Med andre ord, i Git mærker du ikke grene. Du mærker forpligtelser. Det er korrekt at sige, at mærket kun er en kommenteret markør til en forpligtelse.

Lad os se på et praktisk eksempel, der demonstrerede det,

 /-- [v1.0] v ---.---.---.---S---.---A <-- master \ \-.---B <-- test 

Lad “s begå” S “blive begået peget af tag” v1.0 “. Denne forpligtelse er både på gren “master” og på gren “test”. Hvis du kører " git beskriv " oven på commit ” En “(øverst på” master “-grenen) får du noget i retning af v1.0-2-g9c116e9. Hvis du kører " git beskriver " oven på begå “B” (også kaldet “test” -grenen) får du noget i retning af v1.0-2-g3f55e41, det er tilfældet med standard git-beskriv konfiguration. Bemærk, at dette resultat er lidt anderledes. v1.0-2-g9c116e9 betyder, at vi er på begå med sorteret SHA-1 id på 9c116e9, 2 begår efter tag v1.0. Der er intet tag v1.0-2!

Hvis du ønsker, at dit tag kun skal vises i filialens “master”, kan du oprette nyt commit (f.eks. Kun opdatere standard / fallback versionoplysninger i GIT-VERSION-FILE) efter forgreningspunktet for “test” -grenen. Hvis du mærker forpligter sig til “test” -gren med f.eks. “v1.0.3` det ville kun være synligt fra” test “.

Referencer

Jeg har fundet mange, mange nyttige blogs og indlæg at lære af. Dog dem, der er professionelt illustreret er sjældne. Så jeg vil anbefale et indlæg – En vellykket Git-forgreningsmodel af @nvie. Jeg har lånt hans illustration:)

Kommentarer

• 1.0-2-g1ab3183 er en identifikator konstrueret af git beskrive ud fra information tilgængelig fra git, men at kalde det en git-id er lidt for meget. Git identificeres ved SHA-hash; tags og grene er menneskelige konstruktioner, som git hjælper med at holde styr på. Som sådan lav et tag når du tror, at et menneske en dag vil finde et praktisk bogmærke for en forpligtelse.
• en vidunderlig illustration af multidimensionalitet i gituniverset. smuk. tak
• Det er værd bemærker, at mange projekter ikke har behov for nogle af banerne vist i dette diagram. Nogle projekter har kun brug for det, der ' kaldes, udvikler og indeholder her. Dette gælder ofte for webapps, der kan implementeres efter ønske.
• Selv forfatteren af git flow anbefaler ikke længere det til mange projekttyper, såsom webudvikling. Mange mennesker mener, at det er meget mere komplekst, end langt størstedelen af projekterne har brug for, hvilket gør det besværligt at udføre og let at tage fejl.I den anden ende af spektret bruger nogle avancerede praktiserende advokathold ' trunkbaseret udvikling ', som næsten aldrig bruger grene overhovedet, og levere vellykkede projekter som det. For noget mellemliggende, overvej " anti-gitflow '

En gren bruges, hvis du har 2 forskellige versioner af lageret på samme tid. Et tag er en måde at markere et tidspunkt i dit arkiv.

Du skal tilføje et tag for at markere en frigivet version. Hvis du derefter har brug for at lave fejlrettelser til den frigivelse, opretter du en gren ved tagget.

Du vil kun slette grene, der er blevet flettet tilbage i HEAD [eller en anden gren].

Kommentarer

• åh … og jeg antager, at du mener, at grenen flettes til en anden gren, såsom master. HEAD bevæger sig hver gang jeg foretager en checkout, ikke?
• HEAD peger normalt på en gren (medmindre du ' er i løsrevet HEAD-tilstand), så HEAD bevæger sig med grenen det peger på