Why you should avoid complex branching
When we talk about branches, we often use the terms long-lived and short-lived, which refer to time. I find this somehow misleading. Branches are about changes, and changes can hardly be measured in time. Developers can write 8 hours of code with a lot of refactoring and try to merge that very complex branch in 1 day. This would still be considered short-lived if they measured it in time only. Conversely, if they have a branch with just one line changed—for example, the update of a package that the code depends on—but the branch stays open for 3 weeks as the team must solve some architectural questions regarding the change, from a time perspective it would be long-lived, even if it would be very simple to rebase the changes on top of main.
Time doesn't seem to be the best measure to distinguish good and bad practices for branches; it is a combination of complexity and time.
The more changes that happen in the base branch...
