Show HN: Why you should not use feature branches
I like TBD -- a lot.  However there are a couple of problems with it.  If your team is not collocated in a time zone then you&#x27;ll one one guy (me, for instance) who will push 8 hours of development into trunk without anyone else getting a chance to look at it.<p>The same thing happens if you have someone who just &quot;disappears&quot; for a day or two and effectively has a feature branch.  You need to have discipline on your team to push often (I like to push at least every 20 minutes).<p>I also tend to think that continuous deployment with TBD is risky.  It depends on how good your automated acceptance tests are, but I tend to like to do a manual sanity check before deployment.  It&#x27;s a lot easier when you are not working on a moving target.<p>Finally, sometimes you just <i>have</i> to break something in order to change its direction.  This forces you into a feature branch if you are doing continuous deployment.<p>We&#x27;ve occasionally experimented with having an &quot;integration branch&quot; that acts like trunk but isn&#x27;t deployed.  You can then time your trunk deployments, potentially cherry picking from the integration branch.  It seems like a good solution, but I&#x27;ve found it to be more trouble than its worth most of the time.<p>Having said all that, my preference would be to abandon continuous deployment and instead have regular deployment (say once a week or once every 2 weeks) with a mechanism for hot patches.  Then force everyone to work mostly core hours and have continuous integration (with commits coming in every 5 minutes or so).  In my experience this has produced dramatically better results than feature branches.<p>However... On my team it is impossible (not least because I&#x27;m 9 time zones away from the majority of my team mates).  So feature branches are an acceptable second best.