0Pricing
Git Advanced: Monorepo, Submodules & Workflows · Lesson

GitLab Flow and Release Management

Explore the GitLab Flow, focusing on its integration with CI/CD and efficient release management practices.

GitLab Flow and Release Management is a free Git Advanced: Monorepo, Submodules & Workflows lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Git Advanced: Monorepo, Submodules & Workflows learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What is GitLab Flow?

The GitLab Flow is a streamlined Git workflow that combines feature-driven development with release management and CI/CD integration.

It's designed to be simple, effective, and to work seamlessly with GitLab's built-in features like Merge Requests and pipelines.

Main Branch & Environments

At its heart, GitLab Flow uses a single main branch (often named main or master) as the source of truth.

  • Feature branches: All new work happens here.
  • Environment branches: Dedicated branches (e.g., pre-production, production) track deployed code.
  • CI/CD: Heavily integrated to automate testing and deployments.

Developing New Features

When starting new work, you'll create a feature branch directly from the main branch. This keeps your main branch stable.

Naming conventions are key, like feature/add-user-profile or bugfix/fix-login-error.

Here's how you might start a new feature:

git checkout main
git pull origin main
git checkout -b feature/new-dashboard

Code Review with MRs

Once your feature is complete on its branch, you open a Merge Request (MR) to merge it back into main.

MRs are central to GitLab Flow:

  • They trigger CI/CD pipelines for testing.
  • They facilitate code review by your teammates.
  • They track discussions and approvals.

Deploying to Staging

After a feature branch is merged into main, the main branch itself is often deployed to a staging environment automatically by CI/CD.

This allows for final testing in an environment that closely mirrors production before the code goes live.

The main branch is always deployable.

The Production Branch

For production deployments, GitLab Flow often uses a dedicated production branch. This branch only contains code that has been successfully deployed to the live environment.

When main is ready for production, you merge main into production, which triggers a production deployment.

git checkout production
git pull origin production
git merge main
git push origin production

Marking Releases with Tags

When a deployment to production is successful, it's good practice to create a Git tag on the production branch.

Tags act as permanent markers for specific release versions (e.g., v1.0.0, v1.0.1). They help you easily refer back to a released state.

git checkout production
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

Handling Hotfixes

If a critical bug is found in production, a hotfix is needed. In GitLab Flow, hotfixes are typically handled by creating a branch directly from the production branch.

Once fixed, it's merged back into production (triggering redeploy) and then also merged into main to ensure main is up-to-date.

CI/CD at its Core

The true power of GitLab Flow comes from its tight integration with CI/CD pipelines.

  • Automated Tests: Every push to a feature branch runs tests.
  • Deployment Automation: Merges to main or production can automatically deploy.
  • Quality Gates: Pipelines can prevent merges if tests fail or code quality is low.

GitLab Flow Check

Consider the typical structure of GitLab Flow.

Recap: GitLab Flow

You've explored the GitLab Flow, a robust workflow for continuous integration and delivery.

  • It uses a stable main branch.
  • Feature development happens on separate branches.
  • Merge Requests drive code review and CI/CD.
  • Dedicated environment branches (like production) ensure smooth releases.
  • Hotfixes are handled by branching from production.

This flow is ideal for teams leveraging GitLab's full suite of features.

Frequently asked questions

Is the “GitLab Flow and Release Management” lesson free?

Yes — the full text of “GitLab Flow and Release Management” is free to read here on the web, and the Git Advanced: Monorepo, Submodules & Workflows course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Git Advanced: Monorepo, Submodules & Workflows course, upgrade to CoddyKit PRO.

What will I learn in “GitLab Flow and Release Management”?

Explore the GitLab Flow, focusing on its integration with CI/CD and efficient release management practices. You practise Git Advanced: Monorepo, Submodules & Workflows with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Git Advanced: Monorepo, Submodules & Workflows?

No prior experience is required. Git Advanced: Monorepo, Submodules & Workflows on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “GitLab Flow and Release Management” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Git Advanced: Monorepo, Submodules & Workflows lesson?

Yes. Every Git Advanced: Monorepo, Submodules & Workflows lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Git Flow vs. GitHub Flow
  2. GitLab Flow and Release Management
  3. Feature Branching and Hotfixes
  4. Trunk-Based Development and Continuous Integration
← Back to Git Advanced: Monorepo, Submodules & Workflows