finally, someone summarizes these different branching strategies in an easy way to digest. thanks a lot.

This was outstanding, I loved every word of it. I’ve worked on most of these methods and cannot agree more with your evaluation.

Exceptional! you are a legend, and the way how you explained these strategies, I could not control but ROFL. We started off with GitFlow, and then adapted Release branching and now taking the path of Trunk based!

A git branching strategies video that talks about git branching strategies. And on top of that it explains sums them very well. This should be higher on youtube's list.

You are awesome. The visual & pictorial representations were awesome. Though I spent more than 2 hours understanding this complete video. But this was so much worthy and concentrated content. Thanks for the video 😃

Wow I spent ages reading on articles and other videos and I could never fully understand branching and versioning until I watched your videos. Thank you!

Not only super instructive but also funny :p Excellent as always, thank you !

Nice video, Viktor. Liked the simplified articulation. Great job!

Hey Viktor, Trust me this is one of the best video explanations out in internet. Super thanks for making information as well as fun. I totally get your points and the options for different purposes. And the last takeaway was awesome, Haha.

Excellent video. Thorough and clear enough for someone who has almost no experience with this!

you solved my confusion by summarizing the branching strategies once and for all tysm

This is a great meta topic in our industry, thank you so much for taking the time to dd on this.

Well done for summarizing and comparing all of them 👏👏👏

You just saved me hours preparring my last notes for my exam.. thank you

Great rundown. I LOL'd when you mentioned people using complex strategies for job security. I have people like that at my company.

Luv this! I appreciate your humor ... very helpful.

Excellent presentation. Immediately subbed. Thank you from Ireland.

Great explanation even today :) I've been feeling lately that every other company developed their own branching strategy with its own name :D Even in our team, I have no clue where to categorize our strategy. It is a mix of feature, release, and even maybe an environment strategy. I guess I will never know if there is a team that uses the similar technique :D Cheers!

"...because it will feel like I'm on vacation" I ROTFL there! Great explanation btw, thanks

excellent explanation! Thanks Victor for sharing!

Very informative ! Thank you!

Appreciate this breakdown, thanks!

Excellent video, I like the way you delivered truth with a pinch of sarcasm. Kudos!

Very well illustrated. I don't think you should waste your time watching any other videos about branching strategies

This was a good explanation and illustrated even. Thank you for helping.

you make the topic interesting, thank you.

Really nice overview. Thank you:)

Loved the video, subscribing your channel :) , especially the extreme hatred for Git flow & Env. branches :)

There is a big chunk of strategy that was missed here in relation to trunk based development combined with release branches and environments. My preferred workflow uses trunk based where main/master deploys to a staging environment (or UAT). Then once acceptance testing has completed, a release branch is created to trigger a deployment to production. Hotfixes then can be cherry picked from main into the release branch, as needed, avoiding the branching mess described in this video. This is similar to Gitlab AutoDevOps, but inverted from their default (main/master targets k8s production and other branches target staging environments). This also works well outside of k8s deployment targets.

I'm on the Environment Crap. and have deployment team... when I mentioned "branchless" they told me that doesn't scale or other idiocy.

What an easy and interesting explanation!👍

Thank you for the video!

Thanx a lot for your work!

It's a great video, very crisp and concise !! However, in a corporate development environment there can't be only 1 approach. Probably, it makes sense to use combination of Trunk + Fork + Feature Branch. Here is the reason : Reason : 1) Trunk based - For frequent small feature changes to main branch. 2) Fork Strategy - To limit the developers access to main repository and allow merge into main repo only via PRs. 3) Feature Branch - To have development for major features which tends to break almost everything until they are entirely completed. e.g. TECH stack upgrade etc I know there can be different approaches with Trunk based development, to disable/hide incomplete features (e.g. Dark launch, Branch Abstraction, feature toggles etc). but that requires very high level of maturity of team (which is not always possible with new developers joining once-twice year).

My dumb ass stumbled across the wrong video. I literally have no idea what your talking about and found no clue in the comments. I was just trying to figure out how to create more branches on my cannabis plants. Hats off to u geniuses.

Nice presentation! Thank you!

Great summary and actionable insights

Well done! You should do a talk with the guy from the channel "Continous Delivery", I just saw a video in which he is more for trunk-based development rather than branching. Would love to understand better in an in-depth talk between you two! Btw, the git flow part was really fun!

Great video, thanks really found it to be informative.

Great video, very helpful. Thank you.

Baby dev here: I learned git flow just yesterday and I was so proud of it for a complete day until this video broke my pride bubble :D But seriously, git flow makes a lot of sense, it's not this difficult. Also there are tools that can automate its flow. But I'll trust this video b/c experience talks first.

Outstanding !!

Just to be fair to the Release Branches Strategy: Everything Victor said about it is true, but when it is applied in the Project or Product as a Service business models, when there is only one production environment. However, when business model is Product based, where product is shipped to many customers and there are many production environments, then Release Branches Strategy is viable complementary branching strategy to cover customers that are using different versions of our product (for non-technical legal, regulatory, business... reasons). Actually it is must-have additional branching strategy, in addition to say trunk based development or feature branches that are used for the main stream of development on the current version of the product.

My team _started_ using git flow shortly after I joined the teama few months ago. I was brand new to the team, and don't have a tonne of experience with branching strategies and yet even without knowing exactly why, I just had an almost instinctive revulsion to the new strategy, but as the team newbie, I kept my concerns to myself. Tomorrow though, I think I'm going to share this video with my managers and just let them watch it and take from it what they will.

Wonderful explanation! You have saved my day.

great explanation!

Awesome video, nice and easy explanations

Personal opinion: The testing needed for trunk based development isn't a lot of unit tests. What's needed, in my opinion, is to have a robot equivalent of a QA tester, meaning that the thing will be deployed in an environment just like production, and some component will drive the program like a human would. Teams I worked in didn't like this or even see it as a possibility because it sometimes requires thinking outside the box and being multi-disciplinary in order to implement.

You deserve a million thumbs up!

Stayed for 14:45 my favorite branching workflow 👌😉

In our BI team we use release beanching because things are interconnected. The thing is… you have to commit often

I giggled a bit at the environment branching part, since the idea was pretty intensely circulated in our team meetings a few months ago, as a possible strategy for our IaaC repositories. In the end we went for something most closely resembling feature branching - looks like we dodged a git bullet there :)

thank you, this was great

This explains all the strategies very well. But I think it should also include rollback strategies and which branching strategy makes it easier.

I liked this video very much. Very informative

thank you for this

Interesting video; I liked it. With my 40 years of experience, I agree with most of it. There is an unstated assumption in what is presented here, especially with the trunk based dev. The assumption here is that whatever is in trunk/master/mainline = production. That is not always the case, and it is where I diverge from agreeing. This is due to Continuous Deployment, which I personally, am not a fan of. I prefer a human in the loop. I follow the Apache Maven approach. Yes, Forking and PR's are used [to good effect], but commits to master can (and sometimes do) create a dirty/broken master. But this is not a problem, as we choose when to perform a Release - it is not automatic - why I don't like Continuous Deployment. Once is a Release is performed, it's out in the wild, and we prepare for the next release. Always moving forward. Cut a Release, moving it through environments until it fails testing or hits Prod. You make this point well, where you point out that we're not deploying source into production (unless you're using Ansible!), we make packages and deploy them as need be. Why don't I care that trunk does not equal production? What if there is more than one? OS Libraries and some of my work places have more than one production, so having trunk represent 'production' what ever that is, is meaningless. One thing that I'd add/challenge: I understand why you say that you need a disciplined team for trunk, but my experience shows that feature branching requires a higher level of maturity and discipline so that you DO limit branch lifetimes. Otherwise you end up in merge hell and everything comes to a sudden halt due to the inability to deliver any change. So, I take the KISS approach for everything that I've ever done, trunk based dev has worked for me, and what I recommend. Only go more complex if you absolutely need too. TBH, there was ONE exception, where there were monthly release branches with overlapping dev (due to testing resources), but we simplified things by never having to merge back to master (no point). R2210->R2211->R2212->R2301 etc.

Excellent video! I think you left out the biggest madness of all -> Not having a documented strategy, ending up with some crazy mix of all of the above and hundreds of branches -> Madness Level = Suicidal... Might be worse than using Outlook for source control.

Great Video. Thanks Victor

Ah, good old branch per environment merging. I still have nightmares! Happy feature branch user now :). Great video as always.

loved the conclusion at the end! The beginning was more like he was biased towards trunk based dev and thought that is what he was going to conclude. It was refreshing to hear otherwise

There are millions of ways to branch. All the strategies you mentioned fall into a single family. Branching with git opens up so much potential. Yet, the industry is stuck on one flavor, as always.

7th of April, 2005. Release date of Git. However, Victor is using branching strategies for 30+ years. LEGEND, still think you're the best DevOps youtube and can't stop wathing and learning from you! Keep the great job mate!

hahaha loved the conclusion ! RUN !

OMG, thx a lot Papa Varcic

Great job on this video! It was spot on and also had some really funny moments. “Cake made of mud..” 😂

That madness caused by git-flow, I am experiencing it in my veins these days as I switched to a team that uses git-flow. When I share my opinions with the more experienced engineers, they keep producing arguments against me which freaks me out.

haha, thanks a lot for this video. Awesome take on this subject. I'ma send this video to all the old heads i know, who still believe Git Flow/Environment branching is the right way to go. Tired of convincing :P

Best video on guy I’ve ever watched

Loved it ❤ thanks! But you're not completely fair on gitflow: it's not that complicated : it's like the feature flow but with extra steps (and, from what i've seen, some steps, like the release branch are, often, not even used !)... ... And, often (e.g. if you don't have strong tests, ci/cd ) you don't realy have the choice :(

Really nice overview. Thanks

I've worked in many teams that use short lived feature branches (that exist for a day or two) and they call it trunk based development. And I agree with them. What you call feature branching is essentially the same as trunk based development since you need feature switches because you are essentially pushing to the trunk regularly.

I think release branches can make sense for mobile applications or IoT software where you simply can't deploy updates on-demand, or force users to update remotely.

What no one realizes is even in feature branching or trunk based development or release branching we all encounter merge conflicts etc., because the business team wants 3 big features in the same javascript or java or typescript file at the same time which will be taken in same sprint and the leads and devs are supposed to deliver that.

Great video thanks. Though I will step in to defend git flow a little here since it seems no one else wants to :) ... When I use git flow, the release branches / hotfix branches are like a stepping stone to main, then main (which one would tag / release from anyway) gets merged back to dev instead of the original branch. It makes things a lot simpler vs oft-documented git flow per-branch stuff and cuts out the "more or less sometimes eventually up to date" bit (1 tag = one merge back to dev rather than depending on the merger to know how to / remember to merge individual branches back to dev - which admittedly they wouldn't remember to do otherwise). I think it depends a lot the sensitivity of the software you're writing, the manual testing / team involved, the stability / confidence required etc (after all, unit tests / integration tests get bugs too). I do a lot of specialist development so those factors have been important pretty much anywhere I have went. Effectively it depends on whether or not you need release branches to stage for extensive and/or expensive non-automatable QA while ongoing bleeding development testing can continue in isolation. It also gives you a more formal and well defined version of environmental branching too without doing an environment strategy (automated deployments for dev = integration, release-* = UAT / staging, master = production). It even can give you long release branches should you need them. That's the thing with git flow - it pretty much gives you everything you describe in the list, but gives you a well defined framework in which to do it. As another example if your target is an embedded or specialist hardware system, you can't always automatically test every aspect of it, and testing everything in a test plan is resource intensive where you have a separate QA team testing it. So you don't want to do it too often (and as a developer you don't want to be pressing buttons on a hardware device either). If you're lucky enough to have a simulator for CI, even then it won't necessarily behave in the same way as the real thing so you ultimately still need manual testing anyway. I think git flow gives you everything most mature projects need and it's ubiquitous enough that must developers don't need it explained to them. In saying that, I usually would start trunk-based for new projects, then move to git flow once the project starts getting deployed because it *does* bring with it more overhead, but I've used it in several companies, none of which needed a release manager and none of which caught fire after I moved on.

Great video! Could you clarify how we can handle with hotfix using feature branch strategy? I’m not sure how to not interrupt the development flow of new features? (In this case there is only one development environment)

So eature branches with feature flags. For me it has everything as soon as feature flags are being used. As soon as project is non-production you can give right to merge pull requests without a review. It's quite close to trunk based development - gives you more speed via simplicity while avoiding any dedicated pipeline logic.

Thanks!

I laughed at Git flow segment like I was watching a standup show haha.

Great video

I use a single mainline where everything is merged. Any commit to it is deployed to staging environment, and any tag is deployed to production. Insanity level seems low even with this git flow. The only problem is when devs merge to the mainline but that change is not ready to be tagged at any moment. It doesn’t happen that often but then it’s better to keep the feature branch a bit longer until we know it could be deployed to prod right away or wait. I have to mention we do automatic deployment to staging when the PR is open too. This doesn’t use feature branches but instead it’s a new pod with slightly different service name. The infrastructure can route to that version at runtime by passing flags. It’s kind of a feature flag but for the microservice routing infrastructure rather than the code. This makes the deployment a bit more complex but it’s fully automated now. I would still like to try code feature flags to remove the issue I mentioned of the mainline not being ready for deployment as well as not having to deploy multiple pods for each PR. Then we would release to both staging and production on commits to the main trunk. But the default state of the feature flags would be on in staging and off in production. A tag In the main trunk would then happen when a feature flag is flipped to on in production. I haven’t really thought how that looks precisely but it sounds interesting

Hey Dev need Assistance , we have One big monolithic application , we work on Agile PI model like 3 month work panned advance and requirements break in to stories and plan multiple spring , for that PI , there are many thing we can only test in integration environment because of hardware software etc , for Sure trunk base or feature base development wont work for us and release base is too complex , was thinking to modify bit on fork base , So we have 2 branch main and integration close on each other thn dev create feature branch from main work on it after test code review merge to integration branch , after integration testing core team decide if thy want to release the feature or not , if they want they can push to master and it goes to prod

I disagree with the "you don't care what goes to production" in trunk-based development, because the feature toggles are exactly to avoid that. Other than that, great video!

How do you handle big feature projects without release branches? I started with a very continuous strategy with light feature branches, but the product owner is pushing for not releasing until the big feature is “perfect “

This is a great video! We used to follow gitflow, but now swited to release based braching. But the issue we only have 2 environment. As per gitflow, develop and prod. How can manage these in release based branching.

What do you recommend when using GitOps style IaC? It seems to be often recommended as a branch per environment, or sometimes using a tag per environment. Love to hear your thoughts.

What about the continuos delivery using feature branching or trunk based to dev, staging and production environments in an automated fashion. Think of GitOps and GitHub actions to k8s cluster. How would you do it? Git tags?

Ok. I've got something set up for my team that is a bit different than all of those. Our current release schedule is every two weeks, but that's primarily because what we inherited from the last team was a total mess. No testing. And deployment is: merge to master on the public repository -> merge to a feature on the private repository -> merge to an svn repository -> go to all the locations that have code and run svn up. All command-line. Inside containers hosted on a single-worker k8s cluster. Which has tons of code that isn't stored on git or svn. Container images? Surely you jest! So... yeah... that's what I had to start with. As soon as we get things sorted out, with automated building and testing, ramping up the speed of deployment should be easy. Anyway, if you're still reading, here is what I set up. There is a fair amount of redundancy, but three sprints in, it's pretty stable. Master branch. Off master, a dev and a qa/testing branch. Also hotfixes come off and merge to master. Dev branch. Feature and bug branches off these. All work must be broken down into bites that only take a few days to complete. Once ready, PR back onto dev for dev review. Once passed, PR same branch to qa/testing. Currently all testing is being done manually. But they are setting up the specs to automate things. Once the testers get notification of the PR, they run the needed tests, including making sure the ticket fixes what's requested. They approve and it gets merged onto qa/testing. Once the QA team is happy with the number of features/bugs added, they run final tests to make sure nothing added breaks anything else. Then a release branch is created. Release branch, once we get the new architecture completed, can be pushed to a "public" test-deployment for user acceptance. If all is good, merge to production and deploy. I know this may seem a bit convoluted. But I think it will allow for complete automation with needed checkpoints built in. Ideally, once the work branch finishes dev review, there is no more human interaction until the UA point. And then it's out to production. Thoughts?

if we go with one branch only, I don't think we can hot fix? because main branch will have some features which we would not want to ship to prod. and if we take a branch off of master branch it would contain the work. if we take hot fix from release branch then we will need to merge it back to master. NO? Could you please share thoughts on that

Git Flow is the symptom of when having a very good hammer then everything looks like a nail. I would also add to the list of unspeakable mad strategy git sub-modules as a way to police where developers push things.

hmmm. Were i work they want to do environment branching, but keep some branches in different repositories

Thanks for your video. I really like it but I have to say your opinion on the Git-Flow strategy was a big surprise to me, probably because I worked at the place using it and it was the least painful environment for me as developer (and I know we had release management but it did not sound in any way complex compared to for example Release Branching strategy). So, I have a question for you. I know your opinion on it already but it looks like you favor environments with fully implemented CI/CDel/CDev pipeline and I do, too. However, the reality is these dont get implemented just over the night. The things that need to be set in the motion are not as simple. There needs to be an agreement "we need to change", that needs to be approved by the higherups, there need to be team agreement to move that direction etc, etc. In lean environments, these can take weeks or months, in not-so-lean environments, these can take years or never come to materialize. What do you recommend as a strategy fitting a team where (a) there is no CI/CD in place, (b) there is slow release cycle, 1-3 deployments a year, (c) teams (as you described for "release-branching" collaborate only once one team is ready to merge into the trunk), (d) there is no need to maintain multiple versions of the same software, and (e) Our features are not small to fit into 1-2 day living branch only, but last usually months? Thank you and much appreciated. Really like your video, so many good points. Thumbs up!

what do you think about vs code extensions that notify you in real time when you are about to make a conflict in a line so you can discus it with a colleague?

The last 2 blank minutes are for meditation over the code-to-subversion? :D Cool video as always

The threat of migrating my code to subversion worked ;-)

I was gonna say best video but after reading some comments of Viktor, I am gonna say "good video" :)

We have the release branch model in preproduction while everybody deploy its own version and every body else wait till he goes to production before we can go on with ours for pre production. very annoying in a big team...

Great video. Which one to use? Depends on how mad you want to get ;-)

You're really cool, it's a pleasure to watch

what's the best choice for solo projects in ReactJs web developing