Purpose

To establish a standardized process for managing version control in WordPress projects to ensure consistency, collaboration, and tracking of changes during development.

Scope

This SOP applies to all developers, designers, and project managers working on WordPress projects at Axys Digital Marketing.

1. Repository Setup

  • Use a Git-based version control system (e.g., GitHub, GitLab, or Bitbucket) for all WordPress projects.
  • Each project must have a dedicated repository, named using the format: 
    [ClientName]_WordPressProject_[Date]
  • Configure access permissions to ensure only authorized team members can access the repository.

2. Branching Strategy

  • Follow a structured branch hierarchy:
    • Main Branch: Reserved for production-ready, stable code.
      • Master Branch – Never work directly on this branch, this branch will update by only Stage branch.
    • Develop Branch: Active branch for integrating new features and bug fixes.
      • Stage Branch & Dev Branch – Here also never work directly but its updated by other branch which is create based on new functionality and features.
      • Dev Branch – This branch will update by multiple branches and developer work on it and merge code in this branch.

3. Development Best Practices

  • Avoid committing sensitive data (e.g., API keys, database credentials). Use .env files for environment variables.
  • Add a .gitignore file to exclude unnecessary files like:
    • node_modules/
    • vendor/
    • wp-content/uploads/
    • .env
    • *.zip
  • Use a staging server to test changes before deploying to production.

-Branch naming conventions:

  • Feature: feature/[feature-name]
  • Bug Fix: bugfix/[issue-name]

3. Commit Messages

  • Write clear and descriptive commit messages for every change.
  • Commit message format:
    • Need to be discussed

4. Pull Requests (PRs)

  • Open a pull request when merging changes from a feature or hotfix branch into the develop branch.
  • Include the following in the pull request:
    • A summary of changes made.
    • Link to the task or ticket associated with the changes.
    • Testing instructions or screenshots.
  • Require at least one reviewer to approve the pull request before merging.

5. Merging Guidelines

  • Use squash merging for feature branches to keep the commit history clean.
  • Changes must pass all code reviews and testing processes before merging into the develop or main branch.
  • Only stable, tested code can be merged into the main branch.

6. Semantic Versioning and Tagging

  • Follow semantic versioning for releases: vX.Y.Z
    • X: Major changes or breaking updates.
    • Y: Minor updates or new features.
    • Z: Bug fixes or patches.
  • Add annotated tags to releases with descriptions of included changes.

7. Deployment Process

  • Deploy code only from the main branch.
  • Use automated deployment tools (e.g., GitHub Actions) to streamline deployment.
  • Verify functionality in staging environments before production deployment.

Responsibilities

  • Developers: Ensure all changes are tracked in Git, use proper branching, and write clear commit messages.
  • Project Managers: Monitor adherence to the version control process and oversee pull request reviews.
  • Team Leads: Approve pull requests and manage release tagging.
  • IT/Admin Team: Configure repository permissions and maintain automated backup systems.