Git Workflow - Revision history

Daanr: /* Doetjes & Doe-nietjes */

2018-01-23T00:47:20Z

‎Doetjes & Doe-nietjes

Daanr: /* Doetjes & Doe-nietjes */

2018-01-15T18:45:22Z

‎Doetjes & Doe-nietjes

Daanr at 18:43, 15 January 2018

2018-01-15T18:43:01Z

Daanr: /* Branches */

2018-01-15T18:40:53Z

‎Branches

Daanr: /* Doetjes & Doe-nietjes */

2018-01-15T18:38:36Z

‎Doetjes & Doe-nietjes

Daanr: Schrijf die shit

2017-11-20T22:52:23Z

Schrijf die shit

Daanr: /* Branches */

2017-11-20T17:37:46Z

‎Branches

Daanr: Created page with "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 m..."

2017-11-20T17:37:15Z

Created page with "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 m..."

New page

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

== Branches ==
;develop
:
;master
:
;feature-$bla
:
;bug-$bla
:

== Dos & Don'ts

[[Category:WebCie]]

@@ Line 24: / Line 24: @@
 * '''Doe''': pull met een rebase (<code>git pull --rebase</code>; 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 <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> 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.
+* '''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''': <code>git cherry-pick</code>. 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.
 [[Category:WebCie]]

@@ Line 23: / Line 23: @@
 * '''Doe''': pull met een rebase (<code>git pull --rebase</code>; 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 <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld.
+* '''Doe''': merge altijd met git <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld
 * '''Doe-niet''': <code>git cherry-pick</code>. 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.
 [[Category:WebCie]]

← Older revision		Revision as of 18:43, 15 January 2018
Line 4:		Line 4:

	Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)		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 ==		== Branches ==

@@ Line 13: / Line 13: @@
 ;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 <code>git rebase</code>, en vervolgens merge je 'm terug naar develop.
 == Doetjes & Doe-nietjes ==

@@ Line 17: / Line 17: @@
 * '''Doe''': pull met een rebase (<code>git pull --rebase</code>; 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 <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat bisecten en blamen wat moeilijker gaat, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld.
+* '''Doe''': merge altijd met git <code>git merge --no-ff</code>. Hierdoor kan je altijd zien wanneer er een merge is geweest. Het nadeel is wel dat <code>git bisect</code> en <code>git blame</code> wat moeilijker gaan, omdat merge commits ook in de geschiedenis van een bestand worden meegeteld.
 * '''Doe-niet''': <code>git cherry-pick</code>. 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.
 [[Category:WebCie]]

@@ Line 3: / Line 3: @@
 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
+Zie ook: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows (maar we volgen dit systeem niet precies)
 == 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 <code>git rebase</code>, en vervolgens merge je 'm terug naar develop.
-;bug-$bla
+== Doetjes & Doe-nietjes ==
-== Dos & Don'ts ==
+* '''Doe''': pull met een rebase (<code>git pull --rebase</code>; 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!
 [[Category:WebCie]]