Skip to end of metadata
Go to start of metadata

Every repo that the team works on should have at least three branches:

  1. production
  2. staging
  3. feature-name

Repo guidelines


  1. Avoid including files in source control that are specific to your development machine or process
  2. Delete local and remote feature branches after the feature has been deployed to production
  3. Perform work in a feature branch
  4. Use sentence case for commit messages and make them concise but usefully descriptive
  5. Rebase frequently to incorporate upstream changes
  6. Use a pull request for code reviews (thoughtbot's code review guidelines are good).

How to set up a new repo

  1. Create private repo in digital org with
  2. Remove Wikis and Issues under Settings > Options
  3. Create production and staging branches
  4. Set staging to be the default branch
  5. Delete master branch
  6. Add the Digital team as 'Admin' under Settings > Collaborators and teams
  7. Set the default branch to be protected and require pull request reviews before merging, including administrators

Continuous integration and continuous deployment

We set up a build and deploy of the production branch in Bamboo and then enable plan branches. This means that all new branches will automatically get a build plan created for them.

We use the GitHub Bamboo Service (via repo_page -> Settings -> Webservices & Hooks) to trigger a build each time a commit is made.

Commits to the production and staging branches are automatically deployed by Continuous Integration, provided they pass their unit tests and acceptance tests.

See detailed instructions on how to set this up


  • No labels


  1. Unknown User (pgw22)

    More questions:

    1. should we be squashing commits together for a pull request like in ? This makes review easier
    2. do we need a clearer set of steps on rebasing, e.g. in circumstances like this:
    1. Unknown User (pgw22)