-
Notifications
You must be signed in to change notification settings - Fork 1
Name Conventions
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.
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.
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>
-
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.
-
-
Reference β After the category, add a
/
followed by the issue or ticket reference (e.g.,issue-42
). If thereβs no reference, useno-ref
. -
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-
.
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.
Β© 2024 Sporta Team. All rights reserved.