Git Workflow & Environment Promotion

All software code must be version-controlled using Git.
Each software component must live in its own independent repository (single-application-per-repository).
No repository may contain more than one software component.

Git

All repositories must include a default branch named main.
Changing the default branch is not permitted unless explicitly authorized by the Head of DevOps.

Branching Model

DIT follows an environment-based branching strategy with versioned release branches and optional feature branches.

Environment Branches

Branch	Purpose
dev	Active development environment
main	Staging environment

Production deployments no longer use a production branch.
Production is deployed exclusively via GitHub Releases, which update the GitOps configurations.

---

Version Branches

Each major version must have its own long-lived branch, such as:

• v1.x.x
• v2.x.x (typically created from main)

These branches represent the source of truth for their respective major versions.

---

Feature Branches

Feature branches may be created independently by developers for new development work.

• Normal Feature Branches

  • May be created freely by any developer.
  • May be merged into dev without special approval.

• Hotfix Branches

  • Must be explicitly authorized by the Head of Digital Development.
  • Merging a hotfix into dev, main, or any version branch also requires this authorization.

This ensures feature development remains flexible while hotfixes remain controlled.

---

Branch Promotion Flow

The updated branch and deployment flow is:

major-version-branch → dev → main → GitHub Release → Production

Examples:

v1.x.x → dev → main → GitHub Release → Production
v2.x.x → dev → main → GitHub Release → Production

Deployment and GitOps Workflow

All environment deployments—development, staging, and production—are handled through GitOps.

Development Deployments

• Merging into dev triggers a GitOps PR targeting the development environment.
• Development GitOps PRs auto-merge without approval.

Staging Deployments

• Merging into main triggers a GitOps PR targeting the staging environment.
• Staging GitOps PRs require approval from:
  • Head of DevOps, or
  • Head of Digital Development

Production Deployments

• Production deployments are triggered only via GitHub Releases.
• Creating a release automatically generates a GitOps PR targeting the production environment.
• Production GitOps PRs require approval from:
  • Head of DevOps, or
  • Head of Digital Development

Merging and Pushing Policy

Developers may freely push to:

• Feature branches
• Release branches
• dev

The following require authorization and/or review:

Branch / Action	Who Can Trigger	Approval Requirements
Feature Branch → dev	Any developer	No review required (unless hotfix)
Hotfix Branch (any merge target)	Only with authorization from Head of Digital Development	Authorization required
main	Head of DevOps or Head of Digital Development	PR required
GitHub Release (Production)	Head of DevOps or Head of Digital Development	GitOps PR approval required

Secrets

(Section unchanged unless revised separately.)

GitHub

All repositories must be hosted under the
👉 https://github.com/ditkrg.

All members of the organization must use:

1. SSH keys for authentication
2. GPG-signed commits

Unsigned or unverified commits are not permitted.

Refer to GitHub’s guide for configuring commit signing:
https://docs.github.com/en/authentication/managing-commit-signature-verification