Git Standards

Introduction

This document outlines the standard practices and guidelines for using Git within our team. The goal of this standard is to promote consistency, efficiency, and collaboration among team members when managing code changes. By adhering to these guidelines, we can ensure that our Git workflows are well-organized, maintainable, and conducive to effective teamwork.

Branch naming convention

Purpose: To establish a consistent and informative naming convention for Git branches, ensuring easy identification and traceability of code changes.

Format:

• Feature branches: feat/<jira_ticket_name>
  • Example: feat/ZT-1234
• Bugfix branches: fix/<jira_ticket_name>
  • Example: fix/ZT-3456
• Documentation branches: docs/<jira_ticket_name>
  • Example: docs/ZT-6789
• Refactoring branches: refactor/<jira_ticket_name>
  • Example: refactor/ZT-1011

Commit Messages Convention

Purpose: To promote clear, concise, and informative commit messages following the Conventional Commits specification. This ensures consistent communication about code changes and facilitates automated tooling like versioning and changelogs.

Reference: The Conventional Commits specification: https://www.conventionalcommits.org/en/v1.0.0/

Format:

The Conventional Commits format consists of three parts:

1. Type (REQUIRED): A single word in lowercase prefixed with a colon (:) indicating the nature of the change. Common types include:

   • feat: Introduces a new feature.
   • fix: Fixes a bug.
   • docs: Adds or updates documentation.
   • style: Changes code formatting or styling without affecting functionality.
   • refactor: Improves code structure without adding new features or fixing bugs.
   • test: Adds or updates tests.
   • perf: Improves performance.
   • ci: Changes the CI configuration.
   • chore: Other maintenance or build tasks not related to features or bugs.

2. Scope (OPTIONAL): A bracketed and optional section specifying the area of the codebase affected. Use PascalCase for scopes. (e.g., (auth), (UI))

3. Description (REQUIRED): A concise, lower-cased description of the change. It should answer the question "What changed?"

Example:

fix(auth): Handle invalid login attempts gracefully

Benefits:

• Improved Communication: Clear and concise commit messages facilitate understanding code changes for developers.
• Versioning and Changelogs: Automated tools can use commit messages to generate version changelogs with accurate information.
• Collaboration: Consistent commit messages promote better collaboration and code review practices.

Additional Considerations:

• Imperative Tense: Describe changes in the present tense (e.g., "fixes", "adds").
• No Period: Omit a period (.) at the end of the description.
• First Line Wrap: Keep the type, scope, and description within 72 characters to avoid wrapping in most Git GUIs.