Skip to main content

Repository Structure

Initial Build​

During the initial build of a website most work can be carried out directly on the master branch, however, feel free to create feature branches if you prefer. Remember to commit regularly.

Post Launch​

Once the site has been launched we need to be more careful with what code is deployed to the store. Going forward the repo will switch to a new structure, allowing for peer reviews and better testing.

Changes to the repository​

  • A staging branch will be created
  • New features should be done on a feature branch
  • Bug fixes should be done on a hotfix branch
  • No work should be committed directly to master
  • All feature and hotfix branches must be PR'd into master

Work flow​

When starting new work (both features and hotfixes), create your new branch off master.

Ensure that you have pulled the latest version of master before creating a branch to avoid merge issues down the line.*

Commit all of the code relevant to the feature to your feature branch (this keeps it separate from the main project).

Once you're ready to deploy your branch for testing the feature branch should be merged into the staging branch.

Never merge the staging branch into your feature branch. This can result in unfinished features from going live accidentally

The staging branch should be deployed to a staging theme, where the client is able to test all current features in one place.

Once the feature has been approved and is ready to release create a PR for the feature branch into master.

For now it is okay to self-approve your own PRs, however if you would like another dev to review the work first, tag them as a reviewer and ask them to review the code.

In the future we plan to make peer reviews mandatory

Once the work has been approved and merged into the master branch, deploy the master branch to the live theme.