[dvdgsng]

Good for you that you found something that works for you. But why the random length restrictions to 4 chars, seems kind of outdated? Also, how does using only a "next" branch for development scale for teams (maybe using a fork-based workflow?).

While I use a similar approach like yours on my personal projects, I still prefer the widely known and battle proven Git-Flow when working on agile teams:

    - master
    - develop (optional)
    - feature/*
    - release/*
    - bugfix/* (optional)
    - hotfix/*

[franky47]

I use this pattern mostly on solo projects and small OSS libraries, when working with clients in teams there is usually already a convention in place, most often just `master` and `develop`.

I've never managed to find use in the "complexity" added by adhering strictly to GitFlow (maybe I'm working in too small teams), I don't find it suited to the continuous delivery method. I still use feature branches and hotfixes though.

I much prefer a linear history, and use semantic-release to automate releases via commit message standardisation, which gets rid of the `release/*` pattern.

[corobo]

Git flow doesn't care what you call your branches.

[dvdgsng]

correct, it doesn't, but using a quite common scheme like this makes onboarding and reasoning about git-related issues easier. YMMV.