Branching Strategies Explained

You know, it's funny how you dislike the two branching strategies that are probably the best for extremely serious production deployments.

hhhhhhhhhhhhhhhhhh.
You are amazing.

Hahaha Gitflow = job security

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

you make the topic interesting, thank you.

you're not very good at explaining git flow, too much of your own thought on this flow, and is wrong.

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.

Best video on guy I’ve ever watched

great explanation!

To be honest I don't see any difference between GitFlow and Feature Branch. They're actually the same except Feature Branch has no mechanism for Release management. In GitFlow the release branch is never merged with any branch except to master/main not to dev. You cannot merge anything into release either they are like disposable branches which can either be successful or failed.

Unexpectedly funny!

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.

Somebody explain to me why Gitflow is not a good idea? I have been in many companies and experienced my self that many of the Gitflow's ideas has its own usecases and resolve so many problems.

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

You forget the backup aspect of the central repo. When you only push to the main line and do not create branches, then you do not have that backup component and at some point some work will get lost if you do not push your work to the central server. Often people want to push to a server before they leave the office or it is an requirement of the company.

Thanks!

Excellent presentation. Immediately subbed. Thank you from Ireland.

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

You don't know gitflow apparently, because it is not what you described.

Warm suggestion, move away from using images of real people for expressing madness there is no right answer there that will not get you blow back based on race and gender.

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 an easy and interesting explanation!👍

Oh and Job Security hahaha ….People Factors are the worst in tech industries…..a bunch of car sales (used car sales) that work in the tech space…unfortunately

I completely agree with the Test Coverage of >95% should graduate their Strategy to Trunk Based…..otherwise, I can say lots of Engineering Manager or LEAD, pretty much hiding behind Waterfall with few merging every other day….I’ve seen lots of self-proclaimed DevOps engineers for big enterprise proudly thinking they are a DevOps engineer….true and true…. 😂

You deserve a million thumbs up!

I don't get why release branching is preferable to git flow? If you add hotfixes to a previous release you'll want them in your develop branch anyway, so you'll not have to fix the same issues over and over. That means you have to merge it to release and develop in some shape or form anyway?

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!

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.

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

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

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

Do you have videos explaining the workflows of feature-branches and release-branches little bit more in depth?

Are feature-branches same as GitHub-flow? Thanks

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!

So your madness levels only take into account the developer perspective. Typically the madness level will be inversely proportional for the Quality organization for these branching strategy. For example, you rated trunk based development with a madness level of low. For QA, the madness level would be high because the difficulty of ensuring that a bad change does not go out the door is much more difficult.

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.

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

? git flow is easy. you can focus pn the actual implementstion. branching, merging and PR are easy.

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

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.

Appreciate this breakdown, thanks!

This was a good explanation and illustrated even. Thank you for helping. <3
Now with this knowledge to find a solution for my own workflow.

Nice presentation! Thank you!

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.

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

You are promoting not to actually create branches per environment. What is your suggestion on how to replace them? Becase we have now situation where we have 3 environments, multiple features. Each feature can be deployed out of order based on client's demand.

Not all of it are correct and also not all of it are wrong, but thanks for making this.

This is a great summation of branching strategies, I give him that. But he grossly characterizes the real value behind mature branching strategies like git flow, which are the only kinds of sane ways of deploying complex, mission critical systems to a large user base where one mistake can shut down an entire streaming service, or take down the entire east coast of a cloud provider.

These silly "strategies" of directly committing to main/master/trunk or these juvenile short "loop-back" feature branches onto the same main line branch are not "strategies" at all. They are both hugely risky, and are a sign of either a single-person operation, or a very tiny dedicated team of developers with deep knowledge and "ownership" of the whole of the code base (or SME's in their specific sub-domains) who can get away with it, especially if the releases are infrequent and only minor patching is involved.

Otherwise, any large, mature company with sufficiently complex software releases cannot operate in a sane manner without "safe areas" in which Devs and QA folks can deploy to internal environments and thoroughly test changes before pushing them out the main/master "flume ride" direct to users. Anything else would be chaos and insanity. That's why mature shops use git flow and similar methodologies. It actually very orderly and sane for shops that use it. Unfortunately this guys completely mischaracterizes how companies use it and makes it sound like its madness or "difficult to merge". In actuality, for many large shops, the structure and regularity of of using a git flow approach makes this simple and easy with minimal surprises and a drumbeat of regularity. Such mature shop demands a feature/dev/release/main/hotfix type of separation of workflows just to keep things sane. Of course most of this is automated and in well-run shops with good communication, merge conflicts are actually very rare.

Bottom line is: You can either work out your issues in-house, before you push problems out to the world (and resolve any potential merge conflicts if that is what is needed), or you can rapid-fire commit changes close to your main line release branch and let the world find your issues, which then you have to fix in-house (which is what you should have done in the first place by giving it enough 'bake time' and human eyeballs to actually view and test it manually). It's your choice. And it's your reputation.

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?