Gremoire

Collaboration Workflow with Semantic Versioning and Conventions ​

Steps for Collaborators ​

  1. Clone the Repository
    Download the project to your local machine:

    bash
    git clone <git-repo>

  2. Sync with the Latest Code
    Ensure your local repository is up-to-date:

    bash
    git pull origin main

  3. Create a New Branch
    Use a semantic branch naming convention:

    bash
    git checkout -b <branch type>/<scope>/<short-description>

    • Branch Types:

      • feature/ → New features.
      • bugfix/ → Fixing bugs.
      • hotfix/ → Urgent fixes.
      • chore/ → Maintenance tasks.
      • docs/ → Documentation updates.
      • test/ → Testing-related updates.

    • Scope:
      Use a keyword describing the area of change, e.g., auth, ui, backend.

    • Short Description:
      A brief description of the work, e.g., login-page, fix-header.

    Example Branch Name:

    • feature/auth/login-page
    • bugfix/ui/header-alignment

  4. Update the Codebase
    Make your changes, add files, and commit them using semantic commit messages:

    bash
    git add .
git commit -m "<type>(<scope>): <short description>"

    • Commit Message Structure:

      <type>(<scope>): <short description>

    • Types:

      • feat → New feature.
      • fix → Bug fix.
      • docs → Documentation changes.
      • style → Code style changes (e.g., formatting).
      • refactor → Code refactoring.
      • test → Adding or updating tests.
      • chore → Maintenance tasks.

    Example Commit Messages:

    • feat(auth): add login functionality
    • fix(ui): resolve header alignment issue

  5. Push Your Branch to Remote
    Save your changes to the remote repository:

    bash
    git push origin <branch type>/<scope>/<short-description>

  6. Create a Pull Request

    • Go to the repository on GitHub/GitLab/Bitbucket.
    • Open a Pull Request to merge your branch into the main branch.
    • Follow the semantic versioning guidelines for PR titles and add a clear description of your changes.

Versioning (Semantic Versioning) ​

Use Semantic Versioning (MAJOR.MINOR.PATCH) to manage releases:

  • MAJOR: Breaking changes (e.g., incompatible API updates).
  • MINOR: New features that are backward-compatible.
  • PATCH: Bug fixes or minor improvements.

Examples:

  • v1.0.0 → Initial release.
  • v1.1.0 → Added new feature.
  • v1.1.1 → Fixed a bug.

Steps for Maintainers ​

  1. Manage the Pull Request

    • Review changes for semantic conventions in branch names and commits.
    • Approve and merge if the changes follow conventions.

  2. Tag the Release (Optional)
    Create a version tag after merging:

    bash
    git tag -a v<version> -m "Release v<version>"
git push origin v<version>

  3. Delete the Branch (Optional)
    Once the pull request is merged:

    bash
    git branch -D <branch type>/<scope>/<short-description>
git push origin --delete <branch type>/<scope>/<short-description>

Workflow Summary ​

  1. Branch Naming Convention: <branch type>/<scope>/<short-description>

    • Example: feature/auth/login-page

  2. Commit Convention: <type>(<scope>): <short description>

    • Example: fix(ui): resolve header alignment issue

  3. Versioning: MAJOR.MINOR.PATCH

    • Example: v1.2.0

  4. Tagging Releases:
    Tag releases to maintain version history:

    bash
    git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0

Following these conventions ensures a clean and scalable workflow.