Bij het ontwikkelen van nieuwe software wordt vaak gebruikgemaakt van het populaire GitFlow en GitLab Workflow. Bij Seleno hebben we ruime ervaring met beide varianten, dus daarom zetten we ze in dit artikel tegen elkaar af. Wat zijn van beide de voordelen en waar zitten juist de grote verschillen?
Voordat we beginnen
Zowel GitFlow als Gitlab Workflow zijn bedoeld om meerdere ontwikkelaars tegelijkertijd aan dezelfde code te kunnen laten werken. Er worden zogenaamde branches aangemaakt waarin wijzigingen worden gedaan, die vervolgens weer samen worden gevoegd met de originele versie. Zo is er altijd 1 versie met de meest recente versie van de software, en kunnen ontwikkelaars in hun eigen kopieën rustig aan nieuwe features werken. Beide tools zorgen ervoor dat het samenvoegen van wijzigingen, nieuwe features en bugfixes zo soepel mogelijk verloopt.
Over GitFlow
GitFlow is eigenlijk de standaard voor het opzetten van je branching model. Gitflow gaat er van uit dat je develop branch de basisversie van je software is. Elke ontwikkelaar gebruikt de code in de develop branch dus als rode draad voor de code die ze schrijven. Elke feature of fix die wordt ontwikkeld, wordt dus ook op basis van de develop branch gedaan. En ze worden daarna weer gemerged (lees: samengevoegd) naar de develop branch. Deze branch bevat dus altijd de laatste versie van de software.
Over GitLab Workflow
GitLab Workflow is vergelijkbaar met GitFlow. In GitLab Workflow beschouwen ze de master branch als rode draad. Features en bugfixes worden dus op basis van de master branch ontwikkeld en uiteindelijk toegevoegd aan de master branch.
GitFlow zorgt voor vervuiling in de git log
Bij het toepassen van continuous integration zien we in de praktijk hele duidelijke verschillen ontstaan.
Veel bedrijven werken met GitFlow. Maar als we meekijken met de merge requests om code te publiceren, zien we dat deze tool wel wat extra stappen nodig heeft om de code op de juiste plek uit te rollen.
Als we ervan uitgaan dat er een feature branch is, de develop branch als main branch uitgerold kan worden naar staging en de master branch naar de productieomgeving, zien we bij GitFLow de volgende 2 stappen:
- Een merge request van de feature branch naar develop om de code in de main branch te zetten. Deze develop branch kan uitgerold worden naar staging.
- Een merge request van de develop branch naar master om dezelfde code naar productie te krijgen.
Kijken we in dezelfde situatie naar GitLab WorkFlow, met de master branch als main branch en geen develop branch, dan zien we deze 2 stappen:
- Een merge request van de feature branch naar master om de code in de main branch te zetten. Deze master branch kan uitgerold worden naar staging.
- Een tag die wordt aangemaakt op basis van de master branch. Hierin staat bijvoorbeeld een versienummer waarnaar gerefereerd kan worden in release notes.
2 stappen naar productie, maar grote verschillen
Ondanks dat de code in beide gevallen in 2 stappen naar de productieomgeving gezet kan worden, is er een groot verschil: de lijst met commits in de git log.
In deze lijst worden alle wijzigingen bijgehouden die aan de code gedaan zijn. Dat is heel handig, omdat je op die manier bijvoorbeeld snel kunt achterhalen wanneer een feature is toegevoegd of waar een bug is ontstaan. Maar je wilt niet álle merge requests terugvinden in de git log, want dat zorgt voor een hoop vervuiling.
En dat is precies wat GitFlow wel doet en Gitlab Workflow niet. GitFlow neemt ook alle kleine bug- en hotfixes mee in de git log, wat zorgt voor een onoverzichtelijk geheel. Daarnaast hangt GitFlow geen duidelijk label aan de release, waardoor het terugvinden lastiger is. Bij GitLab Workflow gaat dat eenvoudig via de tags, die eigenlijk gelijk zijn aan je releases.
Ons advies
Juist vanwege het betere overzicht, adviseren wij onze klanten GitLab Workflow te gebruiken. We hebben goede ervaringen en weten vanuit de praktijk dat het prettiger werkt dan GitFlow. Wil je meer weten over 1 van beide tools? We kunnen je er alles over vertellen.