A consistent branch naming convention is part of code review best practices.
-
Use ticket ID in your branch names
If you use ticket ID, then it will be very easy to track the ticket also the ticket will be unique.
It doesn't take much time to think about branch name and it more convenient to use it.
-
After prefixing ticket ID, add a short description of the task
If you work with multiple member on same ticket, then it will be really great to add small description after the ticket ID.
There are 2 main naming convention styles within Git. Hyphen(-) separated or slash(/) separated.
- feature/XXX
example: features/homepage
- release/XXX
example: releases/1.1
- hotfix/XXX
example: hotfix/search
You can also integrate push rules into your project, it seems very cool and easy as well. It definitely improves code commit structuring.
How we integrate Push rules in GitLab π€
Push rules are essentially pre-receive Git hooks
that are easy to enable in a user-friendly interface.
In GitLab account go to Project => Settings => Repository => Push Rules
You can define it per project as well, so you can have different rules to different projects.
-
Commit messages with a specific reference
Let's assume every commit should reference a JIRA issue.
Exmaple: JIRA-11
Then we can write a regular expression that requires JIRA issue in the commit message like
JIRA\-\d+
. -
Restrict branch names
If your company has a strict policy for branch names, you may want the branches to start with a certain name.This approach enables different GitLab CI/CD jobs (such as feature, hotfix, docker, android) that rely on the branch name.
Any branch name that doesnβt match your push rule is rejected.
Enabling push rules
Prevent pushing secrets to the repository
Reference π§
π Twitter | π©π»βπ» suprabha.me | π Instagram |
Top comments (1)
how do you ensure the JIRA ID is acutally a valid Jira Issue and Jira Issue Type