Best Practices for GIT Merge Requests and Staging Environments


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.

Direct Merging into main for Production

  • When a feature is deemed ready for production, the feature branch is merged directly into main.
  • After merging, the feature branch is closed and deleted from GitHub to maintain a clean and manageable repository history.

General Best Practices

1. Documentation

  • All processes and methodologies related to MRs, staging, and direct merging into main are documented and accessible to the development team.
  • Documentation is regularly reviewed and updated to reflect any changes in workflow or best practices.

2. Communication

  • Encourage open communication and feedback within the development team regarding the merge request and environment management process.
  • Leverage collaboration tools for discussions related to MRs, deployments, and testing outcomes.