Skip to main content

Git Workflow

Long Term Branches​

  • master

    • This is the most stable, up-to-date release. Never work on this branch. This branch is only for storing completed code.

  • release/production

    • This branch is for building production build.

  • release/pre-release

    • This branch is for building testing version (testing environment), for the next release.
danger

All merging operations to the long term branches must be done by PULL REQUEST

Short Term Branches​

Every new feature and small bug fixes should be done in branches.

  • feature/...

    New features or features for the existing functionalities.

  • bugfix/...

    For the non-urgent bugs existing in the production build.

  • hotfix/...

    Urgent small, critical bug fixes found in the production build.

Commit Processes​

We are using Jira to manage the changes that will be included in the next release.

Every commit will need to be linked to a Jira ticket. In the comment, start with the Jira ticket code and a colon followed by the comment.

# git commit -m "<jira-issue-key> <message>"
git commit -m "ABC-123 Lorem ipsum"

Merging Processes​

Merging Flow Chart​

Merging into Long Term Branches​

Every change merged into long term branches must be done by a PULL REQUEST.

The code in the release/production and master branch has to be at a release state.

Every merge commit should be tagged in the release/pre-release branch.

Version Stages (tagging)​

Follow the version naming conventions https://semver.org/

  • Alpha

    Pull requests to release/pre-release must be tagged as alpha after they have been merged and ready to build. e.g. 1.2.0-a.x.

  • Release Candidate

    Pre-production build stage. e.g. 1.2.0-rc.x.

  • Production

    Use the release naming convention. e.g. 1.2.0

Merging into release/pre-release​

Merge from the master branch to build internal testing build. This is the final stage before releasing.

Merging into release/production​

Merge from the master branch. This is the production build.

Resolving Conflicts​

One file should never be massively modified on multiple different branches simultaneously.

But, if it does happen, or you know it is about to happen, please let the other parties know ASAP.

Resolving conflicts should be done in the individual branches. If you are ready to create a pull request to master, merge master into your branch and resolve all conflicts if any.

If there are conflicts, do testing in the area the conflicts occurred.

DO NOT resolve conflicts in the master branch.

Building​

Internal Testing​

Use release/pre-release to build the internal pre-release testing version (testing environment).

Developers use their own testing URL for their own branch changes.

e.g.

tidewater.schoolbridge.pages.dev

testing.schoolbridge.pages.dev

sbr-888.schoolbridge.pages.dev

Production Build​

Use release/production to build the production build (production environment).