Skip to content

Name Conventions

Ziad Elsharkawi edited this page Nov 4, 2024 · 6 revisions

To maintain clarity and consistency across our project, we follow standardized conventions for commit messages and branch naming. Below, you’ll find our guidelines for each, along with examples to illustrate proper usage.


Commit Message Convention

We follow the Conventional Commits specification to ensure commit messages are informative and standardized. Our commit message structure is as follows:

Format: GH-#: [purpose] Message

Components:

  • # – The issue or ticket number related to the commit (e.g., 42).
  • purpose – The purpose of the commit, chosen from the list below.
  • Message – A brief, clear message that starts with a capital letter and describes the changes.

Accepted Purposes:

  • build: Changes that affect the build system or external dependencies.
  • chore: Miscellaneous tasks such as updating dependencies.
  • ci: Continuous integration-related changes.
  • docs: Documentation changes.
  • feat: A new feature.
  • fix: A bug fix.
  • perf: Performance improvements.
  • refactor: Code restructuring that doesn’t add features or fix bugs.
  • revert: Revert a previous commit.
  • style: Formatting changes, missing semi-colons, etc.; no code changes.
  • test: Adding or modifying tests.

Example: GH-2: [feat] Added new endpoint

Remember to adhere to the specified spaces and capitalization.


Branch Naming Convention

To keep our Git workflow organized and clear, we use a structured branch naming convention. This enables team members to quickly understand the purpose of each branch.

Format: <category/reference/description-in-kebab-case>

Components:

  1. Category – Start with a category from the list below:

    • feature: Adding, refactoring, or removing a feature.
    • bugfix: Fixing bugs.
    • hotfix: Temporary or emergency solutions that may not follow the usual process.
    • test: Experimental work outside of an issue/ticket.
  2. Reference – After the category, add a / followed by the issue or ticket reference (e.g., issue-42). If there’s no reference, use no-ref.

  3. Description – Finally, add another / and a brief, kebab-cased description of the branch purpose (e.g., create-new-button-component). Use the issue or ticket title where possible, replacing special characters with -.

Examples

Purpose Command
Adding a feature git branch feature/issue-42/create-new-button-component
Fixing a bug git branch bugfix/issue-342/button-overlap-form-on-mobile
Hotfix for an emergency git branch hotfix/no-ref/registration-form-not-working
Experimenting git branch test/no-ref/refactor-components-with-atomic-design

For additional details, please refer to this branch naming convention guide.


Following these conventions will help keep our repository organized and make our Git history easier to understand.