I disagree with the author.<p>Feature branches should not be long lived in the first place. If a feature branch encompasses more than a story of 1-5 story points it&#x27;s likely that it is too large in the first place. Once you dispel this notion that feature branches are allowed to be long lived all the other points fall as well.<p>Since feature branches are merged to master frequently the problem of integration between multiple features is mitigated. Personally I find that the extra merge commits and the commit bubbles generated by this model make the log easier to read and it&#x27;s clearer how the code came to be at the state it is.<p>Additionally the PR&#x2F;MR process codifies when code review should happen and it does not require an extra tool if a web based git UI is being used(GitLab, Github, Bitbucket). During the PR&#x2F;MR the author can create many small commits with fixes to aid the review of incremental change after the initial full review. When the PR&#x2F;MR is accepted a rebase on origin&#x2F;master and heavy use of squashing removes the extra noise created by these smaller commits as well as resolves most problems with integration into to the master branch.