Branches

You will encounter four different branches in the BAO repositories: master, staging, feature and hotfix.

master

The master branch (in some repos develop) is the main branch for the project. This should contain all of the code for the current live site. During initial development this may be the only branch you see, and all work can be committed directly to it.

Once the site has gone live the master branch will become protected, this means that code cannot be directly committed to this branch, and any new work must be added via a peer review (PR).

When deploying to the live theme, you should only ever deploy from master, this ensures that all current work will be deployed.

staging

Once the site has launched the staging branch will be created in the repository.

The purpose of this branch is to provide a single branch containing all of the current features in development. This will allow the client to test everything in one place, rather than having to jump between themes.

All feature branches should be merged into staging and deployed to the Staging theme for testing before being PR'd into master.

Never merge the staging branch into your feature branch. This will add any code changes from other outstanding features into your branch, and when your branch is merged into master those changes will be added along with it.

feature

feature branches should be created for any new pieces of work.

Feature branches should always be created off master to ensure they are up to date with the current live site. Ensure you pull master before creating the new branch.

When creating your branch give it a short, descriptive title, for example if you are adding an image gallery to the PDP use feature/pdp-image-gallery. Other developers should be able to read the branch name and know what it has been created for.

Continue to commit any code related to the feature to your new branch. Avoid committing unrelated changes - if you've been asked to make a small change elsewhere on the site while you're working on a feature, commit your current progress, create a new branch for the small change, complete that, then switch back to your original feature.

Once you have finished your work merge your feature branch into the staging branch and deploy it from there to be tested or create a new theme, whichever is more appropriate..

Any changes requested to the feature after testing should be done back on the feature branch, and merged into staging again. Do not make these changes on the staging branch as they won't then be merged into master.

Once the feature has been approved by the client create a PR for the feature branch into master. Currently it's up to you if you want another developer to review your code, but in the future peer reviews will be mandatory.

Once the PR has been approved and merged remember to delete the feature branch to keep the repository tidy.

hotfix

hotfix branches should be used for small bug fixes on the live site.

Hotfix branches work in a similar way to feature branches; they should be created off the latest version of master and contain only changes relevant to the bug. Ensure you pull master before creating the new branch.

As with feature branches, give it a short, descriptive name related to the bug it is fixing.

When deploying a hotfix branch for testing you can either merge it into staging or create a new theme, whichever is more appropriate.

Once the fix has been approved it should be PR'd into master, in the same way you would a feature branch.

The reason we use hotfix branch is to quickly differentiate between new features or bug fixes.