branch_protection.md

GitHub Branching and PR Guidelines

1. Branching Rules

1.1 General Branching Convention

• The master branch is protected. No direct pushes are allowed.
• All changes must be made through feature or bug branches and merged via Pull Requests (PRs).
• The dev branch is the main base branch for development work.

1.2 Team-Specific Branch Naming Conventions

• Platform Team: Use /story/<story_id> or /bug/<bug_id>
• Data Team: Use /DAT-<story_id>
• <story_id> and <bug_id> correspond to Jira tickets.
• For branches which are from SIT or PROD (as quick fix) use /story/sit/<story_id> or bug/prod/<story_id> i.e. include the environment name in the branch name.

2. Pull Request (PR) Guidelines

2.1 PR Requirements

• All PRs must have a clear description explaining the changes.
• Reference the Jira ticket ID in the PR title or description.
• Follow the coding standards of the project.
• PRs should be small and focused. Read more about writing effective PRs here
• PRs should have appropriate labels for tracking purposes.

2.2 Code Review Process

• Developers cannot push directly to master. A review is required.
• The reviewer is assigned based on the team:
  • Platform Team: A senior developer from the Platform team reviews the PR.
  • Data Team: A senior developer from the Data team reviews the PR.
• All code must be reviewed and approved before merging.

3. Additional GitHub Etiquette

• Commit Messages: Use meaningful commit messages following the format: [Jira_ID] Brief description of change
• Rebasing: Keep your branch updated with dev by regularly rebasing.
• Merging: Use squash and merge to keep a clean commit history.
• Conflict Resolution: Ensure conflicts are resolved before requesting a review.

By following these guidelines, we ensure a smooth and structured development workflow, reducing merge conflicts and improving code quality.