Git is een versiebeheersysteem dat de kern vormt van bijna alle softwareontwikkeling - het wordt gebruikt om wijzigingen in de code die u schrijft op te slaan en bij te houden. Wanneer u in teams werkt, is het hebben van een gemakkelijk te volgen workflow die werkt voor uw bedrijf cruciaal voor een snelle ontwikkeling.
Betere repository-organisatie, snellere ontwikkeling
Met de opkomst van gebruiksvriendelijke automatiseringspijplijnen zoals Jenkins, beginnen veel bedrijven aan continue integratie en levering (CI/CD), waarbij wijzigingen van ontwikkelaars vaak worden samengevoegd in de repo, meestal met het verzenden van een product op een wekelijks in plaats van maandelijks schema.
Dit soort snelheid legt veel stress op je organisatie, vooral als het om Git gaat. Als je 50 mensen hebt, die allemaal proberen veranderingen aan te brengen in dezelfde
master branch, dan zul je problemen krijgen met frequente merge conflicten.
Gelukkig biedt Git de mogelijkheid om branches te maken en te kiezen wanneer je code wilt samenvoegen, die elk team zou moeten gebruiken om hun ontwikkeling te organiseren. Door je Git-workflow onder controle te krijgen, hoeven jij en je teamgenoten op zijn minst geen tijd te verspillen aan het googelen van meer Git-problemen.
Functies en takken ontwikkelen
Er zijn twee grote problemen die Git-vestigingen moeten oplossen: je interne teams synchroon houden en je openbare release behouden.
Als je een branch start in Git, worden nieuwe commits gemaakt op die branch, in plaats van
master Dit kan handig zijn om de individuele voortgang van een bepaalde feature of bugfix; elke tak kan bijvoorbeeld een functie implementeren die wordt beschreven in een probleem in een Kanban-service, zoals Jira, Trello of Github Issues & Projects.
Meestal wordt het samenvoegen van branches gedaan met pull-verzoeken, een functie van gehoste Git-oplossingen zoals Github, waarbij het team vraagt dat
master
pull uit de
featurebranch, en integreer de wijzigingen voor iedereen. Dit kan erg handig zijn voor teams om QA- en unit-tests uit te voeren om ervoor te zorgen dat de branch goed functioneert voordat ze in de keten worden geduwd.
Het andere probleem is het beheren van je releases - je wilt je klanten geen kopie van je nieuwste interne dev-build sturen, omdat die kan worden verbroken door een foutieve commit.
Om dat op te lossen, zullen veel teams een aparte branch gebruiken voor releases, en die branch alleen samenvoegen als het tijd is om een nieuwe versie te pushen. Hierdoor kunnen meerdere commits op de achtergrond worden gedaan, in de dev-tak tussen releases.
Een ander voordeel van dit model is dat het in staat is om afzonderlijke commits te maken op de productietak, misschien om patches voor problemen te bieden voordat de volgende release klaar is.
Trunk-gebaseerde ontwikkeling
Uw vertakkingsstrategie bepa alt de exacte manier waarop u deze aan u verstrekte tools gebruikt. Er zijn veel verschillende vertakkingsstrategieën gemaakt voor verschillende soorten teams.
Trunk-gebaseerde ontwikkeling komt dicht in de buurt van wat teamprogrammering zou moeten zijn: snelle iteratie op de
master
branch, om snel een levensvatbaar product te lanceren. Het team maakt kortstondige feature branches, die meestal niet langer dan een paar dagen duren, en zich vaak rechtstreeks committeren aan
master
Het wordt "trunk" genoemd omdat het effect hiervan de
master branch de meest actieve en bruikbare branch in de hele repo maakt, zoals een dikke boomstam die al het andere ondersteunt. Alle ontwikkeling wordt gedaan gericht op deze tak, die snel en gemakkelijk in je hoofd te wikkelen is, wat zorgt voor een goede ontwikkelaarservaring.
Eenmaal klaar voor release, wordt voor elke release een nieuwe vertakking met versie gemaakt. Dit houdt releases gescheiden van
master en helpt ook bij het toevoegen of kiezen van patches aan LTS-releases.
Dit heeft veel voordelen, vooral voor kleine teams. Als u met een handvol senior ontwikkelaars werkt die u kent en die u vertrouwt met schrijfrechten voor de hele repo, kan het zo snel mogelijk integreren van uw wijzigingen de ontwikkeling echt versnellen. Het neemt tenslotte bijna alle bureaucratie weg van constante pull-verzoeken en fusies - hoewel eenvoudige communicatie met je team nog steeds nodig is om te voorkomen dat je elkaar op de tenen loopt, en je moet te allen tijde weten waar een ander aan werkt.
Dit is echter geen geweldige organisatie, omdat het afhankelijk is van discipline en goede ontwikkelaars om het voor elkaar te krijgen. Het is echt geweldig om snel producten op de markt te brengen, of om snel bestaande projecten te herhalen, maar zodra je meer junior ontwikkelaars aan het project toevoegt, of meer open source-medewerkers krijgt, begint het zijn gebreken te vertonen.
Traditionele Git Flow
"Git Flow" is een workflow die voor veel teams heeft gewerkt. Het is ingewikkelder dan de eenvoudige workflow van trunkgebaseerde ontwikkeling, maar het biedt veel voordelen voor open-sourceprojecten en grote projecten met veel teamleden.
In een Git Flow-vertakkingsstrategie hebben functievertakkingen een langere levensduur en zijn ze de primaire focus van dagelijkse integratie. Teams werken aan functies totdat ze klaar zijn voor productie en doorlopen vervolgens het pull-aanvraagproces om ze goedgekeurd te krijgen. Er kan een willekeurig aantal functies tegelijk zijn, inclusief degenen die lang genoeg meegaan om te moeten worden gerebaseerd op recentere
master commits.
Met Git Flow is de toegang beperkter, omdat de meeste ontwikkelaars geen toestemming hebben om rechtstreeks samen te voegen met
develop
, en natuurlijk niet op
master, en zal vertakkingen moeten maken als de primaire methode om wijzigingen aan te brengen.
Git Flow laat natuurlijk tijd over voor een goede codebeoordeling tijdens het pull-aanvraagproces. Hiermee kunnen conflicten worden afgehandeld via PR's, rebasen en samenvoegen, in plaats van een constant veranderende trunk-tak. Dit is logisch voor open source, aangezien die vestigingen van buitenstaanders kunnen zijn, maar het is ook logisch in grote teamomgevingen of voor teams die monolithische producten met veel componenten leveren.
Een van de belangrijkste kenmerken van deze workflow is het releasepatroon. Wanneer het tijd is voor een nieuwe release, wordt er een aparte branch gemaakt om voor te bereiden. De laatste bugfixes en patches worden hier gedaan, dan gepusht naar de eigenlijke
master branch en voorzien van een tag, van waaruit een release kan worden gebouwd.
Het belangrijkste verschil is dat deze
master
branch wordt onderhouden naast
develop
De commits van de release branches worden weer samengevoegd indevelop
, evenals eventuele hotfixes. Dit maakt
develop
altijd de meest up-to-date branch, van waaruit releases worden gemaakt als ze stabiel zijn.
Deze scheiding maakt het gemakkelijker om kleinere bugfixes te beheren die moeten worden vrijgegeven voordat
master wordt samengevoegd met de nieuwste releases. Een release-branch werkt vrij gelijkaardig aan een feature-branch, met als functie het feit dat het wordt gemarkeerd als een stabiele release.
Constante pull-verzoeken, rebasen en samenvoegen is natuurlijk hard werken en kan vermoeiend zijn als je snel probeert te werken. Maar net als bij statisch typen of unit-tests, is het uiteindelijk de moeite waard om alles georganiseerd te houden en altijd soepel te laten werken.
Kies wat bij u past
Uiteindelijk draait het allemaal om het hebben van goede teametiquette, en je team kan het prima redden met een Git-geschiedenis die meer op een regel lijkt dan op een mooi diagram. Als je project klein is, of als je een solo-hobbyist bent, kan het naleven van strikte Git-normen je meer kwaad dan goed doen.
Maar als je problemen hebt met Git, wil je misschien trunk-gebaseerde ontwikkeling of Git Flow proberen. Als u zich bewust bent van de organisatie van uw repository, kunt u op zijn minst uw integratieproces verbeteren.
