Branching Strategy - mhmunem/Grocery-Comparison-App GitHub Wiki

Branching Strategy

Branch Types

  • Main Branches:
    • master:
      • Represents the production- ready code.
      • Only stable and tested code is merged here.
      • Deployment to production is done from this branch.
    • dev:
      • Serves as the development integration branch for ongoing development.
      • All feature branches are merged here after review and testing.
      • Represents the latest stable version of the code under development.
  • Supporting Branches:
    • Feature Branches (feature/*):
      • Used for developing individual features or tasks.
      • Created from the dev branch.
      • Merged back into dev after review and testing.
    • Release Branches (release/*):
      • Used to prepare for production releases.
      • Created from the dev branch when a release is ready.
      • Allows for final testing, bug fixes, and version tagging.
      • Merged into master after release.
    • Hotfix Branches (hotfix/*):
      • Used to address critical issues in production.
      • Created from the release branch.
      • Merged into dev and master to keep all branches updated.

Branching Rules

Feature Branch Rules
  • Naming Convention:
    • Use feature/(feature/search-feature).
  • Base Branch: Always branch off/cut off from dev.
  • Merge Rules:
    • Create a merge request targeting dev.
    • Add reviewers for code review.
    • Ensure all tests pass before merging.
    • Delete the feature branch after merging.

Release Branch Rules

  • Naming Convention:
    • Use release/ (release/v1.0.0).
  • Base Branch:
    • Always branch off/ cut- off from dev.
  • Merge Rules:
    • After successful release, merge into master.
    • Merge back into dev to sync any fixes applied during release.

Hotfix Branch Rules

  • Naming Convention:
    • Use hotfix/- (hotfix/567- critical- fix).
  • Base Branch:
    • Always branch off from release.
  • Merge Rules:
    • After testing, merge into release, dev, and master.
    • Tag the fix on master if needed.

General Guidelines

  • Commit Messages: Follow a clear and concise commit message (example-> fix: resolve pagination issue).
  • Code Reviews:
    • All branches must undergo peer review before merging.
    • At least one reviewer must approve the changes.
  • Testing Requirements:
    • Ensure all tests (unit, integration, and regression) pass in the CI pipeline.
    • Deploy feature or release branches to the appropriate testing environment before merging.
  • Conflict Resolution:
    • Resolve conflicts locally before creating merge requests.

Workflow Overview

  1. Developers create and push feature branches for individual tasks.
  2. Feature branches are reviewed, tested, and merged into dev.
  3. When a release is ready, a release branch is created from dev.
  4. After final testing/ successful release, the release branch is merged into master for clean code maintenance.
  5. In case of production issues, a hotfix branch is created from release, tested, and merged into all relevant branches.
⚠️ **GitHub.com Fallback** ⚠️