We currently have two different processes in place as we are transitioning between them.
The below is true for both approaches, see branching strategy below for the differences.
- As a first step, GPG key setup is required in order to contribute: instructions on setup can be found in the GPG Guide
- Pull requests must use the pull request template found in each repo. Each section must contain the following:
- 'What' - a succinct, clear summary of what the user-need is that is driving this feature change,
- 'How to review' - a step-by-step guide or set of guides that detail how a reviewer can test and verify the changes made
- 'Who can review' - a list of the most appropriate people to review the pull request, e.g. if on a frontend application, a member of the frontend team should review; likewise for backend and platform. If the changes are critical or are likely to have severe side-effects then the Tech Lead should review.
- Ensure your branch contains logical atomic commits before sending a pull request - follow the GDS Way styleguide
- You may rebase your branch after feedback if it's to include relevant updates from the upstream branch. We prefer a rebase here to a merge commit as we prefer a clean and straight history on protected branches, with discrete merge commits for features
- It is advised to squash commits before pushing to a remote repository
We use trunk based development - create a feature branch from main, e.g. feature/new-feature
We use git-flow - create a feature or fix branch from develop, e.g. feature/<new-feature>, fix/<new-fix>. Alternatively, create a hotfix branch from master e.g. hot-fix/<new-hotfix>.
For instructions on how to release work, read the Releases guidelines
Note: if you get a 404 error for any of the below links, then you need to be added to the ONSdigital organisation in GitHub
- For direct access to the environments
- Setup your AWS credentials
- Configure your SSH access
- Ansible is required for provisioning to environments