Comment by Sai Kishore Komanduri on "Does your team follow any convention for branch names in git?"

Our (Team Hashnode) convention is quite similar to the one j mentioned.

We have two branches master and development; no direct modifications are made to these.

Side note: as soon as something is merged into development all the changes are automatically deployed to a staging server, and are available to be tested, before they are pushed to master.

We generally branch out from the latest development branch; and branches are named in this pattern: <author>/<branch-type>/<branch-name>

Here are a few (recent) examples:

somu/perf/code-splitting
alkshendra/feature/response-share-prompt
sai/misc/editor-experiments

What is the benefit to add author name to branch name?

Even we follow the same procedure exactly making our production branch and latest stable branch as protected and people review the code before they can be merged. We run the build and check if the code is as per expected standards and then the pull request gets merged. And regarding the names we almost use the same thing <Sprint>+<Jira id>

Jitendra, <author> is for maintaining a point-of-contact context, if we ever run into any roadblock with that particular branch.

Also, if you ever want to switch to a branch of an author, you don't need to remember the exact branch name, you can just find it from a list, like so: git branch --list 'sid/feature/*'. And when you know that this feature has something to do, say with the feed, you can zero in on the result even more quickly: git branch --list 'sid/feature/*-feed'

This is especially helpful when you have a long list of branches.

Search Hashnode