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