Implementing GitHub flow in Bitbucket

April 20, 2020

Why GitHub flow

GitHub flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. This guide explains how and why GitHub flow works and how to implement it in Bitbucket Server with Snake CI add-on installed.

While out-dated workflows such as GitFlow offer a complicated structure with feature-, hotfix-, release-, and even specialized develop branches, GitHub Flow offers a much simpler alternative — having only feature & master branches.

The workflow consists of the following steps:

  • Push changes to branch and create a Pull Request
  • Wait for build to pass on CI servers
  • Discuss and review your code
  • Deploy it
  • Verify that the changes work and fix problems that come up
  • Merge branch into master

How to do it with Bitbucket Server

The solution to implementing the GitHub workflow on self-hosted Bitbucket Server / Data Center comes with our latest release of Snake CI — 0.3.0.

In this release, we have improved Conditional Jobs and especially only:variables section that has a new level of restrictions — required variable.

Read more about this feature in our technical docs.

Now you can have a Pipeline Job that will be executed only if one of the specified variables was passed via Environment Variables or by a user via Bitbucket UI in the New Pipeline dialog.

Let’s go through the steps.

Step 1: Preparation

Create a simple repository & push a simple snake-ci.yaml config with the following contents:

image: alpine

  - build
  - test
  - deploy

build code:
  stage: build
    - echo Building the code...

test code:
  stage: test
    - echo Running unit tests...

deploy code:
  stage: deploy
      - "$DEPLOY"
    - echo Deploying the package to ${DEPLOY} environment

Here in the example, we print messages instead of building/testing/deploying code to keep it as simple as possible.

Step 2: Make the changes

Create a branch, add some commits, and push it to the Bitbucket repository.

Take a look at the git push's response because it contains a lot of useful links such as:
  • Link for creating the Pull Request
  • Link on the Pipeline caused by your git push

Step 3: Create a Pull Request

Create a Pull Request from the feature branch into the master branch. Discuss and review your code.

Notice that you are not able to merge your changes into the master branch if the pipeline has failed.

Step 4: Deploy it

Deploy your changes by specifying the target environment in the New Pipeline dialog and put identifier of the target environment into the DEPLOY variable.

For example, it could be production, staging, or even some unique identifier or your target cluster.


If your branch causes issues, you can roll it back by deploying the existing master into the production environment.

Step 5: Merge it

Now when you deployed your feature branch into the target environment, and the changes have been verified, it’s time to merge your code back to master by clicking Merge button on the Pull Request page, and jump on the next task.

Still have questions?

If you need assistance or want to say hi, contact us:

Start building faster. Today.

Free 30-days trial.