GitLab Branching Strategy | GitLab Flow Tutorial Part 1

Maximize your productivity with the GitLab Flow. Learn about the GitLab Flow, the recommended branching strategy for GitLab in this tutorial. In this video I discuss the two versions of the GitLab Flow, Environment and Release branches, and provide a conceptual overview of how the strategies work. Perfect for DevOps Specialist/Engineers, Developers, and Product Managers

TOC:
Introduction: 00:00
GitLab Flow Environment Branches: 01:20
GitLab Flow Release Branches: 11:13
Conclusion: 15:17

[tech_with_moss]

TOC:
Introduction: 00:00
GitLab Flow Environment Branches: 01:20
GitLab Flow Release Branches: 11:13
Conclusion: 15:17

[philrichards]

Well, that made a lot more sense than watchinf one of the "official" GitLab videos on the subject. Nicely done.

One quibble: Git's internal data structure is a DAG (Directed Acyclic Graph) not a Linked List.

[is-gmhg]

Another master piece. Moss does not stop surprising me. Thanks again for your time and effort to illuminate us. Best wishes

[sanees]

Please make a video on gitlab keywords and its usage, especially on how to use gitlab variables in the pipeline. E.g using aws access keys as credential to do terraform plan and apply on a specific account

[syunwei]

Awesome video!!! Thanks for explaining and sharing!!! Was able to understand GitLab Flow in 16 mins :D, awesome!!!

[RicardoBoriba]

this one is pure Gold!! Thanks for the effort

[jamesdevitt]

awesome video, makes learning gitlab flow soooo much easier!

[aaronhenderson]

Wonderful breakdown of environment branches vs release branches.

[kisstamas]

thanks for the video :) its very greate content, I just have a little concern about a thing, I share it with you:
you create your feature branches from the master, after you finish you merge back to the main with merge request, you will run your automated tests, but at this point your code can contains bugs, thats why you test in staging/pre-production branch also (manual testing). So during this, somebody can create a new feature branch form the main branch wich can contains some bugs. Is this all right?
My solution is:
- create feature branch from main
- merge to staging branch from feature branch with merge request
- run automate tests (unit, e2e, etc..)
- merge to staging, deploy pre-production/test environment
- test you feature in test environment with others
- create merge request to main branch
- run automated tests again
- deploy to production

What do you think about it?

[adonsav]

Awesome explanation! Thanks a lot for your effort and time.

[vitaerial]

Very helpful and valuable. Clarifies a lot. Thanks

[Kikeron]

What if you have a huge application with multiple installations across the world? These installations in general are the same codebase (with heavy configuration from the application) but with one or two instances of old versions that cannot be ported? Which git branching strategy is the best in your opinion?

[dinushkam]

Great video, very difficult to find detailed deep knowledge videos

[bhavyawadhwa]

This is actually nice explanation, thanks, could you please provide and blog or pdf or any reference document for "GitLab Flow with Release Branches", as I want to implement and couldnt find on internet.

[ManishKumar-uyio]

Why do you suggest a fast forward commit instead of a merge commit from main to production branch

[markusr]

Hi, thanks for the great video. What i don’t understand is how i can tell GitLab to fast-forward merge only in the pro-production and production branch…. That’s exactly what i am searching for because it prevents me to merge the production back to main every time. Is there a setting for that?

[RenéZanner]

Cherry-picking of bug-fixes from main/master work only, when the main branch is still compatible with the release branch source code. That was the reason for the GitFlow approach, I guess. How does GitLab Flow solve this?

[SundarLalCh]

How you maintain binary integrity if code getting merged to multiple branches

[arber]

Why do we need the main branch? Couldn't we just use a staging branch and a production branch? Feature branches could be created based on the staging branch and later merged back. The staging branch can be merged in the production branch when it's ready. If a bug fix is needed on the production while the developement is going on in the staging branch, we could create a hotfix branch based on the production branch, fix it and merge it back to production and the staging branch. What are the advanteges of having a main branch? What am I missing? Thank you!

[kaizoey]

What is the difference between staging and pre-production?