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.
Regarding section 1, won’t you still get the conflicts when pushing to remote (or pulling from it)?
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.