Git & CI Workflow

Git & CI Workflow

Remotes

• origin — the primary Git server (self-hosted). This is the single source of truth; always fetch from and push to origin.
• github — GitHub mirror used for CI/CD and offsite backup. Never push or pull directly; a scheduled job mirrors origin → GitHub.

Protected master

master on GitHub is branch-protected: direct pushes are rejected. Changes reach production through pull requests:

feature/fix branch → push → PR → all checks green → squash-merge → CD

• PRs require all checks to pass (see below).
• Never force-push shared branches.
• Never use [skip ci] in commit messages — it would suppress the CI/CD pipelines triggered by sync pushes.
• Commit messages: concise, conventional-commit style (feat:, fix:, docs:, chore:).

CI pipeline (GitHub Actions)

Pull requests run the full gate:

Check	What it does
Lint & Typecheck	ESLint + tsc --noEmit
Unit & Integration Tests	Jest (API) + Vitest (Web)
E2E API Tests	Jest E2E against a test database
E2E UI Tests	Playwright
Docker Build Smoke Test	All images build
CodeQL	SAST
Semgrep	SAST rules
Trivy	Dependency/container vulnerabilities
SBOM & Security Audit	Software bill of materials + audit

Additionally scheduled: OWASP ZAP baseline (DAST against production), weekly security scans, automated docs generation.

Merge → Deploy

A merge to master triggers the CD workflow (blue-green deployment) — see Deployment. If the push trigger does not fire, the workflow can be dispatched manually (workflow_dispatch).

Sync-generated PRs

Some automation (e.g. generated documentation) commits via dedicated branches + auto-PRs because direct pushes to master are impossible. Expect to see bot PRs like docs: regenerate end-user docs — merge them like normal PRs after checks pass.