GitHub Flow: een gestroomlijnde en collaboratieve manier van werken met Git

Git is een krachtig en populair versiebeheersysteem dat ontwikkelaars wereldwijd gebruiken om samen te werken aan softwareprojecten. Wanneer je met Git werkt, heb je verschillende strategieën om te bepalen hoe je wijzigingen integreert in de main branch van je project. Een populaire strategie is GitHub Flow. In deze blogpost zullen we bekijken wat GitHub Flow is, hoe GitHub Flow werkt en hoe het kan bijdragen aan een gestroomlijnde en collaboratieve manier van werken.

Wat is GitHub Flow?

GitHub Flow is een workflow voor softwareontwikkeling die speciaal is ontworpen voor teams die Git en GitHub gebruiken. De workflow is gebaseerd op het principe van Continuous Delivery. Het zorgt ervoor dat ontwikkelaars snel en efficiënt wijzigingen kunnen integreren in de main branch van het project. GitHub Flow is geoptimaliseerd voor het werken aan webapplicaties en andere soorten software die snel kunnen worden uitgerold.

GitHub flow in Gitlab pipelines

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy
# Define the jobs for each stage
build:
  stage: build
  script:
    - echo "Building the Docker image"
test:
  stage: test
  script:
    - echo "Running tests"
deploy:
  stage: deploy
  script:
    - echo "Deploying to the environment"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE == "push"'

De GitHub Flow pipeline heeft drie stages: "build", "test" en "deploy". De "build" en "test" stages zijn niet afhankelijk van een branch of merge request. Ze zijn bedoeld om te builden en tests uit te voeren.

De "deploy" fase is bedoeld om het artifact dat uit de build en test stages komt, naar een omgeving te deployen. In dit voorbeeld wordt de deploy fase alleen uitgevoerd wanneer er wordt gepusht naar de hoofd (main) branch.

Hoe werkt GitHub Flow?

GitHub Flow bestaat uit 4 stappen:

1. Creëer een branch: de eerste stap is een nieuwe branch maken van de main branch van het project. Dit is de branch waarin je wijzigingen gaat aanbrengen en waarvan je later een pull request indient.
   
2. Voeg commits toe: de volgende stap is het toevoegen van commits aan de branch die je hebt gemaakt. Commits zijn de individuele wijzigingen die je aanbrengt in je code. Elke commit bevat een beschrijving van de wijzigingen die je hebt aangebracht.
   
3. Open een pull request: zodra je tevreden bent met de wijzigingen die je hebt aangebracht, open je een pull request (PR) om de wijzigingen samen te voegen met de main branch van het project. Andere ontwikkelaars kunnen dan de wijzigingen bekijken en feedback geven.
   
4. Merge en deploy: wanneer de pull request is goedgekeurd, kun je de wijzigingen samenvoegen met de main branch van het project. De wijzigingen worden dan automatisch uitgerold naar de productieomgeving.
   
   

Wat zijn de voordelen van GitHub Flow?

Hieronder hebben we aan aantal voordelen voor het gebruik van GitHub Flow voor je op een rijtje gezet:

1. Snelheid en efficiëntie: door het gebruik van branches en pull requests kunnen ontwikkelaars snel en efficiënt werken aan wijzigingen en nieuwe functies. Ontwikkelaars kunnen eenvoudig switchen tussen verschillende branches en samenwerken aan meerdere wijzigingen tegelijk.
   
2. Transparantie en samenwerking: met GitHub Flow kunnen ontwikkelaars transparant samenwerken aan wijzigingen en feedback geven op elkaars werk. Door de open en collaboratieve werkwijze, wordt de kwaliteit van de code verbeterd en kunnen problemen snel worden opgelost.
   
3. Continuous delivery: GitHub Flow is geoptimaliseerd voor het werken met continuous delivery. Wijzigingen kunnen snel worden geïntegreerd in de main branch van het project en automatisch worden uitgerold naar de productieomgeving.
   
   

Waar moet je rekening mee houden wanneer GitHub Flow gebruikt?

Er zijn ook een aantal zaken waar je goed over na moet denken:

1. Minder geschikt voor grote en complexe projecten: GitHub Flow is gericht op kleinere en minder complexe projecten. Voor grote en complexe projecten kan het beheer van feature branches moeilijker worden en kan er meer behoefte zijn aan de structuur van andere branching-modellen zoals Gitflow.
   
2. Geen duidelijke scheiding tussen ontwikkeling en stabilisatie: met GitHub Flow is er geen duidelijke scheiding tussen ontwikkeling en stabilisatie, omdat elke wijziging rechtstreeks naar de productieomgeving kan worden gebracht. Dit kan leiden tot problemen met stabiliteit en regressie.
   
3. Beperkte controle over de release-cyclus: met GitHub Flow is er weinig controle over de release-cyclus. Dit kan leiden tot uitdagingen bij het plannen en coördineren van releases. Dit kan met name problematisch zijn voor projecten met meerdere teams en afhankelijkheden tussen projecten.
   
4. Complexer om grote wijzigingen te coördineren: GitHub Flow kan het moeilijker maken om grote wijzigingen te coördineren die meerdere ontwikkelaars of teams nodig hebben. Dit komt doordat er geen centrale plaats is om de wijzigingen samen te brengen en te integreren voordat ze naar de productieomgeving worden gebracht.
   
5. Minder geschikt voor continuous integration en testen: GitHub Flow is minder geschikt voor continuous integration en testen, omdat elke wijziging rechtstreeks naar de productieomgeving kan worden gebracht, met de kans dat er niet voldoende tests en validaties worden uitgevoerd. Dit kan leiden tot problemen met kwaliteit en betrouwbaarheid.
   
   

Wat is ons advies?

GitHub Flow is een eenvoudige en flexibele branching strategie voor softwareontwikkeling die gericht is op het snel en betrouwbaar opleveren van code. De overhead is minder t.o.v. sommige andere branching strategieën. Hierdoor is het ideaal voor kleine- en middelgrote projecten. Het gebruik van feature-branches stelt ontwikkelaars in staat om geïsoleerd aan nieuwe functionaliteiten te werken zonder de voortgang van het team te belemmeren. De focus op kleine, incrementele veranderingen helpt om fouten vroegtijdig te detecteren en vermindert de kans op complexe merge conflicten. Dit maakt GitHub Flow een populaire keuze voor teams die werken aan projecten waarvan de omvang en complexiteit beheersbaar zijn.

Het is belangrijk om te benadrukken dat GitHub Flow niet voor elk project geschikt is. Voor grotere en complexe projecten kan een meer gestructureerde werkwijze zoals GitFlow of een andere variant geschikter zijn. Ook kan het werken met feature-branches leiden tot een versnipperde codebase en kan het moeilijker worden om wijzigingen die over meerdere branches zijn verspreid te integreren. Het is daarom belangrijk om de werkwijze te kiezen die het beste past bij de omvang en complexiteit van het project. Evalueer ook zeker de werkwijze regelmatig, zodat je deze kunt aanpassen wanneer zaken veranderen.

Wil je hier meer over weten? Neem dan contact op met onze collega Gerard!