# Sensible Branch Policies for IBP

To maintain high code quality, foster effective collaboration, and protect critical branches from unintended changes, the following branch policies have been established. These policies are designed to minimize risks while ensuring that the development process remains efficient and manageable.

# Overview

These policies apply to all repositories within the organization and aim to:

Enforce consistent code quality standards.
Ensure proper code review and accountability.
Protect critical branches from direct or unreviewed changes.
Streamline collaboration across teams with minimal overhead.

By adhering to these guidelines, teams can reduce the likelihood of bugs, maintain a clean and stable codebase, and ensure that all changes are properly reviewed and documented.

# Cross-Repository Policies

The following policies apply universally across all repositories:

# 1. No Direct Commits to Protected Branches

Direct commits to critical branches are strictly prohibited. This ensures that all changes are reviewed and approved before being merged. The following branches are considered protected:

dev
qa
preprod1
pent
prod1
main

All changes to these branches must go through a pull request (PR) process.

# 2. Pull Request (PR) Requirement

To commit changes to any protected branch, a pull request must be submitted. This process ensures that all changes are reviewed and approved before being merged into the branch.

Key requirements for pull requests:

At Least One Reviewer is Required: Every pull request must have at least one reviewer assigned. This ensures that another team member reviews the changes for quality and correctness.
Self-Approval is Not Allowed: The author of the pull request cannot approve their own changes. This policy ensures an independent review process and avoids potential oversights.

# 3. Resolve All Comments Before Merging

All comments made during the code review process must be addressed and marked as resolved before the pull request can be merged. This ensures that any concerns or suggestions raised during the review are properly handled, leading to better code quality and fewer issues downstream.

# 4. Link Work Items to Pull Requests

For projects that follow a sprint-based workflow and utilize work items, every pull request to dev must include a linked work item. This helps maintain traceability and ensures that all changes are tied to specific tasks or user stories.

Benefits of linking work items:

Provides context for the changes being made.
Helps track progress and align development efforts with sprint goals.
Improves reporting and accountability.

# 5. Special Approval for Infrastructure Changes

Changes to infrastructure-related files (e.g., files in the /infra directory) require additional scrutiny due to their potential impact on the environment. To ensure these changes are reviewed by the appropriate team, the following policy applies:

At least one member of the Software Architecture must approve any changes to the /infra directory.
A reviewer group containing the Software Architecture Team will be automatically added to pull requests that involve infrastructure changes.

This policy ensures that infrastructure changes are reviewed by subject matter experts, reducing the risk of misconfigurations or deployment issues.

# Why These Policies Matter

By implementing these branch policies, we aim to:

Improve Code Quality: Code reviews help catch bugs, enforce coding standards, and encourage knowledge sharing among team members.
Enhance Collaboration: The pull request process fosters communication and collaboration, ensuring that all team members are aligned on changes.
Protect Critical Branches: Restricting direct commits and requiring reviews minimizes the risk of accidental or harmful changes to critical branches.
Ensure Traceability: Linking work items to pull requests provides a clear connection between code changes and project goals, improving transparency and accountability.