Libaro docs

Appearance

On this page

Git flow ​

git-flow are a set of git extensions to provide high-level repository operations for Vincent Driessen's branching model.

Installatie ​

Keuze tussen het gebruik van commando's of software met interface.

Merge (fast-forward) nooit de remote branch in je eigen lokale branch. REBASE ALTIJD EERST VOOR JE PUSHED ​

Manueel (commands) ​

OSX ​

Homebrew: brew install git-flow-avh

Macports: port install git-flow-avh

Linux ​

apt-get install git-flow

Windows (Cygwin) ​

wget -q -O - --no-check-certificate https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh install stable | bash

Zie wiki

Software ​

Fork

Start Git Flow per project: menu: Repository->Git flow

Om een nieuwe branch te starten: rechtsklikken op een branch (master of develop) -> git flow -> start ..

SourceTree

GitKraken

Init ​

Command

git flow init

Het eerste wat je moet doen is git-flow initialiseren. Hierna zal je enkele vragen moeten beantwoorden over naming conventions voor je branches. De standaard is normaal goed genoeg:

  • Production Branch: master
  • Development Branch: develop (of development wanneer je project deze al gebruikt)
  • Feature Prefix: feature/
  • Release Prefix: release/
  • Hotfix Prefix: hotfix/
  • Version Tag Prefix: leeg

Feature ​

Feature branches starten van de develop branch en worden ook naar de develop branch gemerged. Deze branches worden gebruikt als een 'verzameling van code' voor een specifieke feature. Dit kan gelijk zijn aan een Forecast Ticket (of 'Sprint') maar dat hoeft niet.

Start ​

Command

git flow feature start MYFEATURE

Bij het starten van een feature wordt een feature/MYFEATURE branch aangemaakt, gebaseerd op develop. Deze nieuwe branch wordt ook meteen actief.

Finish ​

Command

git flow feature finish MYFEATURE

Hierbij zal de feature/MYFEATURE merged worden naar develop. Na de merge zal de feature branch ook worden verwijderd en zal develop actief worden.

Hotfix ​

Hotfix branches starten op master en worden naar master én develop gemerged.

Start ​

Command

git flow hotfix start MYHOTFIX

Hierbij zal een hotfix/MYHOTFIX branch worden aangemaakt op basis van master. Deze branch zal ook meteen actief worden.

Finish ​

Command

git flow hotfix finish MYHOTFIX

Wanneer de hotfix afgewerkt is zal deze worden gemerged in master én develop.

Release ​

Een Release branch start op develop en wordt gemerged naar master. Deze branches worden gebruikt om nieuwe productie-releases voor te bereiden, m.b.v. minor bug fixes etc.

Start ​

Command

git flow release start v1

Dit zal een nieuwe release/v1 branch maken en actief zetten. Deze branch kan gebruikt worden om een release voor te bereiden:

  • Minor bug fixes
  • Documentatie updaten
  • Migrations schrijven (indien nog nodig)
  • Controleren van release
  • Changelog bijhouden
  • ...

Finish ​

Command

git flow release finish v1

Wanneer een release klaar is zal deze worden gemerged in master en zal de merge tagged worden met de naam van de release (v1 in dit geval). De release zal ook back-merged worden in develop. Hierna zal de release branch ook worden verwijderd.

Tags

Vergeet niet om je tags te pushen.

Merge vs Rebase ​

Beide commando's zijn ontworpen om veranderingen van de ene branch in een andere branch te integreren - ze doen het gewoon op heel verschillende manieren.

Uitgebreide uitleg

Wanneer je aanpassingen van de ene branch naar de andere wil overzetten, doe je dit via een merge. De historiek van beide branches worden samengevoegd:

  • feature/MYFEATURE -> merge -> develop
  • release/v1 -> merge -> master

Een rebase naar bv master zorgt ervoor dat de hele feature branch begint op de laaste commit van de master branch, waardoor alle nieuwe commits effectief in master worden opgenomen. Maar in plaats van een merge commit te gebruiken, herschrijft rebasen de projectgeschiedenis door gloednieuwe commits te creëren voor elke commit in de originele branch.:

  • origin/develop -> rebase -> develop
  • origin/feature/MYFEATURE -> rebase -> feature/MYFEATURE

Dit doen we omdat er dan geen vervuiling is van de git historiek door Merge Commits, aangezien een rebase geen commit nodig heeft. Je baseert (based) je eigen branch als het ware op een andere (remote) branch.

Versioning ​

Het aanhouden van een duidelijke versioning kan het opvolgen en onderhouden van een project heel wat makkelijker maken.

Een goeie structuur bij deze versioning zal dus van groot belang zijn. Een voorbeeld:

21.10.2.3

In bovenstaand voorbeeld hebben de waarden volgende betekenis:

  • 21 - jaartal
  • 10 - maand (major version)
  • 2 - feature (grote releases - grote aanpassingen en nieuwe features)
  • 3 - update (kleine releases - aanpassingen aan bestaande logica)

Voor een hotfix kan het handig zijn een duidelijk onderscheid te maken, daar kunnen we nog een waarde gaan toevoegen alsook een korte beschrijving.

21.10.2.3.1_hotfix_name

We voegden hier het volgende toe:

  • 1 - patch (hotfix)
  • _hotfix_name - korte beschrijving

Deze versioning kan je telkens meegeven bij het maken van een release- of een hotfix branch.