A consistent branch naming convention is part of code review best practices.

1. 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.

2. 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.

1. feature/XXX

example: features/homepage

1. release/XXX

example: releases/1.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.

1. 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+ .

2. 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.

3. Enabling push rules

4. Prevent pushing secrets to the repository

Reference 🧐

• Atlassian
• pre-receive Git hooks
• Push Rules