5 ms·
I have worked at organizations that followed TBD and git-flow. TBD is much better for software that is delivered to the end user as a package ( not as a SaaS )
by simula67 10y ago
I have worked at organizations that followed TBD and git-flow.
TBD is much better for software that is delivered to the end user as a package ( not as a SaaS ), ones that does not require a staging branch
> Why are the alternatives inferior?
This is specifically useful if your working on multiple releases at the same time. With git-flow, your pull requests ade blocked for the later release until the earlier release goes out of the door. When you later merge the PRs that has to go into the later release, you get massive conflicts which waste time.
With this model, all changes are always present on trunk first and are cherry-picked onto the release branch. Release owners can selectively choose to include whatever changes they are comfortable with onto their releases. This dramatically signifies communication and management of releases.
- whack 10y ago> "This is specifically useful if your working on multiple releases at the same time. With git-flow, your pull requests ade blocked for the later release until the earlier release goes out of the door. When you later merge the PRs that has to go into the later release, you get massive conflicts which waste time." If you're doing git-flow right, your PRs shouldn't be blocked at any time. You should have a dev branch, which everyone is working off of. Any feature branches should be branched off of dev, and any approved PRs should be merged back into dev asap. Developers concerned about conflicts can also merge dev into their feature branches, on a regular basis, in order to catch and resolve conflicts early on. Creating a new release is then as simple as creating a snapshot of the dev branch. https://datasift.github.io/gitflow/IntroducingGitFlow.html https://datasift.github.io/gitflow/IntroducingGitFlow.html Gitflow and TBD are more similar than people think; TBD is essentially gitflow with the requirement that feature-branches can only live for <24 hours. Short-lived feature branches does reduce the potential for conflicts, which sounds great, except that 1) By forcing people to create multiple PRs every single day, people are spending a ton of time dealing with the PR review/discuss/update process. 2) Because many features require multiple days to develop, you're going to have a bunch of half-finished code littered all over your codebase, gated behind temp flags. If TBD was tweaked with the requirement that developers should merge commits into trunk every 7 days, I'd be all for it. 24 hours sounds to me like death by a thousand papercuts.