إنتقل إلى المحتوى الرئيسي

🌿 Git Workflow & Feature Flags

BayanCore employs Trunk-Based Development to maintain shipping velocity while verifying that all code merges satisfy security, stability, and Saudi compliance standards.

1. Trunk-Based Development​

  • Main Branch Protection: The main branch represents the active, stable release state. Direct commits to main are blocked.
  • Short-Lived Branches: Feature and bugfix branches must be merged back into main within 48 hours to prevent integration conflicts.
  • PR Merging Rules: Pull requests require:
    1. Successful CI/CD pipeline pass (linting, tests, build checks).
    2. Minimum of 1 approved peer code review.
    3. Linear commit history (no merge commits; PRs are squashed and rebased).

2. Conventional Commits​

Commits must follow the Conventional Commits specification to enable automated changelog generation and release numbering:

<type>(<scope>): <description>

[Optional Body]
[Optional Footer]

Commit Types​

  • feat: A new feature (e.g. feat(zatca): add B2B invoice clearance)
  • fix: A bug fix (e.g. fix(hr): correct GOSI deduction rounding)
  • docs: Documentation changes (e.g. docs(naming): update Git prefix rules)
  • style: Code style modifications (formatting, white-space)
  • refactor: Code changes that neither fix bugs nor add features
  • test: Adding or correcting tests

3. Feature Flag Policies​

To execute safe, progressive deployments without blocking merges, we utilize feature flags (via a local service like Unleash):

  • Phased Rollouts: New workflows (like GOSI automated filing or WhatsApp OCR) are deployed to production hidden behind feature flags.
  • Tenant-Specific Toggles: Feature flags enable features selectively (e.g., enabling the contracting module only for accounts tagged with the contracting vertical).
  • Flag Expiries: Feature flags must be removed from the codebase within 30 days of full feature activation to prevent technical debt build-up.