Skip to content

Latest commit

 

History

History
69 lines (50 loc) · 2.3 KB

README_branching.md

File metadata and controls

69 lines (50 loc) · 2.3 KB

Branching Strategy Documentation

Overview

This document outlines the branching strategy to be followed in the repository for managing development, staging, and main branches. The purpose is to provide a clear and organized approach to collaborative development and release management.

Branches

1. Main Branch

  • Name: main
  • Purpose: Represents the production-ready code.
  • Rules:
    • Only stable and tested code should be merged into main.
    • Direct commits to main should be avoided. All changes should go through pull requests.

2. Development Branch

  • Name: development
  • Purpose: Represents the latest development changes.
  • Rules:
    • Developers create feature branches from development.
    • Frequent integration with feature branches to identify and resolve conflicts early.

3. Feature Branches

  • Naming Convention: feature/<feature-name>
  • Purpose: Isolated branches for developing specific features.
  • Rules:
    • Created from and merged back into development.
    • Short-lived and specific to a single feature or bug fix.
    • Regularly updated with changes from development.

4. Staging Branch

  • Name: staging
  • Purpose: Represents a stable state for testing before release.
  • Rules:
    • Merged from development once a set of features are ready for testing.
    • Used for integration testing before merging into main.

Workflow

  1. Feature Development:

    • Create a new feature branch from development.
    • Implement and test the feature.
    • Regularly merge changes from development to stay up-to-date.

  2. Code Review:

    • Create a pull request when the feature is ready.
    • Get code reviews from peers.
    • Make necessary changes and address feedback.

  3. Merge to Development:

    • Once the feature is approved, merge it into the development branch.

  4. Testing:

    • Periodically merge development into staging for testing.
    • Conduct thorough testing on the staging branch.

  5. Release to Production:

    • After successful testing, merge staging into main for release.

Best Practices

  • Commit messages should be clear and descriptive.
  • Regularly update local branches with remote changes.
  • Avoid force-pushing to shared branches.
  • Utilize git hooks for automation and validation.