Git process
This document outlines the git process used for the authoring tool product. For information on the framework's process, see this page.
Note: This article assumes that you understand the basic concepts of the git version control system.
On the authoring tool project, we organise the branches in our repos in a similar way to standard git flow, with a few alterations.
We use the following branches:
| Name | Description | Persisting |
|---|---|---|
master |
Contains the stable, released code. | yes |
develop |
Contains the latest features. Not guaranteed to have been tested, so not suitable for production installs. | yes |
release/VERSION_NAME(e.g. release/v1.0)
|
A release candidate branch. Contains development code, and should not be considered stable. Use this code at your own risk! | no |
issue/TICKET_NAME (e.g. issue/1024)
|
A self-contained bug-fix/feature. Should be named after a corresponding issue ID. Finished changes should be submitted as a pull request. | no |
We also apply the following rules:
- The
masteranddevelopbranches are the only persisting branches. All other branches should be deleted post-merge. - The
masterbranch contains only thoroughly tested code, and should only ever merge code from areleasebranch. - Any
issuebranches should be submitted as a PR to the currentreleasebranch (NOTmaster-- unlike standard git flow, we don't allow hotfixes directly intomaster).
We go through the following schedule prior to making a release:
- The core development team assign a bunch of issues/features to the relevant release.
- A
releasebranch is created from the latestdevelopcode. - The coders are let loose 🔧, and submit their additions as PRs using the documented process.
- Once all work has been done, we call a code freeze ❄️, and the branch goes through our testing process.
- Any issues are fixed.
Once the release code has been tested, we are ready to merge the release branch into master. When this is done, we tag the master branch with the release number, and party! 🎉🎈🍹
