I can't see the purpose of adding something in front of a branch, to mark a branch. Usually the feature name with, if applicable, a number of the tracking system (e.g. bug number). That does the job for me in almost any case... This is how I've been handling it at my previous job at Catalyst IT and here at BYOI now.

If it comes from a project management tool such as Jira or Clubhouse, I normally start the name of the branch with the ID of the card in the tool:

• LPF-129-save-draft-of-form

But if there's no ID to relate, I just use the feature or the thing to do in the name:

• save-draft-of-form

BTW, starting a branch name with b/ is quite weird because you know it's a branch from the get-go.

Gaurav Dnyandeo Kukade,

We generally separate it out feature and bugfix wise.

The branch name for feature branches look like,

• feature/<Feature_ID>-<Feature_Summary>

For bugfixes,

• bugfix/<Bug_ID>-<Bug_Summary>

Apart from these we got,

• master as the base branch

Also the release branches as,

• release\1.0.0.0
• release\1.1.0.0 and so on..

I just write my feature name and the problem I am resolving form it. It would be something like: notifications-color

But i'm realizing your great ways of doing this. I will apply them.

Starting branch names with b/ is a bit strange, since you already know that it's a branch, right? I'd decide for a branching strategy first and then base the names on that.

---

We usually follow git-flow, so we have develop for integration, feature/XXXX for feature development and bug fixing, release/XXXX for QA and release-preparation work, master for productive code and hotfix/XXXX for hotfixes.

As for the individual name part (XXXX in the above naming convention), we usually work with Jira, so we have an issue ID and then a very short description. For example, one of our branches might be called feature/PROJECT-1234-implement-back-to-top. That way, we can even track branches in Jira.

---

Other than git-flow, there is for example master-centric development, which makes master the integration branch and whenever you release code, you branch off into a release/VERSION branch for every version. The feature branches usually are the issue-id plus a short description. This allows for better support of multiple versions, however means that you have additional burden per released version. From the top of my head, Amethyst uses such a branching strategy for their game engine, which allows them to offer and support several versions in parallel.

This is a high level of the branching strategy the company I work at and I utilise: There are story branches which are basically features and the branch looks like this:
story/{PROJECT_INITIALS}-{ISSUE_NUMBER}-{ISSUE_NAME}.

So using My Awesome Project and issue or ticket number 134 (jira, gitlab, github, notepad) and the name could be Create landing page:
story/MAP-134-create_landing_page.
Then this story gets split into smaller sub-tasks which are as trivial as possible. So, following the same convention as above, a sub-task would look like this:
sub-task/MAP-135-create_navbar_item.
Defects would look like this:
defect/MAP-136-fix_padding_on_nav_items.

master/ is the release branch.
story/ and defect/ branches come off master.
sub-task/ branches only come off story/ branches.