Branching Strategy

Overview

To maintain a stable production environment while allowing for frequent weekly contributions, this project follows a structured branching strategy based on Git Flow. This ensures that the main branch remains deployable at all times while providing a sandbox for development and testing.

Primary Branches

The repository maintains two evergreen branches:

• main: Contains the latest stable, production-ready code. All code in this branch has been tested and approved.
• develop: The primary integration branch for new features. This is where the latest development changes live before being merged into main.

Contribution Workflow

All contributors should follow these steps when proposing changes:

1. Create a Supporting Branch

Do not commit directly to main or develop. Create a new branch from develop using the following naming conventions:

| Branch Prefix | Purpose | Base Branch | | :--- | :--- | :--- | | feature/ | New functionality or WordPress enhancements. | develop | | fix/ | Standard bug fixes. | develop | | hotfix/ | Urgent production fixes required immediately. | main | | docs/ | Documentation updates or README improvements. | develop |

Example Usage:

# Feature development
git checkout develop
git pull origin develop
git checkout -b feature/custom-plugin-integration

# Urgent hotfix
git checkout main
git pull origin main
git checkout -b hotfix/critical-security-patch

2. Implementation and Commits

Write your code and commit changes locally. Ensure your commit messages are descriptive and follow standard Conventional Commits (e.g., feat: add custom rest api endpoint).

git add .
git commit -m "feat: implement weekly contribution tracker"

3. Submitting a Pull Request (PR)

Once your work is ready for review:

1. Push your branch to your fork or the origin.
2. Open a Pull Request.
3. Target Branch:
   • Target develop for features, standard fixes, and documentation.
   • Target main only for critical hotfixes.

git push origin feature/custom-plugin-integration

Hotfix Procedure

Hotfixes are the only branches that may branch off main and be merged directly back into main. This is reserved for critical issues that cannot wait for the next scheduled release cycle. Once a hotfix is merged into main, it must also be merged back into develop to ensure the development environment stays synchronized.

Merging Policy

• Code Review: At least one maintainer must approve a PR before merging.
• CI/CD: All automated tests must pass before the "Merge" button is enabled.
• Clean History: We prefer Squash and Merge for feature branches to keep the main history clean and readable.