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

Wonderful breakdown of environment branches vs release branches.

By far the best video on this topic. Much better than everything GitLab puts out on this, for sure.

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.

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

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

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

Some of your work are amazing man and this is definitely one of them.

this one is pure Gold!! Thanks for the effort

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

awesome video, makes learning gitlab flow soooo much easier!

Great overview!

Very helpful and valuable. Clarifies a lot. Thanks

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?

It is really informative and nicely presented. For the env based branching strategy, where should I carry out bug fixing? I mean, after merging 'main' to 'pre-prod', if a test team finds some errors then fixing of those bugs should be carried out on 'pre-prod' branch Or 'main'? 1. If the answer is 'pre-prod' then should I fix bugs directly on 'pre-prod' branch or create 'feature' branch from 'pre-prod' ? (I believe this might not be a right approach as this will require merging 'pre-prod' bug fixed commit back to 'main' which would add complexity) 2. If the answer is 'main' then should I fix bug by creating 'feature', then merge 'feature' to 'main', and then merge 'main' to 'pre-prod'? Apologies for asking multiple queries in single comment, appreciate if you could help me clarify the doubts. Thanks in advance.

Wonderful video. Subscribed!!!

Awesome content🙂

Great video, very difficult to find detailed deep knowledge videos

Thnx a lot dude, you are best

Thanks 🙏.

Thanks for the explanation, this was very helpful I have a question... we configure the repository settings to perform only fast forward merges (as shown in the Part 2 video) Doesn't this mean that the merge from feature-branch to main-branch is also treated as a fast forward merge? And hence no merge commits are allowed?

Thanks a lot for the video. I like the env based branches strategy as it naturally relates to the environments a team usually has. So how should we go about the hot fixes in the env based version of the flow? This is not mentioned in the video. The fact that you assume only fast forwards tells me that it also should be a cherry pick from the main branch?

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?

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.

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?

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?

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!

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

What is the difference between staging and pre-production?

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

plz complete the series dont leave it in between

How to do if the production branch is a main branch?

Thanks for your video! I am still learning different branching strategies for our work. However, we are facing an issue that we have concurrent developments for different features, but the feature release to production could be different. For example, feature 1 start development from 1st Jul and completed at 15th Jul, feature 2 start development from 8th Jul and completed at 20th Jul. However, feature 1 take a long time for UAT like finished at 25th Aug but feature 2 finish UAT fast at 5th Aug. In order to release the feature 2 asap, in GitLab Flow how can I release feature 2 at 15th Aug but the release does not include feature 1(because at 15th Aug feature 1 still under UAT)?

Thank for your video. I think Environment branches are suitable for SaaS that need deploy to an environment. Release branches are suitable for software that is a software simply, it don't need deploy, user will do that. If i have a release, beside, i want provide a release as a service, can i use both versions?

as an admin how can i download all users data from gitlab?

Could shere me git lab full course

HELP