<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gitflow on dotkarl</title><link>https://www.karlvanheijster.com/tags/gitflow/</link><description>Recent content in Gitflow on dotkarl</description><generator>Hugo</generator><language>nl-NL</language><lastBuildDate>Fri, 09 May 2025 07:55:13 +0200</lastBuildDate><atom:link href="https://www.karlvanheijster.com/tags/gitflow/index.xml" rel="self" type="application/rss+xml"/><item><title>Feature branches belemmeren een beter begrip van koppeling</title><link>https://www.karlvanheijster.com/blog/25/05/feature-branches-belemmeren-een-beter-begrip-van-koppeling/</link><pubDate>Fri, 09 May 2025 07:51:17 +0200</pubDate><guid>https://www.karlvanheijster.com/blog/25/05/feature-branches-belemmeren-een-beter-begrip-van-koppeling/</guid><description>Laatst brak een kleine wijziging aan de back-end &amp;ndash; die we zo snel mogelijk richting de testomgeving hadden gebracht &amp;ndash; functionaliteit aan de front-end. Voor mijn collega was het een ideale gelegenheid om zijn &lt;em>bias&lt;/em> voor Gitflow bevestigd te zien. &amp;ldquo;Dit zou nooit gebeurd zijn als we van &lt;em>feature branches&lt;/em> gebruik hadden gemaakt!&amp;rdquo; concludeerde hij. &amp;ndash; En niet onterecht, want het apart houden van de wijziging in kwestie zou de functionaliteit op testomgeving inderdaad intact hebben gehouden.</description></item></channel></rss>