Branching Strategy
Before this proposal HSW was just pushed straight to main. This is not ideal but also not critical since historically there has only been 1 contributor @inspizzz. However, as HSW grows and eventually website development/maintainece is handed over to news teams. This can lead to problems if multiple contributors are working at the same time. To maintain integrity of the site it is important to have a branching strategy.
There is also an underlying assumption that contributors are students, therefore this also exposes them to software engineering best practices
Our branching strategy will loosely follow the Gitflow model. The reasoning for this is that it is an industry standard and it very easy to make exceptions for edge cases.
main → production-ready code
develop → All development and feature work will be merged into this branch
feature/<issueid-username-featurename> → new features, sub issues within features can branch off this
- Example:
feature/42-inspizz-user-auth
bugfix/<issueid-username-bugname> → bug fixes
- Example:
bugfix/87-inspizz-fix-navbar
release/<version> → staging/pre-release work
- Example:
release/1.2.0
hotfix/<issueid-username-hotfixname> → staging/pre-release work
- Example:
hotfix/99-finn-critical-login-patch
feature/, bugfix/ → merge into develop.
release/ → merged into both main and develop.
(We are using the v(Major).(Minor).(Patch) release numbering format)
hotfix/ → merged into both main and develop.
All branches (main, develop, feature/*, bugfix/*) share the following base requirements:
- Pull Requests Required: Direct pushes are generally restricted; changes must be merged via a Pull Request.
- Code Review: At least 1 approving review is required before merging.
- Fresh Approvals: Stale reviews are dismissed when new commits are pushed (approvals must be re-given).
- Merge Methods: Only Squash and Rebase merges are allowed (Merge commits are disabled to keep history clean).
| Rule | main |
develop |
feature/* & bugfix/*
|
|---|---|---|---|
| Branch Protection |
Strict (No creation, updates, or deletion allowed) |
Protected (No deletion or force pushes) |
Standard (Standard PR workflow) |
| Linear History | ✅ Required | ✅ Required | ❌ Not Required |
| Conversation Resolution | ✅ Required (All threads must be resolved) |
✅ Required (All threads must be resolved) |
❌ Not Required |
| Force Push | 🚫 Blocked | 🚫 Blocked | Allowed (if not explicitly blocked) |
-
main: The most strictly protected branch. It enforces a linear history and requires all conversation threads on PRs to be resolved before merging. It prevents branch creation, updates, and deletion to ensure production stability. -
develop: Similar to main, it enforces linear history and conversation resolution, ensuring that development code is kept clean and discussed thoroughly. Deletion and force pushes are blocked. -
feature/*&bugfix/*: These branches are more flexible to allow for iteration. While they still require a PR review to ensure quality, they do not enforce linear history or mandatory thread resolution, speeding up the feedback loop during active development.