Git Workflow

From A-Eskwiki
Jump to: navigation, search

Omdat Git zo'n flexibel systeem is, zijn er heel veel manieren om erin je revisiegeschiedenis bij te houden. Dus om te voorkomen dat het allemaal een zooitje wordt, leek het mij een goed idee om er afspraken over te maken.

Dit is mijn eigen idee van hoe ik het graag zou willen, maar jullie kunnen gerust je eigen suggesties doen, in de pagina zelf of op de talk page.

Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)

Pull Requests

Als je een branch wil mergen, doe dit dan altijd via een pull request. Dan kunnen andere WebCie'rs ook de code checken op bugs of stijlfouten.

Branches

develop
Hier staat code op die in principe werkt, maar een foutje kan natuurlijk altijd gebeuren, en dat is niet erg. Als het maar gefixt wordt voordat er naar master wordt gemerget.
master
De code die hier op staat moet zeker wel werken, en op ieder moment live gezet kunnen worden. Je kan hotfixes hierop committen, maar let dan goed op dat ze werken, en houd de commits klein!
feature-$bla
Maak een nieuwe feature branch vanaf develop wanneer je een niet-miniscule feature gaat toevoegen. Zodra je feature klaar is, zorg je eventueel dat ie een beetje netjes is met git rebase, en vervolgens merge je 'm terug naar develop.
refactor-$bla
Als je meer in het algemeen wilt refactoren, kan je daarvoor ook het beste een aparte branch maken, zodat er niet teveel ruis op develop is en zodat je er een pull request van kan maken.

Doetjes & Doe-nietjes

  • Doe: pull met een rebase (git pull --rebase; ik heb zelf een shorthand hiervoor ge-aliased). Merge commits tussen een lokale en remote versie van een branch zijn in 99% van de gevallen onnodig, en in die 1% dat er een substantieel verschil is tussen je lokale code en de remote (die ook niet makkelijk te rebasen valt), heb je gewoon teveel geschreven zonder te pullen, pannekoek!
  • Doe: merge altijd met git git merge --no-ff. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat git bisect en git blame wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld
  • Doe: als een feature branch waar je mee bezig bent nogal achterloopt op develop, kan je die rebasen op develop (en vervolgens force-pushen), mits je de enige bent die een lokale checkout van die branch heeft. Nadruk op mits.
  • Doe-niet: git cherry-pick. Dit zorgt voor erg veel redundancy in de history, waardoor het een stuk minder overzichtelijk wordt. Een uitzondering is als je per ongeluk toch een hotfix op develop hebt gezet; dan mag die wel naar master ge-cherry-pickt.