Inspire Technology
GitHub Workflow Policy
Version 1.0 | Owner: Development Team | Approval Authority: Inspire Technology
| Feature Branch | Each new feature or significant task has its own separate branch. |
| Develop Branch | Completed features are merged here and an integrated build is shared for QA review. |
| Release Branch | The exact live source code remains available here and every production build is identified with a release tag. |
1. Purpose
This policy defines the standard GitHub branching, QA integration, release, and hotfix workflow for Inspire Technology projects. It is designed to keep feature development isolated, make QA builds predictable, and ensure every production deployment is traceable to an exact source-code version.
2. Core Principles
- No new feature development directly on develop or release.
- Each feature or significant task must be developed in its own branch.
- Develop is the shared integration branch used to combine completed features and generate QA builds.
- Only reviewed and QA-approved code is promoted to release.
- The exact source code of every live build must remain available in the release branch and be marked with a release tag.
- Urgent production fixes use a dedicated hotfix branch and must be merged back into develop after release.
Figure 1. Standard Inspire Technology GitHub workflow
3. Branch Structure
3.1 Feature Branch
Every new feature, enhancement, integration, or significant development task must have its own separate feature branch. Feature branches are created from develop and merged back into develop through a Pull Request after completion.
| Rule | Requirement |
|---|---|
| Purpose | Isolate development of one feature or task. |
| Created From | develop |
| Merged Into | develop |
| Naming | feature/<ticket-id>-<short-description> |
| Examples | feature/IT-125-customer-dashboard; feature/IT-140-payment-integration |
3.2 Develop Branch
The develop branch is the shared integration and pre-release branch. Multiple completed features are merged into develop so they can be tested together in one integrated QA build.
- Feature branches merge into develop using Pull Requests.
- Integrated QA builds are generated from develop.
- QA performs functional, regression, integration, and release-scope testing on the develop build.
- Incomplete or unstable features should not be promoted to release.
- Once the agreed release scope is reviewed, stable, and QA-approved, it is promoted to release.
3.3 Release Branch
The release branch represents production-ready source code. It must always contain or preserve the exact source code corresponding to the current live build, and each production deployment must be identified by a release tag.
- Only reviewed and QA-approved code can be promoted to release.
- Production deployments must be built from the approved release source.
- Every production deployment must have a unique version tag.
- Direct feature development on release is prohibited.
- The live source must always be reproducible from GitHub.
Recommended release tags: v1.0.0, v1.1.0, v2.0.0
4. Standard Development & Release Workflow
| Step | Stage | Action |
|---|---|---|
| 1 | Create Feature Branch | Developer creates a new feature branch from develop. |
| 2 | Develop & Self-Test | Developer implements the task and performs developer-level testing. |
| 3 | Pull Request | A Pull Request is raised from the feature branch into develop. |
| 4 | Code Review | Required reviewer(s) review the code before merge. |
| 5 | Merge to Develop | Completed feature is merged into develop. |
| 6 | QA Build | An integrated build from develop is shared with QA. |
| 7 | QA Approval | Release scope is verified and critical issues are resolved. |
| 8 | Promote to Release | Approved source is merged/promoted to the release branch. |
| 9 | Release Tag | A version tag is created for the exact production source. |
| 10 | Production Deployment | The tagged release is deployed to production. |
5. Pull Request & Code Review Rules
- All merges into develop and release should use Pull Requests.
- The Pull Request must reference the related task/ticket where applicable.
- The Pull Request description should summarize the change, testing completed, and any known limitations.
- Significant changes require at least one appropriate reviewer before merge.
- Merge conflicts must be resolved before approval.
- Direct push to protected branches should be restricted.
6. QA & Release Approval Rules
Development completion alone does not make a change eligible for production. Before promotion to release, the agreed release scope should be:
- Code reviewed
- Developer-tested
- Integrated in develop
- QA-tested
- Critical/high-priority defects resolved
- Approved for release
7. Hotfix Workflow
Urgent production issues must be handled through a dedicated hotfix branch so the production correction is isolated and traceable.
- Create hotfix/<ticket-id>-<short-description> from the current release source.
- Implement and test only the urgent production correction.
- Review and merge the fix back into release.
- Create a new release tag and deploy the corrected build.
- Merge the same fix back into develop to prevent regression in future releases.
8. Recommended GitHub Branch Protection
| Branch | Protection | Recommended Rule |
|---|---|---|
| develop | Protected | Pull Request required; reviewer required; direct push restricted; force push disabled. |
| release | Highly Protected | Pull Request required; release/QA approval; restricted merge permissions; force push and deletion disabled. |
9. Release Traceability
Every production deployment must be traceable through the following chain:
Project → Release Branch → Commit → Release Tag → Production Deployment
This allows Inspire Technology to identify what code is live, which features were included, which commit was deployed, and which version can be restored if rollback is required.
10. Naming Conventions
| Type | Format | Example |
|---|---|---|
| Feature | feature/<ticket-id>-<short-description> | feature/IT-225-user-profile |
| Hotfix | hotfix/<ticket-id>-<short-description> | hotfix/IT-231-login-crash |
| Release Tag | v<major>.<minor>.<patch> | v2.4.1 |
11. Policy Summary
Feature Branch: One separate branch for every new feature or major task.
Develop Branch: Multiple completed features are integrated here and the QA build is generated from this branch.
Release Branch: Contains approved production-ready source. The exact source of each live deployment is retained and tagged.
Hotfix Branch: Used only for urgent production fixes and merged back into both release and develop.
Production Rule: No feature reaches production without review, QA approval, release promotion, and version tagging.