---
title: What are GitLab Flow best practices?
updated: 2023-04-04 08:41:06Z
created: 2023-04-04 08:41:06Z
tags:
  - IT
  - IT/Tools/Gitlab
source: >-
  https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/
---

When software development teams rush to accelerate delivery, they may end up with messy or complex workflows. Organizations that have transitioned from another [version control](https://about.gitlab.com/topics/version-control/) system are especially likely to deal with challenging processes that may slow down development. When teams use [GitLab Flow](https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/), they can use feature driven development and feature branches with issue tracking to ensure every team member works efficiently. Using these GitLab Flow tips, software development teams can simplify the process and produce a more efficient and cleaner outcome.

 **1\. Use feature branches rather than direct commits on the main branch.**

Using feature branches is a simple way to develop and keep the [source code](https://about.gitlab.com/stages-devops-lifecycle/source-code-management/) clean. If a team has recently transitioned to Git from SVN, for example, they’ll be used to a trunk-based workflow. When using Git, developers should create a branch for anything they’re working on so that contributors can easily start the [code review process](https://about.gitlab.com/topics/version-control/what-is-code-review/) before merging.

 **2\. Test all commits, not only ones on the main branch.**

Some developers set up their CI to only test what has been merged into the `main` branch, but this is too late in the software development lifecyle, and everyone - from developers to product managers - should feel feel confident that the `main` branch always has green tests. It’s inefficient for developers to have to test `main` before they start developing new features.

 **3\. Run every test on all commits. (If tests run longer than 5 minutes, they can run in parallel.)**

When working on a `feature` branch and adding new commits, run tests right away. If the tests are taking a long time, try running them in parallel. Do this server-side in merge requests, running the complete test suite. If there is a test suite for development and another only for new versions, it’s worthwhile to set up \[parallel\] tests and run them all.

 **4\. Perform code reviews before merging into the main branch.**

Don’t test everything at the end of a week or project. Code reviews should take place as soon as possible, because developers are more likely to identify issues that could cause problems later in the lifecycle. Since they’ll find problems earlier, they’ll have an easier time creating solutions.

 **5\. Deployments are automatic based on branches or tags.**

If developers don’t want to deploy `main` every time, they can create a `production` branch. Rather than using a script or doing it manually, teams can use automation or have a specific branch that triggers a [production deploy](https://docs.gitlab.com/ee/ci/yaml/#environment).

 **6\. Tags are set by the user, not by CI.**

Developers should use `tags` so that the CI will perform an action rather than having the CI change the repository. If teams require detailed metrics, they should have a server report detailing new versions.

 **7\. Releases are based on tags.**

Each tag should create a new release. This practice ensures a clean, efficient development environment.

 **8\. Pushed commits are never rebased.**

When pushing to a public branch, developers shouldn’t rebase it, because that makes it difficult to identify the improvement and test results, while [cherry picking](https://git-scm.com/docs/git-cherry-pick). Sometimes this tip can be ignored when asking someone to squash and rebase at the end of a code review process to make something easier to revert. However, in general, the guideline is: Code should be clean, and history should be realistic.

 **9\. Everyone starts from main and targets main.**

This tip prevents long branches. Developers check out `main`, build a feature, create a merge request, and target `main` again. They should do a complete review **before** merging and eliminating any intermediate stages.

 **10\. Fix bugs in main first and release branches second.**

After identifying a bug, a problematic action someone could take is fix it in the just-released version and not fix it in `main`. To avoid it, developers should always fix forward by pushing the change in `main`, then cherry-pick it into another `patch-release` branch.

 **11\. Commit messages reflect intent.**

Developers should not only say what they did, but also why they did it. An even more useful tactic is to explain why this option was selected over others to help future contributors understand the development process. Writing descriptive commit messages is useful for code reviews and future development.