TBD is a branching model which works fine with DVCS. I’ve used it successfully with git and it was better than the other “git/github flows.”
The point of TBD is to have well-defined branches for certain tasks or topics. Nothing is forced for how you achieve this. For example you won’t get conflicts if you have a rule to merge the master/develop/main branch, or squash or rebase your commits on your feature branch before your merge request is ready.
Also, I disagree with the person who says it’s a “developer culture problem.” IMHO it’s a branching model that should be respected in the same way we have rules for code formatting or using linters before a commit whether it’s a tool, a hook, or a check in the CI.
Overall I prefer TBD because it has fewer branches than the other methods.
I’m actually confused by the whole post.
TBD is a branching model which works fine with DVCS. I’ve used it successfully with git and it was better than the other “git/github flows.”
The point of TBD is to have well-defined branches for certain tasks or topics. Nothing is forced for how you achieve this. For example you won’t get conflicts if you have a rule to merge the master/develop/main branch, or squash or rebase your commits on your feature branch before your merge request is ready.
Also, I disagree with the person who says it’s a “developer culture problem.” IMHO it’s a branching model that should be respected in the same way we have rules for code formatting or using linters before a commit whether it’s a tool, a hook, or a check in the CI.
Overall I prefer TBD because it has fewer branches than the other methods.