Skip to content

Branches

Relationships between branches

Depending on the type of repository, we may have different levels of quality, informing what branch we should work in:

  • main
  • staging (optional)
  • dev
  • feature branch
  • sub-feature branch (optional)

main or release

This branch should contain official code. Its content or content deployed from this repo should be visible to all stakeholders. Code that gets merged in this branch should have been tested thoroughly.

staging (optional)

For repositories containing code to be deployed as a platform, and depending on the used workflow in a particular project, we might need to have a staging step in order to publish content for user-testing or validation before going public. In this cases we use a staging branch between the development branch (dev) and the official branch (main).

This branch is usually derived from main or release and deployments of its content could be visible to stakeholders. The code that gets merged in this branch should have been tested as much as possible.

We should use this content for user-testing. When we have to develop fixes or add new content we should branch dev off staging and work in dev.

dev

This should derive from staging or main if we have no staging branch. This is work in progress and content deployed from it should be visible to the development team or to internal stakeholders (for example testers in Nesta). Code in this branch should be tested before being merged to staging or main/release.

We should use this content for developer testing and testing internal to Nesta. When we have to make changes to this content, we branch off a feature branch from the most recent version of dev.

Feature branch

When we have to develop a new feature or a fix, we pretty much follow the Github workflow, with the exception that we branch off from dev rather than from directly from main, see this page

Sub-feature branch (optional)

When a feature is particularly complex, we might subdivided it into many issues and work in sub branches, merging the work from each sub-feature branch.

Commits in the sub-feature branch should be squashed before being merged to the feature branch, but when we then merge the feature branch to dev we might want to avoid squashing it so that the commits in the sub-feature branches remain, to keep track of how that complex feature came to be.

Tags

These branches should contain released material and should branch off from main.

When we need to deploy an application or mention some content from a repo in an external document, we need to make sure that its position in the repo or its content won't change over time.

To do so, we tag from main and eventually make a new release.

Switch to the main branch:

git checkout main

Tag:

git tag -a v1.4 -m 'version 1.4'

Push it to Github:

git push origin v1.4