Branch name convention, an example

 

 

 Branch name convention

 

1. Prefix with ticket number: Start the branch name with the ticket number associated with the task or issue being addressed. This ensures that branches are easily identifiable and linked to specific tickets in the project management system.
2. Use hyphens for readability: Separate the ticket number from the branch description using hyphens for readability. This helps team members quickly understand the purpose of the branch without having to inspect its contents.
3. Use descriptive branch names: After the ticket number, provide a brief but descriptive name for the branch that summarizes the changes being made. This can include keywords related to the feature, bug fix, or enhancement being implemented.
4. Limit length: Keep branch names concise to avoid excessive verbosity. While it's essential to provide enough information for clarity, overly long branch names can become cumbersome and difficult to manage.
5. Lowercase and dashes: Stick to lowercase letters and use dashes instead of spaces in branch names to ensure compatibility across different operating systems and Git hosting platforms.

 

Branch conventions

Format: <type>/<JIRA issueNumber>-<description>

Example: feature/RSDE-2389-add-user-authentication

• feature indicates that it's a feature branch.
• rsde-2389 is the ticket number associated with the task → Jira task number
• add-user-authentication provides a clear description of the changes being made.

Git branch prefixes

Using prefixes in branch names is a popular strategy to categorize branches based on their purpose:

 

Git Branch Prefixes

Prefix	Purpose
Prefix	Purpose
feat/	New features
fix/	Bug fixes
chore/	Maintenance tasks
docs/	Documentation updates
refactor/	Code refactoring
test/	Adding or updating tests
hotfix/	Urgent fixes (e.g., production)
release/	Release preparation
perf/	Performance improvements
style/	Code style or formatting changes
ci/	CI/CD pipeline updates
build/	Build process or dependency changes
wip/	Work in progress
revert/	Reverting commits

 

---

Repository model for AI-QA

• main: Main branch
• chore: ORT copies
• wip : Work in progress, after a while it can be wiped out safely
• feat, docs, fix, ci: All these could end into a pull request and then be deleted

Example

# Main branch main # Ort copies, NS -> No Story chore/ NS_2024_11_05_ort_branch NS_original_ort_branch # Work in progress, after a while it can be wiped out safely wip/ NS_last_version_without_id # All these below would end into a pull request and then be deleted feat/ RSDET-1234_adding_a_great_feature docs/ RSDET-1332_documentation_readme fix/ RSDET-3333_nasty_bug ci/ RSDET-4444_add_plugin_to_Jenkins

Best Practices for Branch Naming

1. Keep branch names descriptive yet concise:
• Example: feat/add-user-authentication is better than feat/auth.
2. Separate words with hyphens:
• Example: fix/typo-on-homepage instead of fix_typo_on_homepage.
3. Use prefixes consistently:
• Always use the same prefixes for similar tasks.
4. Avoid personal identifiers:
• Instead of john/fix-login, use fix/login.
5. Include ticket/issue IDs when applicable:
• Example: feat/PROJ-123-add-dashboard.

 

 

Pull request conventions

Pull Request Naming Convention

The PR title should summarize the changes in a concise and clear manner.

Naming convention: Pull request title should be: <type>: [JIRA issueNumber] <description>

where

<type> - one of following [optional scope] - additional information
<JIRA issueNumber> - Jira issue number in brackets or NS for no story
<description> - description of pr

Examples:

✅ Good Titles:

• feat: [RSDET-1234] Add user authentication module
• fix: [RSDET-1223] Resolve login page crash on invalid input
• chore: [RSDET-1234] Update dependencies for security fixes

❌ Bad Titles:

• fix bug
• new feature
• updates

 

Prefixes:
FYI: Key Differences Between Branch Prefixes and Pull Request Prefixes

Aspect	Branch Prefixes	Pull Request Prefixes
Purpose	To categorize branches based on the type of work (e.g., feature, bugfix, chore).	To provide context about the change in the PR (e.g., new feature, bug fix, refactor).
Scope	Defines branch content and usage.	Describes the overall change set or purpose of the PR.
Relation to Workflow	Tied directly to Git branching strategies.	Used in review processes, linked to task tracking systems like Jira.