How I learned to stop worrying and push to master
I, for one, will never understand how Trunk Based Development (TBD) is considered &quot;sane default&quot; these days. The power of version control isn&#x27;t just in a record of history, it&#x27;s also in branching; and most often, I&#x27;ve noticed developers move to TBD because they don&#x27;t understand the intricacies of their version control system and how to leverage it for a proper async parallel development workflow. You don&#x27;t need to adopt GitFlow or another workflow verbatim, understand how you want to deliver software and work within the team so that you can adapt it to your requirements.<p>The points made by the author are confusing to me.<p><pre><code>   Quality Assurance was under-resourced. They had a huge job of checking and re-checking every feature to verify that there were no regressions. After merging a feature into develop, they had to check again to see if there were any new issues that were introduced by bad merges or conflicting feature requirements.
</code></pre>
If this was the case and they were fine with QA testing just the `master` branch after moving to TBD, maybe QA shouldn&#x27;t have been testing their feature branches in the original workflow. Just use branches for proper code review and then QA only steps in after the branch is merged?<p><pre><code>   The threshold of conflict was amplified by the time that passed between when a branch was cut from develop to the time when it was merged back.

   For bigger features, a branch&#x27;s life could last one or even two weeks. The more time that passed, the greater divergence there would be from the other code.
</code></pre>
Feature branches should be short-lived, as atomic as possible. And if you&#x27;re working on a big feature, you have to update your branch frequently with upstream changes. Merges of Doom only happen if you&#x27;re not following version control best practices.<p>This also requires a little bit of planning upfront (especially if you&#x27;re working in parallel on a single feature), but forcing that thought is a good thing.<p>It also seems like they attributed moving to Kanban as only being possible due to the move to TBD, but it&#x27;s not like it&#x27;s impossible with a proper branching workflow.<p>So, the author made the switch to TBD and attributed it to increased velocity and better _overall morale_, but I think they&#x27;re just enjoying the seemingly greener grass across the fence for a while.