Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/egeuysall/ryva-archive/llms.txt

Use this file to discover all available pages before exploring further.

Ryva uses a modified Git Flow workflow with strict commit message conventions to maintain a clean and organized codebase.

​
Git Flow Overview

We follow a structured branching strategy: 
master (production)
  ↑
release/* ← develop (integration)
             ↑
             feature/*
             fix/*
             refactor/*

​
Protected Branches

master and develop are protected branches:
  • Requires at least 1 approval before merging
  • All CI/CD checks must pass
  • Direct pushes are forbidden
  • Must be updated via Pull Requests only

​
Daily Development Workflow

1

Update Develop Branch

Start by ensuring your local develop branch is up to date:
git checkout develop
git pull origin develop
2

Create Feature Branch

Create a new branch following the naming convention:
git checkout -b feature/RYVA-123-new-feature
3

Make Changes

Develop your feature and commit regularly:
# Make your changes
git add .
git commit -m "feat(scope): add new feature"
4

Keep Branch Updated

Regularly sync with develop to avoid conflicts:
git fetch origin
git rebase origin/develop
5

Run Tests and Linters

Before pushing, ensure quality checks pass:
make test && make lint
6

Push Your Branch

Push your branch to the remote repository:
git push origin feature/RYVA-123-new-feature
7

Create Pull Request

Create a PR on GitHub targeting the develop branch.
8

Address Review Feedback

Make requested changes and push additional commits:
# Make changes based on feedback
git add .
git commit -m "fix(scope): address review feedback"
git push origin feature/RYVA-123-new-feature

​
Commit Message Convention

We follow the Conventional Commits specification.
Automated Validation: Commit messages are validated by:
  • Pre-commit hook (locally before commit)
  • CI/CD pipeline (in pull requests)
Invalid commits will be rejected automatically.

​
Format

<type>(<scope>): <subject>

[optional body]

[optional footer(s)]

​
Commit Types

TypeDescription
featNew feature
fixBug fix
docsDocumentation changes
styleCode style changes (formatting, missing semicolons)
refactorCode refactoring without changing functionality
perfPerformance improvements
testAdding or updating tests
buildChanges to build system or dependencies
ciChanges to CI/CD configuration
choreOther changes that don’t modify src or test files
revertReverts a previous commit

​
Scope (Optional)

The scope should be the name of the affected module:
  • api - Backend API changes
  • web - Frontend web app changes
  • auth - Authentication-related changes
  • db - Database-related changes
  • ui - UI component changes

​
Subject Rules

  1. Use imperative, present tense: “change” not “changed” nor “changes”
  2. Don’t capitalize the first letter
  3. No period (.) at the end
  4. Maximum 100 characters

​
Commit Examples

feat(auth): add JWT token validation

​
Validation Rules

Header (first line):
  • Max 100 characters
  • Must match pattern: type(scope): subject
  • Subject must be lowercase
  • No period at the end
Body (optional):
  • Blank line after header
  • Max 100 characters per line
  • Explain WHAT and WHY, not HOW
  • Reference issues/tickets
Footer (optional):
  • Blank line before footer
  • Use for breaking changes and issue references
  • Format: BREAKING CHANGE: description or Fixes #123

​
Testing Your Commit Message

# This will fail
git commit -m "updated code"
# Error: 'updated' is not a valid type

​
Release Process

We follow Semantic Versioning: MAJOR.MINOR.PATCH
  • MAJOR: Breaking changes
  • MINOR: New features (backwards compatible)
  • PATCH: Bug fixes (backwards compatible)
1

Create Release Branch

Create a release branch from develop:
git checkout develop
git pull origin develop
git checkout -b release/v1.2.0
2

Update Version Numbers

Update version in:
  • package.json files
  • API version constants
  • CHANGELOG.md
3

Final Testing

Run comprehensive tests:
cd apps/api && make test-all
4

Commit Version Bump

git add .
git commit -m "chore(release): bump version to 1.2.0"
5

Create PR to Master

git push origin release/v1.2.0
# Create PR with title: "Release v1.2.0"
# Requires 2 approvals for release branches
6

Tag the Release

After merge, tag the release:
git checkout master
git pull origin master
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin v1.2.0
7

Merge Back to Develop

git checkout develop
git merge master
git push origin develop
8

Cleanup

git branch -d release/v1.2.0
git push origin --delete release/v1.2.0

​
Release Checklist

  • All features merged to develop
  • All tests passing with 80%+ coverage
  • Documentation updated
  • CHANGELOG.md updated
  • Version numbers bumped
  • Release notes prepared
  • Database migrations tested
  • Environment variables documented
  • Deployment plan ready
  • Rollback plan documented

​
Hotfix Process

For urgent production fixes:
Hotfix Criteria:
  • Security vulnerabilities
  • Critical bugs affecting all users
  • Production outages
  • Data integrity issues
1

Create Hotfix Branch

Branch from master, not develop:
git checkout master
git pull origin master
git checkout -b hotfix/RYVA-999-critical-fix
2

Make the Fix

Implement and test the fix thoroughly:
# Make your fix
make test-all
3

Commit and Push

git add .
git commit -m "fix(api): patch critical security vulnerability"
git push origin hotfix/RYVA-999-critical-fix
4

Create PR to Master

Create PR with fast-track review process.
5

Tag Patch Version

After merge:
git checkout master
git pull
git tag -a v1.2.1 -m "Hotfix version 1.2.1"
git push origin v1.2.1
6

Merge Back to Develop

git checkout develop
git merge master
git push origin develop

​
Common Git Commands

Useful commands for daily workflow:
git status

​
Best Practices

  1. Commit often: Small, focused commits are easier to review
  2. Write descriptive messages: Future you will thank present you
  3. Keep branches up to date: Rebase regularly to avoid conflicts
  4. Test before pushing: Ensure all tests pass locally
  5. Review your own code: Check the diff before creating a PR
  6. Clean up branches: Delete merged branches to keep things tidy

Build docs developers (and LLMs) love

Get started for freeTalk to us