logicspike/docs

Guides

Git Workflow & Release Strategy

This document defines how we manage code changes, branches, and releases for LogicSpike.

🌳 1. Branching Strategy

We follow a Feature Branch workflow (a simplified Gitflow).

The "Golden" Branches

  • main: The Production Source of Truth.
    • ALWAYS deployable to Live.
    • Protected: No direct commits.
  • dev: The Staging / Beta Branch.
    • Deploy Target: Staging Environment (staging.logicspike.com).
    • Code is merged here first for integration testing.

Supporting Branches

  • feat/name-of-feature: For new features.
    • Created from: dev (usually) or main.
    • Merges back to: dev via PR.
    • Once verified on Staging, dev is merged to main for release.
  • fix/issue-description: For bug fixes.
  • chore/maintenance: For config updates.
  • refactor/component: For code cleanup without behavior change.

📝 2. Commit Convention

We follow Conventional Commits. This allows us to auto-generate changelogs.

Format: type(scope): description

Types

  • feat: A new feature (Correlates to MINOR version).
  • fix: A bug fix (Correlates to PATCH version).
  • docs: Documentation only changes.
  • style: Formatting, missing semi colons, etc; no code change.
  • refactor: A code change that neither fixes a bug nor adds a feature.
  • perf: A code change that improves performance.
  • test: Adding missing tests or correcting existing tests.
  • chore: Changes to the build process or auxiliary tools.

Examples

  • feat(auth): add login endpoint
  • fix(ui): resolve button alignment on mobile
  • chore(deps): upgrade prisma to v6

🔀 3. Pull Request (PR) Rules

Lifecycle

  1. Draft: Open a PR as "Draft" if work is in progress but you want feedback.
  2. Review: Request review when ready.
  3. Merge: Squash and Merge into main.

Requirements

  • Title: Must follow Conventional Commit format (e.g., feat: allow users to invite members).
  • CI Checks: All tests and linters MUST pass.
  • Approval: At least 1 peer review required.

🏷️ 4. Release Process

Versioning

We use Semantic Versioning (vMajor.Minor.Patch).

  • Major: Breaking changes (e.g., API structure change).
  • Minor: New features (backward compatible).
  • Patch: Bug fixes.

The Flow

  1. Merge PRs into main.
  2. Create a Tag (e.g., v1.2.0).
  3. CI/CD Pipeline triggers:
    • Builds Docker images.
    • Deploys to Production.
    • Publishes Release Notes (based on commit history).

🚀 Summary Checklist

  • Never commit to main.
  • Branch name: type/description.
  • Commit message: type: description.
  • Merge via PR only.
Guides