How I established a good release process in JavaScript

With Git Workflows, NPM, and 3rd party libraries

Photo by rawpixel on Unsplash


Two Types Of Branches

Infinite lifetime branches: master and develop

  • origin/master is always production ready.
  • origin/develop always includes the latest delivered changes for the next release. When it’s ready, it’s merged to master and the changes are tagged with a release number.

Limited lifetime branches

  • Feature branches
  • Release branches
  • Hot-fix branches

Feature Branches

  • Branched off from and merged back to develop.
  • Naming convention: anything except master, develop, release-*, or hotfix-*. I love to use the prefix feature/, for example feature/fix-texts.

Release Branches

  • Branched off from develop and merged back to develop and master.
  • Naming convention: release-*, for example: release-1.2.
  • Purpose: last minute small changes, so that develop is clear to receive changes for the next release.


> npm version patch

Back To Release Branches

Creating a Release From Tag

Merge Back To develop

Hotfix Branches

  • Contain fixes for urgent production bugs.
  • Branched off from master, and merged back to develop and master.
  • Naming convention: hotfix-*.

Is That So?



Photo from the great project


“Having code in a common place where it’s not fully tested and not necessarily working towards a feature that is to be released ends up being a ghost town of half-completed architectures and not-released features if the team is ever busy.”


“The general feeling is that git-flow works well for products in a more traditional release model, where releases are done once every few weeks, but that this process breaks down considerably when you’re releasing once a day or more”.


“Remember that these workflows are designed to be guidelines rather than concrete rules. We want to show you what’s possible, so you can mix and match aspects from different workflows to suit your individual needs. When evaluating a workflow for your team, it’s most important that you consider your team’s culture.”

“There is no one size fits all Git workflow. It’s important to develop a Git workflow that is a productivity enhancement for your team. In addition to team culture, a workflow should also complement business culture. Git features like branches and tags should complement your business’s release schedule.”

Squashed commits or not?

  1. With indicative messages and not “wip”, “fix”, etc.
  2. Every commit on its own does not break the build or the product, i.e., if a feature contains 3 commits, and we revert 2 of them, the product is stable and working well.


The link to semver is in GitHub’s release page (bottom right corner)

JavaScript Versioning

Updating External Libraries Should Not be Part of Your Git Workflow

“dependencies”: { 
“my_dep”: “^1.0.0”,
npm install foobar --save --save-exact
npm config set save=truenpm config set save-exact=true
  • “A lock file [package-lock.json] will lock down the exact dependencies and sub-dependencies that your project uses, so that everyone running npm install will install the exact same dependencies as the person that last updated the lock file.” You can see why it’s problematic not to use your lock file — things might break in production due to a change in some dependency, and it will be very hard to track the problem, because you’ll have a different version of this dependency on your local environment.
  • A lock file isn’t made to be human-readable. In case a new version of a third-party library you use is released, and it’s within the range of the allowed versions in the package.json file, the package-lock.json will make sure everyone just uses the fixed version that has been defined when it was last updated. For example, in your package.json you have this definition:
“dependencies”: { 
“my_dep”: “^1.0.0”,
  • The usual recommendation is to use a lock file regardless of whether you pin dependencies or not, and pinning even if you have a lock file.


  1. It’s important for any engineer to know different Git workflows, and to understand the semver methodology and how to use lock files.
  2. Different teams need different workflows. It depends on the market and the team, and the workflow should make life as easy as possible for the engineers using it, allowing them to release stable code fast.
  3. I think the closest workflow to what I want to work with is described in this article — Feature Branch Workflow.
  4. It’s nice to use semver and fixed versions, together with a service that helps upgrading third party libraries.
  5. I’m a great fan of design patterns and I loved reading the different patterns to work with Git.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dafna Rosenblum

Engineering Manager at Kry. Co-Founder of Podcasting @extend_podcast. Twitting @dafnaros.