Git Branching & Release Workflow
Our Git workflow enables continuous integration through trunk-based development with short-lived feature branches (<48 hours). By adopting the Conventional Commits standard (feat, fix, docs, refactor) and requiring GPG-signed commits, we maintain a clear, automated changelog and an immutable audit trail for regulatory compliance.
Trunk-Based Development & Short-Lived Branches
Long-lived branches create merge hell and obscure regression origins. We practice trunk-based development: all engineers branch off main (trunk), make small, focused changes, and merge back within 24 to 48 hours via audited pull requests.
Branch Naming Format
feature/NUP-101-language-tabs
fix/NUP-102-null-pointer-bug
docs/NUP-103-ieee-standards
PR Size Guidelines
Aim for ≤ 400 lines of modified code per PR. Smaller pull requests are reviewed 3x faster with 50% fewer escaped defects.
Conventional Commits Specification
Commit messages must follow the Conventional Commits v1.0.0 specification to automate semantic versioning and release notes:
Branch Protection & GPG Non-Repudiation
- Direct Push Disabled: The
mainbranch is locked against direct pushes and force pushes. - Required Status Checks: All CI build, linting, and unit test suites must pass before merge button is enabled.
- Signed Commits: Per FDA 21 CFR Part 11 and SOX ITGC controls, developers must sign commits with a verified GPG key to establish non-repudiation.
Copy this prompt into your AI coding assistant to author clean commit messages.
Community Discussion & Feedback
Attributed peer feedback and official Netspective architecture notes.