Introduction

This document outlines updated best practices and methodologies for managing GIT merge requests, staging, and integration environments at Cantilever Development Agency, emphasizing a workflow where all work begins from the main branch, utilizes develop for staging in absence of automatic preview builds, and merges features directly into main for production deployment.

GIT Merge Requests (MRs)

1. Branching Strategy

• All new work is cut from the main branch. This ensures that every new feature or fix starts from the most current stable version of the project.
• Feature branches should be created for each new feature or bug fix and branched directly from main.

2. Commit Messages

• Maintain clear, descriptive commit messages that succinctly explain the changes made and the reason behind them.
• Implement a commit message template for consistency.

3. Review Process

• Code reviews are mandatory for all merge requests to ensure quality and consistency. At least one peer review by a team member not involved in the branch development is required.
• The Asana task will have a sub task for developer review. Ensure that the review task name includes the name of the parent task. Within the task content include a link to the merge request in Github.

Staging Environment

1. Utilizing the develop Branch for Staging

• In scenarios without automatic preview builds based on pull requests (PRs), the develop branch is set up to act as the staging environment.
• This branch should be regularly updated and serve as a mirror to test features in a collective environment that mimics production.

2. Deployment Process

• Deployments to the staging (develop) environment are automated. Whenever there is a merge into the develop branch it will trigger an automatic build.
• Keep the staging environment closely synchronized with the main branch to reflect production as accurately as possible.