2.4. Standards: Repository Access and Branch Protection Policy

Purpose

This policy establishes a structured and secure workflow for code changes, defining distinct roles for the Release Team, Contributors, and CodeOwners (typically architects). It utilises the GitFlow branching model to maintain code quality and control releases, with CodeOwners playing a key role in planning and release cadence.

Actors and Roles

1. Release Team:

   • Responsibilities:
     • Create release branches from develop
       • Use CLI git-flow release start "semantic version"
     • Merge code from release branch to main.
       • Use CLI git-flow release finish "semantic version"
     • Tag are created on main caused by git-flow
     • Merge from main to develop caused by git-flow
     • Push changes to main and develop, including tags.
   • Permissions:
     • Write access to main & develop.
     • Read access to all branches.

2. Contributors Team (Engineers):

   • Responsibilities:
     • Develop new features and bug fixes.
     • Create feature branches from develop.
       • Can use the UI to create branches.
       • Use CLI git-flow feature start "branch name"
     • Submit pull requests (PRs) for code review.
     • Merge from feature branches to develop
       • Can use the UI to merge
       • Use CLI git-flow feature finish
   • Permissions:
     • Write access to feature branches.
     • Write access to develop for approved feature branches.
     • Read access to main
     • No direct merge access to main.

3. CodeOwners Team (Architects):

   • Responsibilities:
     • Review and approve PRs.
     • Plan milestones and determine release cadence.
     • Release authority (decide when to merge to main).
     • Note: May not directly make code changes.
   • Permissions:
     • Write access to develop for approved feature branches.
     • Read access to all branches.
   • Configuration:
     • Defined in the ./github/CODEOWNERS file.

Branch Protection

• main:

  • Strictly protected.
  • Only the Release Team can merge.
  • Tags used to mark releases.
  • Maintains a history of feature releases.

• develop:

  • Protected.
  • Requires a pull request from a feature branch with approval from CodeOwners to merge.
    • Release team bypass this requirement
  • Contributors and CodeOwners can merge.
  • Maintains a history of feature integrations.

Workflow

1. Planning: CodeOwners plan milestones and determine the release cadence.
2. Branching: Contributors create feature branches from develop.
3. Development: Contributors work on their feature branches.
4. Pull Request: Contributors submit PRs for review, automatically assigning CodeOwners.
5. Code Review: CodeOwners (architects) review code and provide feedback.
6. Approval: CodeOwners approve PRs that meet quality standards.
7. Merge to develop: Approved PRs are merged into develop (by Contributors or CodeOwners).
8. Release: CodeOwners determine the release cadence.
9. Release Team:: Create a release via a release branch and merges to main and develop.

Appendix

• FAQ: Release Engineers: Performing a release with git-flow
• FAQ: Git‐Flow: Developers Branching Model