I don't think the author understand how one is supposed to use branches and DVCS. It also compares an "ideal" situation of "trunk-development" with the worst us

I don't think the author understand how one is supposed to use branches and DVCS. It also compares an "ideal" situation of "trunk-development" with the worst usage of branches. Those unfortunate enough to have worked with CVS/SVN on a single trunk know that the ideal just does not happen and that by 2023 we know what not to do with branches (and it is perfectly realistic to avoid such mistakes). > In the branching model, large and infrequent merges can introduce bugs that are hard to identify and resolve due to the sheer size of the changes. You are not supposed to have branches that diverge too much, and if you do, what's stopping you in a centralized VCS from doing the same? I.e. having a large local changes that you did not upload back to the server. It actually makes the problem worse. > In contrast, the branching model encourages developers to create separate branches for every feature, bug fix, or enhancement. It seems the author suggesting not only a reversion the centralized VCS days but also to do it with just a trunk branch, where either each commit is made to the trunk right away (so it must be right on the first try) or you pile uncommitted changes locally. Using a DVCS and committing to the local version of the `master` branch already counts as having a branched model, except more limited. > In a trunk-based model, continuous integration becomes more straightforward because your code is committed frequently to trunk, and that's the branch your CI environment is running the build and tests on. You can run CI and test in any branch you want, and you can rebase prior to running the tests. It is not a big deal.