Skip to main content

​
Why Version Control? 🌍

Learn how to update your docs locally and deploy them to the public Version control systems are essential tools in our development workflow, allowing us to:
  • Record Code Evolution: Keep a detailed log of every change.
  • Enable Collaboration: Facilitate multiple developers working in parallel.
  • Easily Roll Back: Revert to previous versions when necessary.
  • Ensure Code Stability: Support consistent, production-ready code.

​
​

Commit Message Standards 📜Clear, concise commit messages make it easy to understand the purpose of each code change. Our commit message categories help with consistency:
  • feat: Adds a new feature.
  • fix: Corrects an existing issue.
  • chore: Handles routine updates like dependency changes.
  • refactor: Improves code structure without altering functionality.
  • docs: Updates documentation files.
  • style: Applies non-functional formatting changes.
  • test: Adds or modifies tests.
  • perf: Enhances performance.
  • ci: Adjusts continuous integration configurations.
  • build: Modifies build scripts or dependencies.
  • revert: Reverts a previous change.
  • meta: Updates metadata like contributors or licenses.

​
​

Example:"feat: Add user profile customization feature"

​
​

Branching Strategy 🌿We follow a structured branching strategy to keep development organized and releases smooth.
  • Main Branch: main is the production-ready branch where stable code resides, tagged for each release.
  • Develop Branch: develop serves as the integration branch where tested features merge before release.
  • Feature Branch: Named feature/{feature-name}, each new feature gets its own branch off develop.
  • Fix Branch: Named fix/{issue-identifier}, these branches address non-critical bug fixes and merge back into develop.
  • Release Branch: Named release/{release-version}, this branch finalizes a version for production with any last adjustments.
  • Hotfix Branch: Named hotfix/{issue-identifier}, used for urgent fixes directly on main, then merged into both main and develop.

​
​

Release Management 🚀Our release management process ensures stability, quality, and consistency in production.
  • Planning: Define release scope based on feature readiness.
  • Release Branch Creation: Create a release branch from develop for final changes.
  • Testing: Comprehensive tests validate the code before release.
  • Versioning: Follow semantic versioning (X.Y.Z) where:
    • X = major release
    • Y = minor update
    • Z = patch
Example tag: Copy 
git tag -a v2.1.0 -m "Version 2.1.0 Release"
  • Deployment: Publish to production with appropriate support.
  • Post-release Monitoring: Observe the release for stability and gather user feedback.

​
​

Change Log Management 📋A detailed change log provides a clear record of modifications. Each entry in our change log includes:
  • Type: (e.g., Added, Changed, Fixed, Removed)
  • Description: Brief summary of the change.
  • Author: Name of the contributor.
  • Merge Request Link: URL to the relevant merge request.
  • Reference Link: URL to the related issue or discussion.
  • Date: Date of the change.
Example Entry: Copy 
## [2.1.0] - 2024-11-14
### Added
- **Description**: Introduced enhanced profile customization.
- **Author**: Alex Rivera
- **Merge Request**: [#101](https://github.com/project/repo/merge_requests/101)
- **Reference**: [#210](https://github.com/project/repo/issues/210)
- **Date**: 2024-11-14

​
​

Commit Naming Conventions 🖋️For clarity, commit messages follow this standard format:
  • Type: Action type (e.g., Add, Fix, Update, Remove).
  • Scope: Project area (e.g., profile, dashboard).
  • Description: Concise summary of the change.
Example: Add(profile): Enable profile picture upload
This process ensures that every code change at Yafi is well-organized, fully documented, and easy to track, supporting high-quality releases and effective teamwork.