Git Workflow

1. Introduction

This document outlines the Git usage policy for the company to ensure a structured, efficient, and collaborative workflow. All team members must follow these guidelines to maintain consistency and quality in our version control process.

2. Repository Structure

• Each project must have a central repository hosted on Bitbucket.
• The default branch is main.
• Feature development, bug fixes, and other changes should be done in separate branches.

3. Branching Strategy

Use Git Flow methodology:

• main: Stable production-ready code.
• develop: Integration branch for new features.
• feature/{feature-name}: For developing new features.
• bugfix/{issue-id}-{short-description}: For fixing bugs.
• hotfix/{short-description}: For urgent fixes in production.
• release/{version-number}: For preparing new releases.

4. Commit Messages

Follow the Conventional Commits format:

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

Example:

feat(auth): add JWT authentication

Commit Types:

• feat – A new feature.
• fix – A bug fix.
• docs – Documentation changes.
• style – Code style changes (formatting, white-space, etc.).
• refactor – Code refactoring without changing behavior.
• perf – Performance improvements.
• test – Adding or updating tests.
• chore – Other changes (build scripts, dependencies, etc.).

5. Pull Requests (PR)

Creating a Pull Request

• Ensure your branch is up to date with develop.
• Follow naming conventions: feature/{feature-name}, bugfix/{issue-id}-{short-description}.
• Ensure your code follows clean coding practices.
• Write a clear PR description:
• What was changed?
• Why was it changed?
• How to test it?
• Link related issues (Closes #issue-number).

- At least one reviewer must approve before merging.
- The reviewer checks for:
  - Code quality and best practices.
  - Correct implementation of requirements.
  - Proper documentation (if needed).
  - Passing tests and build.
- Address reviewer comments before merging.

Merging PRs

• Only squash and merge or rebase and merge.
• No direct commits to main or develop.
• Delete branches after merging.

5. Code Reviews

• Every PR must be reviewed before merging.
• Use constructive feedback.
• Ensure changes align with best practices and company guidelines.

6. Handling Merge Conflicts

• Resolve conflicts locally before pushing.
• Test changes after resolving conflicts.
• If unsure, ask for assistance before pushing.

7. Tagging and Releases

Use semantic versioning (vX.Y.Z):

• X – Major changes.
• Y – Minor updates.
• Z – Patches or bug fixes.

Tags should be created from the main branch.

Example:

git tag -a v1.0.0 -m "Initial stable release"

8. Best Practices

• Commit small, atomic changes.
• Write meaningful commit messages.
• Keep branches short-lived and merge them frequently.
• Avoid pushing large files or secrets.
• Use .gitignore to exclude unnecessary files.