Ik krijg nog steeds de vraag waarom en hoe over te stappen van TFVC naar GIT als source control systeem. Bij een dergelijke overstap is een vaak gehoord geluid dat dit lastig is omdat de terminologie anders is en elke verandering vaak weerstand op werpt.

Waarom overstappen naar GIT?

Om deze weerstand eerst maar eens te vergroten en omdat het fijn is om te lezen dat iemand je gelijk geeft: Inderdaad, het is in het begin lastig, maar het moet wel omdat de hele wereld overstapt en omdat Microsoft het zegt. 😊 Ook de recente overname van GitHub door Microsoft is een extra reden om nu toch echt over te stappen. Als laatste reden kan gegeven worden dat GIT ondersteund wordt door de meeste development tooling en andere third party integraties.

TFVC	GIT
Changeset	Commit
Get Latest	Pull
Checkout	Edit
Set active branch	Checkout
Checkin	Push (pull is mandatory first)
Label	Tag
Rollback	Revert
Code Review	Pull Request

Een overzicht van de belangrijkste verschillen:

TFVC	GIT
Server changes	Local changes
Conflicts at checkin	Conflicts at pull
Server branches (path based and heavy)	Local branches (no path and lightweight)
Server historie	Local historie

Voor meer hulp bij het mappen van TFVC commando’s en workflow naar GIT kun je de documentatie en how-to guides van Microsoft raadplegen: https://www.visualstudio.com/en-us/articles/mapping-my-tfvc-actions-to-git

Als je jezelf en je team dan hebt overtuigd om over te stappen. Hoe ga je dan te werk? Om te beginnen zal iedereen de basics van GIT moeten gaan leren begrijpen. Een goed start punt is de learning GIT website van GitHub met allerlei resources over GIT en hoe GIT onder de knie te krijgen. https://try.github.io/

Daarnaast is er een leuke mooie video op YouTube te vinden die de basics van GIT uitlegt. Deze video duurt wel ongeveer 55 minuten, maar lui als we zijn 😊, is dat misschien juist een prettige manier om kennis te maken met GIT: https://www.youtube.com/watch?v=Dv8I_kfrFWw

Tot slot is een keuze voor een branching model erg belangrijk en goed om wat langer over na te denken. Alle teamleden dienen de keuze voor een model te begrijpen en ook daadwerkelijk te volgen. Dit lijkt een logische uitspraak, maar in de praktijk wordt hier toch vaak van afgeweken. Vaak is dit niet noodzakelijk en wordt er onnodig afgeweken van het afgesproken model terwijl het model juist wel zou passen als je wat langer nadenkt over de vraag of bijzondere situatie. Wordt er wel afgeweken komen andere processen zoals deployment vaak in het geding en moeten hier ook uitzonderingen op gemaakt worden die weer extra tijd kosten. Het is dus van groot belang hier goed over na te denken en een goede keuze te maken. Een goed referentie artikel op internet kan als startpunt dienen: http://nvie.com/posts/a-successful-git-branching-model/

Een common veel gebruikt model is het master, development, feature model. Er is een master branch die gebruikt wordt om releases te deployen, en er wordt ook alleen uit deze branch gedeployed. Vanaf de master branch wordt een develop branch gemaakt. Vanuit hier worden per te bouwen functionaliteit (nieuw of uitbreidingen of hotfixes) feature branches gemaakt die individueel ontwikkeld en getest worden. Als deze goedgekeurd zijn worden ze met een pull request (code review) naar de development branch gemerged voor de integratietesten met andere functionaliteiten. Als ook deze testen zijn goedgekeurd wordt het geheel (bijvoorbeeld van 1 sprint) ook via een pull request naar de master branch gemerged voor een volgende release. Een bekende naam voor dit model is GitFlow.

Tools

Daarnaast bieden Azure DevOps en Azure DevOps Server een import functionaliteit om TFVC respositories om te zetten in GIT. Hier zijn echter wel een aantal voorwaarden aan:

•  Er kan maar 1 branch geïmporteerd worden.
•  Er kan maar een beperkte hoeveelheid historie geïmporteerd worden.
•  Je mag geen grote binary bestanden in je repository hebben staan.
•  De maximale grote van de repository is 1 GB.