Like some companies add jira id to branch name.

Sai Kishore Komanduri's photo

Engineering an eGovernance Product | Hashnode Alumnus | I love pixel art

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
Show +1 replies
klvenky's photo

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>

Sai Kishore Komanduri's photo

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.

Kleo Petrov's photo

Professional human being for 29 years

Branching convention

We (Coherent Labs) are using git flow with some small modifications:

develop and master are locked. Only accepted (reviewed by two developers) PRs can be merged.

feature/<feature-name> - every new feature will have a prefix feature

fix/<bug-name> - fixes, regressions and quickfixes.

release/<release-version> - the release branches are ready for deployment, production tested code. All tests must be passing on the latest release branch.

tests/<test-related-code> - everything test related to our test automation infrastructure - our Selenium framework, test dependencies, unit, integration and GUI tests.

experimental/<experiment-name> - every reseach, POC (Point of Concept) and other related code are done in the experimental branches. These branches are never merged in develop or master and are removed once the "experiment" is over.

Commit message convention

As for commit messages we are using the following model:

<Jira-issue-ID> <action-verb> <explanation>
<description (optional)>

For example:

[ED-666] fix exported JS code from the data-click attribute

On scene reopening, path strings were manipulated by the pathHandler method. We had to ignore paths coming from JS code in data-click. A RegExp check now filters which paths should be manipulated.

We have a Jira hook, which looks for the issue IDs in the commit messages, fetch all commits, PRs and branches and display them in the board. That way every developer and Project Manager can easily find and track the progress of the task.

Marco Alka's photo

Software Engineer, Technical Consultant & Mentor

Currently, I am settling on GitFlow, which results in

  • master (latest stable, can always be used in production)
  • develop (all the new and shiny stuff is collected here)
  • release-v1 (old stable, left there for fixing of old version)
  • release-v2 (pre-master branch for release-finalization)
  • feature-someFeature (work on some feature, usually locally)
  • fix-someBug (fix a bug, usually locally)
Pratik Upacharya's photo

Your Problem Solver

In my personal projects I follow following branch names, this is just a sample.

MAIN-DEV-WEB

MAIN-DEV-REST

MAIN-PROD-WEB

MAIN-PROD-REST

MAIN-DEV-WEB-FEATURENAME (This can be anything)

MAIN-DEV-REST-FEATURENAME

MAIN-PROD-WEB-HOTFIX

MAIN-PROD-REST-HOTFIX

This is just a sample, there are other names like integration branch, testing branch, versioning branch etc. This names depends upon the respective project.

Stephan de Vries's photo

Full stack developer, enthusiastic about new technologies.

Just like Marco, my team uses Git Flow:

  • master contains code that's currently run in production.
  • release-x.x contains code of previous releases.
  • develop contains code for the upcoming release.

Depending on the type of code we're working on, we use different branch names with the following convention:

  • fix/{name of issue} contains code for bug fixes. Often with a version prefix like fix/1.0-{name of issue} to indicate what version the fix is for.
  • feat/{name of feature} contains code for features.
j's photo
  • master <locked>
  • development <locked>

branches are constructed in the following matter

<type>/<developer>/<ticket-number>-<short-description>

feature/me/#123-adding-bla

bug/someoneelse/#124-fixing-bla

so in one year, if I'm really that slow to delete branches I can see

  • what
  • who
  • ticket number
  • what was the intention

that's maybe overhead but I like it :)

Mgbako John's photo

Full Stack Developer

Ya our projects we follow this branch naming conventions

1 - develop

2 - design

3 - master

4 - then name depending on the feature we are working on.

Clément's photo

We just started using something based on gitlab flow and I really prefer it versus the usual git flow we find. Here is the explanation: about.gitlab.com/2014/09/29/gitlab-flow.

Basically the principle is less branch better it is. And upstream first so never need to think about merging something back...

We add on that release branches.

So any change is done in master through PR.

We have feature branch which could be deploy on our staging environment to let our QA department testing it before merging into master.

Master should always be minimum stable.

On day before release we create a release branch from master where QA does regression.

When a bug which need to be fix is found we still fixing it in master and cherry-pick into release branch.

When we release we merge to the production branch (only to have an history).

It is:

  • master
  • production
  • release/4.0.0
  • feature/{jira-story-code}
  • personal branch for example for john doe would be jdoe/{jira-code}

I hope it can help