Everyone that uses branches regularly probably has a naming convention they use. This is just an article saying how the author does theirs. It seems reasonable to me.
I usually just do names like `dev/short_description`, but that is still a naming convention.
Sure, I have a branch naming scheme for my repos. But nobody else has to know it because those branches don't leave my system. Branches published waiting for code review are shortlived enough even if someone notices the branch name in the review tool, they're likely not going to use it for anything.
Unless there are many long-lived, public, collaborative branches there's little need for careful and deliberate naming convention across a team. And if you have enough of those kind of branches, I contend that you're not merging enough.
From painful experience, I can say that leaving a branch that lasts longer than a day only on your machine is begging to lose work.
Unless your machine is automatically backed up every hour, in which case ignore me.
That has not been the case in most of my jobs, but pushing my WIP branch to a remote every hour or two achieves that goal in practice (as long as I don't have anything important that's not in a repo).
Branches have names regardless of if they're public or not. Every branch name was determined somehow and having shared conventions for that somehow can enable better tooling, developer interoperation, and even just personal organization.
