It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Minor niggle, but catching potential merge issues early isn't a function of your branching strategy and is easy to do without adopting TBD. Just build every branch, and merge in the trunk before you do anything else. If you've introduced a conflict or broken a test someone else wrote in the interim, you'll know about it right after you push. If you wait on testing the merge until you're ready to integrate, you could have problems across multiple commits whether your branch has been alive for hours or days.
Minor niggle, but catching potential merge issues early isn't a function of your branching strategy and is easy to do without adopting TBD. Just build every branch, and merge in the trunk before you do anything else. If you've introduced a conflict or broken a test someone else wrote in the interim, you'll know about it right after you push. If you wait on testing the merge until you're ready to integrate, you could have problems across multiple commits whether your branch has been alive for hours or days.
Absolutely, you're right on the money here. I addressed this in my other comment, but it's good to surface this point in this thread too.