Als je software schrijft voor de kost in 2018, dan kan ik met vertrouwen zeggen dat je bekend bent met Git. tool gemaakt door Linus Torvalds is synoniem geworden met versiebeheer. En zonder twijfel is een van de beste eigenschappen van Git hoe het de pijn van vertakken en samenvoegen wegneemt. Er zijn verschillende manieren waarop je een branch in Git kunt maken. In dit bericht zullen we er enkele bespreken. Daarna zullen we eindigen met een kleine reflectie op Git’s branching-model en branching in het algemeen.

Een branch creëren van Master

Je maakt branches in Git, niet verrassend, door het branch commando te gebruiken. Net als veel andere Git commando’s is “branch” erg krachtig en flexibel. Behalve het aanmaken van branches, kan het ook gebruikt worden om ze op een lijst te zetten en te verwijderen, en je kunt ze verder aanpassen het commando door een brede lijst van parameters te gebruiken. We beginnen met de eerste manier om een branch te creëren. Stel dat u een nieuwe map met de naam “mijn-app” wilt maken, deze wilt invoeren en een nieuwe Git-opslagplaats wilt starten. Dat is precies hoe u het zou doen:

mkdir my-appcd my-appgit init

Nu heb je een nieuwe, lege Git-repository. Maar lege repositories zijn saai. Dus hoe zit het met het maken van een nieuw markdown-bestand met “Hello World!” erin geschreven?

echo Hello World! > file.md

Als je “git status” uitvoert, zou je een bericht moeten zien dat zegt dat je bestand niet getraceerd is:

Niet-bijgehouden bestanden zijn echter ook niet cool, dus laten we het volgen:

git add file.md

En tot slot, laten we onze eerste commit:

git commit -m "First commit"

We hebben nu een repository met één branch, die precies één commit heeft.Dat klinkt misschien niet als de meest opwindende ding ter wereld (omdat het echt niet ’t is), maar het is zeker minder saai dan een opslagplaats hebben zonder helemaal geen commits, toch? Laten we nu zeggen dat je om wat voor reden dan ook het bestand moet wijzigen “is tevreden. Maar dat doe je niet daar zin in hebben. Wat als er iets misgaat en u op de een of andere manier de mooie, ongerepte inhoud van uw bestand bederft? (Ja, ik weet dat het gewoon een stom bestand is met “Hallo wereld!” Erin, maar gebruik de geweldige krachten van je verbeeldingskracht en beschouw het bestand als een proxy voor een veel complexer project.) De oplossing voor dit dilemma is natuurlijk een nieuwe branch aanmaken:

git branch exp

Dus nu hebben we een nieuwe branch genaamd “exp”, om mee te experimenteren Sommige mensen die gewend zijn verschillende versiebeheersystemen te gebruiken, vooral gecentraliseerde, zouden kunnen zeggen dat de branches dezelfde “inhoud” hebben. Dit is echter niet helemaal juist als het over Git gaat. Beschouw branches als referenties die verwijzen naar een gegeven commit.

Een branch creëren vanuit een commit

Stel dat we, om welke reden dan ook, ons experiment opgeven, zonder een enkele toe te voegen committeren aan de nieuwe branch. Laten we teruggaan naar master en de exp branch verwijderen:

git checkout mastergit branch -d exp

Nu we terug zijn bij een enkele branch, laten we er wat verplichtingen aan toevoegen om het werk te simuleren dat wordt gedaan:

Stel je voor dat je na al dit ‘werk’ te hebben gedaan, leert dat je, om wat voor reden dan ook, terug moet gaan in de tijd naar toen waren slechts twee regels in het bestand en creëer vanaf dat moment nieuwe wijzigingen. Maar tegelijkertijd moet je de voortgang behouden die je al hebt gemaakt. Met andere woorden, je wilt een branch maken van een eerdere commit. Hoe zou je dat doen In Git heeft elke commit een unieke identifier. Dus je kunt dit gemakkelijk zien met het “git log” commando. Om een nieuwe branch te creëren gebaseerd op een specifieke commit, geef je de hash ervan als parameter door aan het branch commando:

git branch new-branch 7e4decb

Even terzijde, je hebt meestal niet eens de hele hash nodig. Alleen de eerste vijf of zes karakters zullen het doen.

Een branch creëren van een tag

Als je een beetje meer ervaring hebt met Git, dan zou je bekend moeten zijn met de concept van tags. U gebruikt tags om aan te geven dat een bepaalde commit op de een of andere manier belangrijk of speciaal is. Tags worden bijvoorbeeld over het algemeen gebruikt om de daadwerkelijke versies van een product aan te geven. Als u al een tijdje in uw toepassing werkt en je gelooft dat het tijd is om versie 1.0 vrij te geven, wat je normaal gesproken zou doen is de versienummers waar nodig tegenwerken, die wijzigingen doorvoeren en dan een tag aan dat specifieke tijdstip toevoegen. Om een tag te maken, “voer je meestal zoiets uit:

git tag -a v1.0 -m "First major version"

De parameter” -a “geeft aan dat dit gebeurt om een geannoteerde tag te zijn. In tegenstelling tot een lichtgewicht tag, is dit een volledig Git-object, dat stukjes informatie bevat zoals de naam en het e-mailadres van de committer, het tijdstempel en een bericht. Nu heb je een tag, een indicatie dat dit specifieke punt in de geschiedenis speciaal is en een naam heeft. Leuk. U kunt doorgaan met het werk, zoals gewoonlijk, door wijzigingen aan te brengen en door te voeren die deel uitmaken van versie 1.1. Totdat er een bugrapport binnenkomt. Sommige clients die zijn bijgewerkt naar de 1.0-versie van het product zeggen dat een importfunctie niet werkt zoals bedoeld. In theorie zou je de bug in de master branch kunnen repareren en implementeren. Maar dan zouden de clients functies ontvangen die mogelijk niet getest en onvolledig zijn. Dat is nee -Nee. Dus wat doe je? Het antwoord: je maakt een nieuwe branch aan van de tag die je hebt gemaakt om de hoofdversie aan te geven. Je lost het probleem daar op, bouwt en implementeert. En je zou dit later waarschijnlijk terug moeten mergen naar master, zodat de volgende releases de fix bevatten . Hoe zou u dat aanpakken? Gemakkelijk:

git branch <NAME-OF-THE-BRANCH> <TAG>

Meer specifiek, met ons vorige voorbeeld:

git branch fix-bug-123 v1.0

Daarna kun je zoals gewoonlijk je nieuwe branch bekijken. Of nog beter, je zou het allemaal in één stap kunnen doen:

git checkout -b fix-bug-1234 v1.0

Een filiaal creëren in een vrijstaande hoofdstaat

Heb je ooit terug in de tijd willen gaan? Met Git is dit mogelijk … tenminste met betrekking tot de bestanden in onze repository. Je kunt op elk moment een commit bekijken als je de hash kent:

git checkout <SHA1>

Nadat je dat hebt uitgevoerd, zal Git je een merkwaardig bericht laten zien:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Wanneer je uitcheckt een commit, je komt in een speciale staat c alled, zoals je kunt zien, “vrijstaande HEAD”. Hoewel je wijzigingen in deze staat kunt committen, behoren die commits niet tot een branch en zullen ze ontoegankelijk worden zodra je een andere branch uitcheckt. Maar wat als je die commits toch wilt behouden? Het antwoord is, niet verrassend, te gebruiken nogmaals het “checkout” -commando om een nieuwe branch aan te maken:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

En natuurlijk weet je inmiddels dat je de laatste twee regels als een enkel commando:

git checkout -b new-branch-to-keep-commits

Vrij eenvoudig, toch?

Gewoon omdat je het kunt … Betekent dat niet dat je het moet

Het vertakkingsmodel van Git is een van zijn verkoopargumenten. Het verandert wat in andere broncontrolesystemen een pijnlijk en zelfs langzaam proces is in een eitje. Je zou kunnen zeggen dat Git met succes vertakking voor de massa heeft gedemocratiseerd. Maar er schuilt een ernstig gevaar. Vanwege de lage prijs van vertakking in Git, kunnen sommige ontwikkelaars in de val lopen door met zeer langlevende branches te werken of workflows of branching-modellen te gebruiken die rooster. Wij zijn er als branche geweest. Dat hebben we gedaan. Het werkt niet. Omarm in plaats daarvan workflows die gebruik maken van zeer kortstondige branches. Je hebt een veilige sandbox waarin je kunt coderen zonder bang te hoeven zijn om dingen kapot te maken of de tijd van je collega’s te verspillen. Maar vraagt u zich daarbij af: “Hoe implementeer ik code met gedeeltelijk voltooide functies?” In dat geval zijn het feature vlaggen die je helpen. Git branches zijn een krachtig hulpmiddel. Gebruik ze verstandig en maak er geen misbruik van. En als ze nog niet genoeg zijn, past u continue levering / continue integratie toe samen met functievlaggen – inclusief gespecialiseerde tools tot uw beschikking – zodat uw applicaties naar het volgende niveau kunnen gaan.