> ## Documentation Index
> Fetch the complete documentation index at: https://docs.d4ds-dev.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Version Control 

> At Yafi Engineering, version control is fundamental to managing, tracking, and coordinating code changes. With version control, we maintain a clear history of edits, enable efficient teamwork, and simplify code comparison and rollback. Here’s our approach to version control at Yafi. 

### 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.

### [**​**](https://docs.wavez.tech/engineering/version-control#commit-message-standards-%F0%9F%93%9C)

**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.

#### [**​**](https://docs.wavez.tech/engineering/version-control#example%3A)

**Example:**`"feat: Add user profile customization feature"`

### [**​**](https://docs.wavez.tech/engineering/version-control#branching-strategy-%F0%9F%8C%BF)

**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`.

### [**​**](https://docs.wavez.tech/engineering/version-control#release-management-%F0%9F%9A%80)

**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

```shellscript theme={null}
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.

### [**​**](https://docs.wavez.tech/engineering/version-control#change-log-management-%F0%9F%93%8B)

**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

```markdown theme={null}
## [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
```

### [**​**](https://docs.wavez.tech/engineering/version-control#commit-naming-conventions-%F0%9F%96%8B%EF%B8%8F)

**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.