Feature Branch in Git: wat is het, hoe maak je het en werk je met branches

Wat is Feature Branch in Git

Feature Branch (functie branch) „ is een tijdelijke branch in Git, gemaakt vanaf develop voor het ontwikkelen van een aparte functionaliteit. In tegenstelling tot de langlevende branches main en develop, bestaan feature branches voor een beperkte tijd „ van enkele uren tot enkele weken.

Het belangrijkste doel van feature branch is het isoleren van wijzigingen die bij één taak horen van de rest van de code. De ontwikkelaar kan experimenteren, vele commits maken en zelfs code breken in zijn branch, zonder het werk van andere teamleden te beïnvloeden.

Na voltooiing van de ontwikkeling wordt de feature branch terug samengevoegd in develop via een Pull Request met verplichte codebeoordeling. Na het samenvoegen wordt de branch meestal verwijderd om de repository schoon te houden.

Volgens Vincent Driessen, 2010 is het Git Flow-model met feature branches de industrienorm geworden dankzij de duidelijke verdeling van verantwoordelijkheden tussen verschillende branchtypen.

Workflow met Feature Branch

Workflow met feature branch bestaat uit een reeks stappen die de ontwikkelaar voor elke nieuwe functie uitvoert. Dit proces minimaliseert samenvoegconflicten en zorgt voor kwaliteitscontrole van de code.

1. Branch aanmaken vanaf de laatste commit van develop. De ontwikkelaar schakelt naar develop, werkt deze bij en maakt een nieuwe feature branch.
2. Ontwikkeling en commits in de feature branch. De ontwikkelaar voert wijzigingen door, maakt commits met duidelijke beschrijvingen en pusht de branch periodiek naar de remote repository.
3. Synchronisatie met develop „ tijdens de ontwikkeling kan de hoofdbranch vooruitgaan. De ontwikkelaar voert rebase of merge develop uit in zijn feature branch.
4. Pull Request aanmaken „ wanneer de functie klaar is, opent de ontwikkelaar een PR voor codebeoordeling. Het team controleert de code en laat opmerkingen achter.
5. Samenvoegen en verwijderen „ na goedkeuring van de PR wordt de branch samengevoegd in develop en zowel lokaal als remote verwijderd.

Periodieke synchronisatie met develop is van cruciaal belang. Hoe langer een feature branch leeft zonder wijzigingen uit develop samen te voegen, hoe groter de kans op conflicten bij de uiteindelijke samenvoeging.

Frequentie van synchronisatie van feature branch

Naamgevingsregels voor feature branches

Branches benoemen „ een belangrijk onderdeel van teamdiscipline. Een uniforme naamgevingsstandaard maakt het mogelijk snel te bepalen aan welke taak wordt gewerkt en wie deze uitvoert.

• feature/naam „ het voorvoegsel feature/ wordt gebruikt in klassieke Git Flow. Voorbeeld: feature/added-auth-module.
• feature/JIRA-123-beschrijving „ koppeling aan het taaknummer in het trackingsysteem. Voorbeeld: feature/PROJ-42-add-login.
• feature/type/naam „ uitgebreid formaat met vermelding van het taaktype. Voorbeeld: feature/feat/analytics-dashboard.

Het gebruik van een taak-ID uit JIRA, Trello of een ander systeem is de beste praktijk. Het koppelt automatisch de code aan de taak en vereenvoudigt het zoeken naar branches via git log.

Pull Request proces

Pull Request (of Merge Request in GitLab) „ is een verzoek om de feature branch in develop samen te voegen. PR is niet zomaar een technische handeling, maar een teamproces van codebeoordeling dat de codekwaliteit verbetert en kennis binnen het team verspreidt.

Een goede PR bevat een titel met een korte taakomschrijving, een link naar de ticket en een beschrijving van de wijzigingen. De ontwikkelaar moet aangeven wat er precies is gedaan, welke bestanden zijn gewijzigd en of er potentiële risico's zijn voor andere delen van het project.

Het team beoordeelt de code in de PR, laat opmerkingen achter, vraagt wijzigingen aan (change requests) en keurt de samenvoeging goed (approve). Na goedkeuring wordt merge of squash merge uitgevoerd.

De gemiddelde beoordelingstijd van een PR in mobiele ontwikkeling is 4 tot 24 uur. De bibliotheek Danger automatiseert een deel van de controles door linters en tests direct in de PR uit te voeren.

Aanbevelingen voor het maken van een goede PR

• Omvang „ niet meer dan 300-400 regels wijzigingen. Grote PR's zijn moeilijk te beoordelen, de kwaliteit van de controle neemt af.
• Één PR „ één taak „ vermijd het mengen van niet-gerelateerde wijzigingen in één verzoek.
• Screenshots „ voeg voor UI-wijzigingen screenshots toe voor en na.
• Testen „ schrijf voor nieuwe functionaliteit unittesten en neem ze op in de PR.

Samenvoegstrategieën voor feature branches

Na goedkeuring van de PR kan de feature branch op verschillende manieren in develop worden samengevoegd. De keuze van samenvoegstrategie beïnvloedt de commitgeschiedenis en de mogelijkheid om wijzigingen terug te draaien.

• Merge commit „ maakt een samenvoegcommit aan, waarbij de volledige commitgeschiedenis van de feature branch behouden blijft. De geschiedenis blijft compleet, maar de vertakkingsgraaf wordt complexer.
• Squash merge „ voegt alle commits van de feature branch samen in één en voegt deze bovenop develop toe. De geschiedenis wordt schoner, maar informatie over tussenliggende commits gaat verloren.
• Rebase and merge „ herschrijft de commits van de feature branch bovenop de laatste commit van develop en voegt samen zonder extra commit. De geschiedenis blijft lineair.

Voor mobiele projecten met frequente releases wordt meestal squash merge gebruikt: het geeft een schone geschiedenis in develop, terwijl ontwikkelingsdetails in de PR-beschrijving en de trackertaak blijven.

Veelgemaakte fouten bij het werken met Feature Branch

Zelfs ervaren ontwikkelaars maken fouten bij het werken met feature branches. Kennis van veelvoorkomende problemen helpt tijd- en gegevensverlies te voorkomen.

• Te lange levensduur van de branch „ een feature branch leeft langer dan 2-3 weken zonder synchronisatie met develop, wat leidt tot massale samenvoegconflicten.
• Commits met onduidelijke beschrijvingen „ berichten zoals „fix” of „update” maken niet duidelijk wat er is gewijzigd en waarom.
• Taken vermengen „ in één feature branch worden twee niet-gerelateerde functies ontwikkeld, waardoor selectief terugdraaien onmogelijk wordt.
• Gebrek aan synchronisatie „ de ontwikkelaar voert geen git fetch uit en werkt develop niet bij, waardoor bij de uiteindelijke merge conflicten ontstaan.

De beste manier om deze problemen te voorkomen, is door aan het begin van het project afspraken te maken over werkregels en gebruik te maken van geautomatiseerde controles in de CI/CD-pipeline.

Voorbeelden van commando's voor Feature Branch

Laten we een praktisch scenario bekijken: een ontwikkelaar begint een nieuwe authenticatiefunctie in een mobiele app. Hij maakt een feature branch, werkt aan de code en voltooit de taak met een Pull Request.

# Develop bijwerken en feature branch aanmaken
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Werken aan de functie: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# Feature branch naar server sturen
git push origin feature/add-login-screen

# Synchronisatie met develop (rebase)
git fetch origin develop
git rebase origin/develop

# Na goedkeuring PR: lokale develop bijwerken en branch verwijderen
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Het commando git branch -d verwijdert de branch pas nadat de wijzigingen volledig zijn samengevoegd. Als de branch niet is samengevoegd, stelt Git voor om git branch -D te gebruiken voor geforceerd verwijderen „ gebruik deze vlag voorzichtig.

Automatisering van controles in de feature branch

De CI/CD-pipeline moet voor elke feature branch worden gestart voordat een PR wordt aangemaakt. Dit maakt het mogelijk problemen in een vroeg stadium te ontdekken, voordat de code ter beoordeling naar andere ontwikkelaars gaat.

# GitHub Actions voor controle van feature branch
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

De pipeline controleert of de code compileert, de tests slagen en de codestijl voldoet aan de binnen het team geldende standaarden. Pas na het doorlopen van alle controles kan een Pull Request worden aangemaakt.