Maintainers
TAYO Methodology
"Test As Your Own"
Table of Contents
Concept
The TAYO Methodology is a way to manage branches in a Git repository. It is based on Git Flow and Conventional Commits (with few changes), the main one is the idea that the developer should be able to test their own code before it is merged into the development branch. This is done by creating a branch specifically for testing called the test branch. The test branch is a branch that is created from the develop branch and is used to test the code before it is merged into the develop branch. The test is a temporary branch that is deleted after the code is merged into the develop branch. You should never merge the test branch into develop or master.
Branches
Master
The master branch is the branch that is used for production. It is the branch that is used to deploy to production. The master branch should never be updated directly. The master branch is only updated by creating a pull request from a release branch.
example: master
Develop
The develop branch is the branch that is used for development. This will be created from the master branch. The develop branch is the branch that is used to deploy to development. The develop branch should never be updated directly. The develop branch is only updated by creating a pull request from a feature, bugfix, or hotfix branch.
example: develop
Release
The release branch is the branch that is used to create a release. This will be created from the develop branch. The release branch is the branch that is used to deploy to staging. The release branch should never contain any new features or bug fixes. The release branch is only used to update the version number, update the changelog, update the documentation, and sync changes from production (if needed, for example, BigCommerce sites where customers have access to modify the theme).
Once time a release is ready you should create a pull request to develop and master.
The name of this branch will contain the version number of the release. The version number should follow the Semantic Versioning standard.
example: release/1.2.0
Feature
The feature branch is the branch that is used to create a new feature. This will be created from the develop branch. The feature branch should contain only the code for the new feature. After the feature is complete you should merge the feature branch into the test branch, this will allow you to test the feature before it is merged into the develop branch. In the meantime, you should create a pull request from the feature branch into the develop branch as a draft. This will allow you to get feedback from the team on the feature.
The name of this branch should contain the ticket number (when using Jira tickets) and for some projects, you will need to use a GitHub issue number.
example: feature/ABC-123
Bugfix
The bugfix branch is the branch that is used to create a bug fix. This will be created from the develop branch. The bugfix branch should contain only the code for the bug fix. After the bug fix is complete you should merge the bugfix branch into the test branch, this will allow you to test the bug fix before it is merged into the develop branch. In the meantime, you should create a pull request from the bugfix branch into the develop branch as a draft. This will allow you to get feedback from the team on the bug fix.
The name of this branch should contain the ticket number (when using Jira tickets) and for some projects, you will need to use a GitHub issue number.
example: bugfix/ABC-123
Hotfix
The hotfix branch is like the bugfix branch but it is used to fix bugs in production that need to be fixed immediately. This will be created from the master branch. The hotfix branch should contain only the code for the bug fix. After the bug fix is complete you should create a pull request from the hotfix branch into the develop and master branches as a draft. This will allow you to get feedback from the team on the hotfix.
As this branch will be merged into master it works as a release branch, so you should update the version number, update the changelog, update the documentation and sync changes from production (if needed, for example, BigCommerce sites were customer have access to modify the theme).
The name of this branch will contain the version number of the release. The version number should follow the Semantic Versioning standard.
example: hotfix/1.2.1
Support
The support branch is the branch that is used to support a specific version of the theme. This will be created from the master branch. The support branch should never be updated directly. The support branch is only updated by creating a pull request from a bugfix branch. support branch will follow the same concept as the master branch, it will remain active as long as that version is being supported.
The name of this branch will contain the version number of the release that you are giving support to. The version number should follow the Semantic Versioning standard.
Example: support/1.2 or support/1.2.x
Test
The test branch is the branch that is used to test a feature or bug fix. This will be created from the develop branch. The test branch should be updated by merging the feature or bugfix branch into the test branch. After the release is completed and merged into the develop branch the test branch should be deleted.
The name of this branch will contain the version number of the next release. The version number should follow the Semantic Versioning standard.
Example: test/1.2.0 or test/1.2.0-beta or test/1.2.0-alpha (We recommend adding the -alpha or -beta to the version number)
Why use the test branch?
The purpose of the test branch is to allow the developer to test their own code before it is merged into the develop branch. This was born out of the need for QA to be able to test changes before being merged into the develop branch, in order to avoid creating new tickets every time feedback needs to be worked on.
The only changes you would make to this branch would be to update the version to something like 1.2.0-beta.1, this branch will always contain an alpha or beta version that will reflect the release, so once the release is finished it will be 1.2.0.
Sync
The sync branch is used to merge the latest changes from a site that is in production and thus avoid the loss of changes when developing a new feature. Additionally, it will decrease the amount of code within a PR, making the code review process more efficient. After obtaining the latest changes from production, a PR is created to merge the branch with develop.
The name of this branch will contain the version number of the current applied theme.
example: sync/1.2.0
Conventional Commits
The TAYO Methodology uses a variation of Conventional Commits to help identify the type of commit. The TAYO Methodology uses the following types:
Types
feat: A new feature (this will create a minor version bump)fix: A bug fix (this will create a patch version bump)perf: A code change that improves performance (this will create a patch version bump)refactor: A code change that neither fixes a bug nor adds a feature (this will create a patch version bump)style: Changes that do not affect the meaning of the code (white space, formatting, missing semi-colons, etc) (this will create a patch version bump)docs: Documentation only changes (this will create a patch version bump)chore: Changes to the build process or auxiliary tools and libraries such as documentation generation (this will create a patch version bump)ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) (this will create a patch version bump)build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) (this will create a patch version bump)test: Adding missing tests or correcting existing tests (this will create a patch version bump)revert: Reverts a previous commit (this will create a patch version bump)
Scopes
The scope of a commit is the part of the code that is affected by the commit. The scope should be a single word that describes the part of the code that is affected by the commit. The scope should be in lowercase and should not contain any spaces.
This can change depending on the project that you are working on. But the following are some examples of scopes that you can use:
Common
homeproductcartcheckoutaccountblogpages
BigCommerce
widgets
Tickets
If the commit is related to a ticket you should add the ticket number to the commit message. This will allow you to link the commit to the ticket.
Example: feat: ABC-123 add a new feature to the home page
Breaking Changes
If there are breaking changes in the commit you should add BREAKING CHANGE: to the commit message. This will create a major version bump and add a description of the breaking changes to the commit body.
Examples
- feat(home): ABC-123 add new feature
- fix(cart): ABC-123 bug in the cart page
- perf: ABC-123 improve performance of the cart page
Versioning
The TAYO Methodology uses Semantic Versioning to version the theme. Releases will be created using the following format:
major.minor.patch
The major version will be updated when there are breaking changes. The minor version will be updated when there are new features. The patch version will be updated when there are bug fixes.
Interested to join the team?
Learn more about our recruitment process and open positions.