Frequency Git Workflow - LibertyDSNP/frequency GitHub Wiki
Overview
Source Diagram: https://docs.google.com/drawings/d/1GyvodIcZ3AfrfmpgK465N369Lu-F41Ni-__Gvk4p6iQ
This page describes Git branching workflow employed by the Frequency team during development and release cycles. This workflow has 4 types of branches:
Number | Branch Name | Type | Branch Pattern | Purpose |
---|---|---|---|---|
1 | Developer Branch | Short-Lived | [issue#]-[brief-descriptive-name] |
a.k.a "feature branch", used to develop new features and make other changes for the upcoming releases. |
2 | Release Branch | Long-Lived | release-v[x.x.x*] |
Frequency release tied to the specific Polkadot release version, etc., e.g. release-v0.9.29 , release-v0.9.30 , release-v0.9.30-1 , etc. |
3 | Next Branch | Long-Lived | origin/main |
Represents the next version under development, i.e. a release candidate. Must be as stable as possible. |
4 | Hot Fix Branch | Short-Lived | [issue#]-[brief-descriptive-name] |
These hot fix branches are necessary to act immediately upon an undesired status of one of the current releases (Rococo and/or Mainnet). |
Once a long-lived branch is created, it can stay in the repo forever. In other words, there is no time limitation on the lifecycle of such branch.
Change Management
To work on something new:
- Create a new developer branch off
main
and give it a descriptive name starting with the story number (ie:504-retire-msa-id
,,
323-upgrade-runtime-v0.29.0, etc.) if there is a GitHub story associated with this change. Direct commits to
main` are not allowed. - Commit to that branch locally and regularly push your work to the same named branch on the server.
- Run tests locally.
- When you need feedback or help, or you think the branch is ready for merging, open a pull request. This will trigger "Verify PR" CI workflow which will execute multiple checks on the code changes in the PR.
- If CI fails, address reported issues and push a new commit to remote. This will trigger a new "Verify PR" workflow run. Repeat this step until all jobs in CI are passing successfully.
- After someone else has reviewed and signed off on the feature, you can merge your PR into
main
.
References: