Ik ben momenteel aan het leren om Git te gebruiken door Pro Git . Op dit moment leer ik over branching en tags. Mijn vraag is wanneer moet ik een branch gebruiken en wanneer moet ik een tag gebruiken?
Stel dat ik bijvoorbeeld een branch maak voor versie 1.1 van een project. Als ik klaar ben en deze versie vrijgeef, moet ik dan de branch verlaten om de releaseversie te markeren? Of moet ik een tag toevoegen? Als ik een tag toevoeg, moet ik de versietak verwijderen (ervan uitgaande dat deze is samengevoegd met master of een andere branch). )?
Antwoord
In het kort: Best practice is vertakking, vaak samenvoegen en altijd gesynchroniseerd houden .
Er zijn vrij duidelijke conventies over het bewaren van je code in een aparte branche van de master branch:
- Je staat op het punt een grote of verstorende verandering te implementeren
- Je staat op het punt om enkele wijzigingen aan te brengen die misschien niet worden gebruikt
- U wilt experimenteren met iets waarvan u niet zeker weet of het zal werken
- Als je wordt verteld dat je moet vertakken, hebben anderen misschien iets dat ze moeten doen in master
Vuistregel is dat je na het vertakken synchroon moet blijven met de master Afdeling. Omdat je het uiteindelijk weer moet samenvoegen tot master. Om een enorme gecompliceerde puinhoop van conflicten te vermijden bij het opnieuw samenvoegen, moet je je vaak committeren, vaak samenvoegen.
Goede praktijken om te volgen
Een succesvol vertakkingsmodel van Git door Vincent Driessen heeft goede suggesties. Als dit branching-model je aanspreekt, overweeg dan de flow-extensie voor git . Anderen hebben opmerkingen gemaakt over flow .
Tagging-praktijken
Zoals je al weet, geeft Git je commit-identifiers zoals 1.0 -2-g1ab3183 maar dat zijn geen tags! Het taggen wordt gedaan met de git-tag, en de tags die zijn gemaakt met de git-tag zijn de basis voor de commit-identifiers die git omschrijft. Met andere woorden, in Git tag je geen branches. Je tagt commits. Het is correct om te zeggen dat de tag slechts een geannoteerde pointer naar een commit is.
Laten we eens kijken naar een praktisch voorbeeld dat het demonstreerde,
/-- [v1.0] v ---.---.---.---S---.---A <-- master \ \-.---B <-- test
Laten we “s commit” S “vastleggen door middel van tag” v1.0 “. Deze commit is zowel op de branch “master” als op de branch “test”. Als je " git beschrijven " bovenop commit ” Een “(top of” master “branch) je zou zoiets krijgen als v1.0-2-g9c116e9. Als je " git beschrijft " uitvoert bovenop commit “B” (ook bekend als de “test” branch), zou je iets krijgen als v1.0-2-g3f55e41, dat is het geval met de standaard git-descript-configuratie. Merk op dat dit resultaat iets anders is. v1.0-2-g9c116e9 betekent dat we vastleggen met gesorteerde SHA-1 id van 9c116e9, 2 commits na tag v1.0. Er is geen tag v1.0-2!
Als je wilt dat je tag alleen op de branch “master” verschijnt, kun je een nieuwe commit aanmaken (bijv. Alleen update default / fallback versie-informatie in GIT-VERSION-FILE) na het vertakkingspunt van de “test” -tak. Als je commits tagt op de “test” branch met bijv. “v1.0.3” zou het alleen zichtbaar zijn vanaf “test”.
Referenties
Ik heb veel, veel, nuttige blogs en berichten gevonden om van te leren. professioneel geïllustreerd zijn zeldzaam. Daarom zou ik een post willen aanbevelen – Een succesvol vertakkingsmodel van Git door @nvie. Ik heb zijn illustratie geleend:)
Opmerkingen
- 1.0-2-g1ab3183 is een identifier geconstrueerd door git beschrijven uit informatie die beschikbaar is van git, maar het een git identifier noemen is iets te veel. Git identificeert door SHA hash; tags en branches zijn menselijke constructies die git handig bijhoudt. Maak daarom een tag als je denkt dat een mens ooit een handige bladwijzer voor een commit wil vinden.
- een prachtige illustratie van multidimensionaliteit in het git-universum. mooi. bedankt
- Het is de moeite waard opmerkend dat veel projecten sommige niet nodig hebben van de rijstroken in dit diagram. Sommige projecten hebben alleen wat ' s genaamd ontwikkel en functie hier nodig. Dit geldt vaak voor webapps die naar believen kunnen worden geïmplementeerd.
- Zelfs de auteur van git flow raadt het niet langer aan voor veel projecttypen, zoals webontwikkeling. Veel mensen denken dat het veel complexer is dan de overgrote meerderheid van de projecten nodig heeft, waardoor het lastig is om uit te voeren en gemakkelijk fout kan worden gemaakt.Aan de andere kant van het spectrum gebruiken sommige teams van ervaren beoefenaars die zich inzetten voor ' trunk-gebaseerde ontwikkeling ', die bijna nooit takken gebruikt, en op die manier succesvolle projecten opleveren. Overweeg voor iets intermediair " anti-gitflow '
Antwoord
Een branch wordt gebruikt als je 2 verschillende versies van repository tegelijkertijd hebt. Een tag is een manier om een tijdstip in je repository te markeren.
Je zou een tag moeten toevoegen om een vrijgegeven versie te markeren. Als je dan bugfixes moet maken voor die uitgave, zou je een branch aanmaken bij de tag.
Je wilt alleen branches verwijderen die weer in de HEAD [of een andere branch] zijn samengevoegd.
Reacties
- oh … en ik neem aan dat je bedoelt dat de branch wordt samengevoegd in een andere branch, zoals master. HEAD beweegt elke keer als ik een checkout doe, toch?
- HEAD verwijst meestal naar een branch (tenzij je ' in de vrijstaande HEAD-modus bent), dus HEAD beweegt mee met de branch waarnaar het verwijst