This assumes all my changes are always incremental. In practice I often tear down most of what I did after I've cemented the general idea. To introduce my initial ramblings to the team before I even know if it's the direction I want to go, sounds like a whole lot of work for nothing.

How do you do code review before a commit to the main branch if you are not branching and submitting merge requests ?

Im not even a programmer but, I'm loving this channel. Found it through Cyberpunk criticism. Very fascinating!

We changed our process after this video few months ago and that instantly solved lot of code conflicts problems that we were facing and allowed us to visualize the progress of the day. Thanks a lot for the content

The definition of continuous integration sounds like 10 developers coding live on the same computer but with different keyboards.

As someone who has experienced both sides, I can say that there's no perfect solution, it's basically a "pick your poison" situation.

I was about to write a comment on how this was clearly bullshit. I watched the video instead. By the end I got completely what you were saying, and it makes perfect sense. CI isn’t something you can dabble in, and this demonstrates the level of commitment required to do it right. But if the data says it’s the most efficient way of working, then it’s worth seriously considering. Thanks!

At what point do you perform code review if you commit to trunk every 15 minutes?

Branching is valuable. Many times I use a branch for experimentl changes/refactorings that I’m not yet sure should ever be merged-at least until they prove themselves. If it doesn’t work out, I just delete the branch. Other times I use a branch to make significant refactorings I don’t want to disturb the main code, which is still moving. Its not always possible to think of work as a stream of small incremental changes.

My preferred way of dealing with staying updated with feature branches is frequent rebasing, this also allows me to have a linear history instead of a git history looking like a weaved basket. Gerrit is a very interesting Git host, it automates a lot of fiddling with branches to the point development can go on for months without even thinking of creating a feature branch. Because in Gerrit you work with patchsets (internally they are just branches where only the head is used, so it acts like a single commit, with all its history still available) and just "replace" commits, and you can do this as long as you like, rebasing it, running CI against it, until you merge it back to the parent branch.

So if Bob is working on the same file as me, then I'm supposed to pull Bob's changes every hour, understand why he broke my feature then rearrange my feature and break Bob's feature the next hour? Sounds like no fun. Never had a problem with merge conflicts and much prefer to have complete ideas to compare and merge.

Best programming content on UKposts, can’t get this level of experience and amount of useful info anywhere else

Thank you for sharing this! When the video started I thought, "this is a terrible idea", but the methods you presented for safely dealing with partial features make a lot of sense. I think branches still seem to make sense for open source projects because of the distributed decision making process in the community. But inside a development team I can definitely see this being a lot smoother.

I just want to express my gratitude for your content. It’s really professional stuff. As a software developer myself, yours is one of the very few channels I can actually still learn from. Bravo!

If your feature requires changes to shared libraries and database schema, how would you handle potential breaking changes to other areas of the code if you don't isolate them by branching?

Very well spoken, constructive and informative. Thank you!

I feel like this would have been better received if it had been about branch lifespan/scope rather than “don’t branch” since branching is the typical means of code review. It seems to me branch/review/merge often is compatible with the CI definition and provides the same benefits you describe. Thanks for the video!

You are the programming mentor i was always looking for but never found. Well now you are here. Thank you for your videos.

I really enjoy your videos and content. While I don't feel I'm radically enlightened I see these as a great opportunity to share them with less experienced engineers, as the clarity of your arguments is amazing. Thanks

I have your books and all the Devops , Martin Fowler series. You ability to speak clearly and know all the pitfalls is A+. Steve McConnell is also someone I deeply respect. Maybe you can comment on his work in a video or have a joint discussion. Thx for all your hard work.

Create branches and rebase often. Happy life :)

Your videos are great and inspiring! Thank you!

Thanks David for all your explanations! Very helpful

Interesting topic. I believe that this is the way forward; however, one concern I have is related to code reviews. Im not worried about syntax relates issues; this can be automated using static code analysis. I'm mainly concerned about the architecture/implementation of the feature as a whole. When you make all your feature changes within a single branch, you will have a holistic view of that feature's design and implementation (something which can also be used as a reference). This is something which you will lose when committing directly to master. Just wondering how you have solved this problem. Maybe it's as simple as tagging the commits with a feature id, but review tooling just isn't ready for this scenario.

One of my favorite channels to watch, I enjoy the style of the videos :)

Love Dave's channel.

Wow! I'm happy to have found this channel. Great videos!

The premise is that my small daily commits doesn't break the app even it is not in production, so my colleagues can work on their tasks. But some tasks with a lot of refactorings take days to finish and it could make harder for others to work. Also you would get rid off pull requests that should be reviewed. But don't get me wrong I hate long term branches and dealing with conflicts so we try to minimize size of branch to minimum. Also feature flags are good approach we implement very often. What I prefer is to pull from development branch often so I keep up with current state.

I worked with both branches and incremental changes on master. They are both valid. If there are more than 15 devs in you team it will be very difficult not to spawn new branches.

Can't wait for all the supporters in here to get in the field and deal with the struggles this methodology lends itself to. Hopefully they won't become cultists over this and one day will be willing to give branching a chance.

Hi. Big fan Continous Delivery (the book) and Accelerate (the other book) here. I've been implementing build processes for more than 10 years for a big variety of projects and I'm a fanatic on software quality. I agree with all the branch by abstraction, feature toggles and dark launch. I have a fundamental disagreement with forcing to work with a single branch. Let me explain my point of view: I want to have the highest software quality. To do so, I automate all the possible quality checks in an automated quality gate, typically: - stupidity checks (duplicate DB migrations, leftover console.log etc ...) - all the necessary linters and static code analysis to spot code smells - unit tests with high code coverage metrics (for code with cyclomatic complexity) - architecture rule enforcement tests (using ArchUnit) - mutation testing - software dependency scanning for vulnerabilities - end-to-end testing for most of the features of the application - UI regression testing with screenshot comparison Well implemented, those checks take 40 minutes wall clock time on a web project after 10 men-years of development (using a standard Spring + Angular stack). I want to deploy to production at least multiple times a day. At any time, tip of the main branch should be production ready. No-one should ever hold his breath before a change getting deployed to production. I've been doing that successfully, with high throughput, over multiple years. How: using short lived branches that have the full quality gate running before being merged. The development cycle is the following: - pick a task to work on - start a branch - as soon as you have some change whose quality is high enough, push, make a self-code review, and get it merged (after pair-review if needed) as soon as the quality checks are ok. - You don't need the task to be complete to merge, you just need the quality to be right, to merge. - You'll typically make quite a few merge requests before completing the task Typical cycle (between branching and merging is less than half a day). If someone wants to keep a branch longer than that, no big deal, he merges the main branch into his development branch as often as necessary (I recommend at least once an hour). He'll have the burden of merging, as he is the one choosing to move away from the "short-lived branch" recommandation. His choice. The higher the threshold of the quality gate, the more frequent the checks are going to be red. If it's red on the main branch, we cannot deploy, so we test before merge. You understand that with such a test battery, considering pipeline 10% of the pushes leading to build failure means the main branch will be red more often than not. This means team blocked hunting for the change failiing the build. Testing on the branches allows as well to: - test the build process update before merging (new compiler chain, different code coverage tool, etc ...) - review app: review UI changes live before they get merged by deploying the branch to a short-lived live environment - code reviews for knowledge sharing (I've read your arguments for pair-programming rather than code review. I'm a big fan of pair-programming, but it's just not always possible, sometimes simply because the work schedule is not uniform among the team members). Conceptually, a developer is always branching. He's working on a local copy that IS kind of a branch. Let's just consider the short-lived branch the equivalent of his local copy. If one is force to push on trunk, he'd better run at least a significant part of the quality checks before pushing. Running well written unit tests for a big project can easily take 5 to 10 minutes (we have many thousand of unit tests). I should run that locally before each push ? Why doing it manually, when tools like Jenkins, Gitlab-CI and many others can do that for you ? Hardware is much cheaper that developers, auto-scalable build farms are just a click away. Short lived branch allow this process to be asynchronous, and let the developer do something more interesting than waiting for the build to be ok on his laptop before pushing. I've now moved on a project that advertise doing trunk-based development (based on your very arguments). Tools have no build-on-branch support (GOCD). Quality gate only contains unit tests and some end-to-end tests. There are just a few deployment to production a month because confidence on the quality is not high enough. There are more days where build gets red at least once than not. I have a strong feeling trunk-based development gets in the way of having a strong quality gate. You can't have both, and without the later, you cannot safely do continuous deployment for mission critical apps. I suggest the following motto: "Long live short-lived branches" (no copyright). I'd be glad to read your feelings about this.

You can always integrate your work by syncing/merging the trunk with your feature branch. By keeping your work current with what happens in the trunk you ensure that other features that are introduced work with your changes all the way until merged back into trunk.

This approach kinda assumes that no one makes mistakes. Imagine someone is committing every 15 minutes. After 2 hours someone realizes that there is a huge issue with the new code which affects everyone's ability to work on their own tasks. Writing tests won't always help. Things can slip through. Also writing tests that early is often times a waste of time because you don't even know what the final version will look like. Thanks for your video tho!

Great video, as always Dave. It's good to know that some of the strategies to avoid branching have to do with a great effort I've been putting into releasing a more intelligent and manageable Feature Flag platform. Thanks for sharing your thoughts.

This is much closer to what I was looking for....while youtube is flooded with basic to advanced GIT tutorials but nobody talks about professional implementation and use of CI/CD with lot of confusion on branching.

Your topics are very informative, these are hot topics and our teams discuss them in the retro. I personally, enjoy reading the different perspectives in the comments.

Nicely explained! Thanks

How do you implement code reviews if you commit every 15 minutes?!

Espectacular Dave! I loved this

Commiting unfinished work to production is kinda scary. I also feel that the “behavior hiding” can introduce unwanted bugs and will need more efforts of removing these hidden behaviors in case the requirement didn’t push through or the requirements have been changed totally in the course of development (dev will have to look for each and every commit just to remove these tiny pieces of hidden behaviors). Also, does this approach considers the need for QA to test the changes? Does this approach requires QA to test the production version whenever there is a new change?

I think , this is good for small teams that consist of experts and seniors , but when it comes to large projects with many people and the skills vary, then we need a strategy "called PR" to review juniors code as example. Thank for your video . I enjoy it

I'm a dev with 20 years professional experience. I disagree with this. Code should not land in master if it's not ready. It doesn't have to be perfect and bug free, but it shouldn't be horribly broken. Where do you keep this code while you are getting it ready. But I think there are some important rules for when working in branches: * Merge/rebase master into your branch often. * As soon as you have some parts of your code ready, get those commits merged in to master asap. A git rebase -i is useful to move the commits that are ready to earlier in the commit graph so that these can be merge without bringing in the commits that aren't ready yet. * Do pay attention to what the other devs are doing. If two devs are working on the same bit of code, then they should maybe merging each others branches.

Would you suggest something like the "Live Share" extension in VSCode? Where entire team can work on same code and you can see what everyone is doing in real-time.

or just merge from the main branch into feature branch every day or even after every other person merges into the main branch. It still keeps your code close to the truth and avoids stepping on other people's toes

I like the principle of continuous visibility of changes. However, regardless of feature branch vs CI, there are few people who will 1) actually look at the commit logs of changes pulled, or 2) see the changes made by others when working on their own ticket. The only thing that wakes people up is merge conflicts. Must say, among the merge conflicts I face using feature branching, very few are due to mismatches based on a fundamental approach; it is minor things like imports/formatting. I like feature branching because a reviewer can see things like architecture of a feature within a PR. I fear that CI will make people approve minor changes with less critical thinking about the big picture.

Do you have any videos that explain where QA processes such as regression and feature testing would fit within CI and CD?

I've worked with a bloke that had the opportunity to work with you back a decade ago. When I'm watching to your videos I can totally imagine he explaining his values, approaches and techniques. Don't mind the people that didn't get what you're trying to explain them. They will, certainly, learn this one way or another. As more videos comes, I'm sure you'll tone down a bit and reach to wider audience. We need this wisdom. Keep pushing mate. Awesome content.

I have a another question, what's youre opinion on using this technique in a mono repo with more than 50 dev working together ?

I try to minimize branching, especially long lived branches. I also think a good starting point is to have only few branches at any given point in time. To facilitate this; do pair programming or otherwise divide the work, to work in parallel.

Another benefit to CI compared to long-lived feature branches - if there is a merge conflict, it is with the code that the developer wrote *in the last 15 minutes!* This code is fresh in the developer's mind, and they will have an easier time fixing the conflicts rather if the conflicted code was written days or weeks ago.

Hey Dave! Love your channel! This is great for on-premise teams. If the teams are distributed all over the world with a single code base, not only that pair programming isn't an option, its that some PRs will have to wait a day to get merged due to time-zone difference. Any advice there?

Yes, this is definitely very interesting. I think that your release/deployment strategies could be integrated also with a more traditional use of VCS. Thank you for sharing.

Thanks for this awesome video. I hear what you are saying, my question is how should you handle code reviews in this case? If I understood correctly, the desired process here is to push to master as often as possible instead of hiding the changes in a branch, but it also means the code needs to be reviewd by someone else(teammate) every 10 or 15 minutes which in reality is very disturbing(in terms of context change for the reviewer) and blocking. What's your point of view on that?

Agreed that they should be very small integrations, integrating at least once a day, but committing and pushing to master allows junior developers to add flaws to master without code review. Merge commits from work branches to main allows associated work (first attempt, write tests, second attempt, add comments) to be grouped as part of a single commit. The commit graph is much more clear about when and why certain changes were made, and a rebase to remove problems can be MUCH simpler.

Wow, your video is amazing! I wish there was a way for me to give you a thousand likes for it. Keep up the fantastic work!

This was awesome!!

This is really great and makes things very understandable, thank you. This seems like an optimal strategy. But, isn't frequent merging to main going to generate a pile of merge/pull requests? Who typically reviews and approves these, and how do they manage this volume?

Thanks for the great videos, but there is a basic flaw with your logic here. That is that the feature branches are somehow completely broken apart from the main branch or trunk. There is nothing wrong with having a long lived feature branch as long as you keep merging the trunk back to it. Your graphic is not quite complete, it only shows the merge of a feature to the trunk. But there are many trunk to feature merges along the way while the feature is being built. This can be done fairly easily and this way your feature is always updated with latest code. The feature itself can be tested completely through CI and if tests pass then you are good to merge your feature to trunk. Adding feature flags, dark features, etc involve huge amounts of extra code/tests which are not necessary. Most of the time this will probably add performance issues and extra unneeded code. In some instances this could be impossible if the new feature demands a DB migration or something similar. Having feature branches or even long lived features branches doesn't mean you are not continuously integrating.

Great explanation! Using this CI approach how have you handled code reviews? Synchronous and in-person before pushing to master?

I see a lot of discussion that feature flags solve the parallel development issue, and I believe they do, to an extent, but they also increase the complexity of the code and make it more difficult to reason about. How does flag x impact flag y? Ahhh I hear you say, well that’s all handled in testing and ci. That’s true of feature branches as well. Branches increase process and development infrastructure complexity. Feature flags increase process and code complexity. Both require coordination and communication between team members. I’ve used feature flag extensively for rolling out experiments in the UI/UX space and they work well. They’re isolated and have a finite lifecycle (the length of the experiment). Cyclomatic complexity has long been shown to a have a major impact on system maintainability. Feature flags by their very nature increase cylomatic complexity. PS: Buying Daves book, reviewing considered opinions are always worth your time.

9:30 (DevOps Handbook) I am not used to this workflow but I can see it’s merit. In my experience, the biggest bottleneck with feature-branch workflows tends to be code reviews (not branch maintenance or testing feature branches). However, code reviews are also the most important step for ensuring code quality and readability. Google/Facebook do NOT bypass this. I think the benefits the DevOps report outlines might be true with trunk-based: - higher throughput - better stability - higher job satisfaction - lower burnout However I don’t think it’s particularly comforting knowing people can commit anything at anytime without any oversight. I’ve seen codebases use this sort of style with just a linter and the commit history was a really long mess (and the code was a mess too). Really was a nightmare having to work off of that. feature-branch workflow compartmentalizes work much better and has a controlled process for integrating. Trunk-based might get you to the end faster but throughput isn’t everything. For example, a project that’s “released” but is being maintained with occasional bug fixes or other minor changes would not benefit at all from continuous integration. I guess it could work on completely green-field projects but most jobs are working on existing money-making products. Just to re-iterate, even Google/Facebook who supposedly use this trunk-based workflow STILL have code reviews. Ultimately the biggest bottleneck is waiting on others.

What would happen after you have merged your small changes to master and part of your code is in product but not yet release. You get told the feature is no longer needed or you need to pause work indefinitely. How do you make sure your partly finished function doesn’t pollute the code base.

One problem that I see with this approach is inability to review / revisit code for any feature much after its iterative release. The feature branch clearly doesn’t have this problem. Any good advice on this ?

I would be concerned about a project that required merging several times a day because the code I was integrating into was being changed that frequently. I suspect the need to constantly integrate is s symptom of much bigger problems. I've not found a big issue with either approach but I also try to manage change chaos.

If you are not using pull requests or mobbing with everyone on the team then what is to stop unreviewed code is getting into the mainline in an uncontrolled way? I know XP is explicit in saying that (at least) pairing is necessary for this to work (partially). What if even pairing is not an option for whatever reason?

WTF. why this channel doesn't have 1 million subscribers yet?

I like the focus on true CI/CD workflow here as the ultimate goal. Personally I do like and currently use feature branches day to day. But we also try to keep our changes small and commits frequent so pull requests are small and they do go into prod on merge to main. Maybe this is a middle ground? If a team could ensure pair or group programming most of the time, then committing frequently to main would work nicely, but in reality that can't be maintained just because even the most committed pair programmer wants their own space sometimes. Anyway, my key takeaway from this is that implementing proper CI/CD is the key and how ever that is achieved then happy days! Nice video Dave I'll be sharing at work 👍

Hi. Sorry if this is late. How do you deal with projects that need to maintain multiple versions like in libraries that has a version 1 and version 2 but they also need to provide hotfixes and security maintenance to both?

This was a very fascinating and informative video! I learned a lot from it but I have a question. How do you handle speculative developments where you are trying out ideas to see how feasible they are and how compatible they are with the rest of the system without committing them to the central trunk? I don't see how to do this without a branch. This is because you don't want your speculative work to interfere in any way with the production system until you are satisfied with it because you may end up discarding it entirely if it proves to be a dead end.

First off I agree with a lot of what you are saying. Certain problems (on an otherwise amenable project) tend to require workshopping before release though, and I feel that in cases like that feature branches and a bit more integration work can be worth the headache in order to get things right. Also, maybe I just don't know how, but I can't figure out a great way to do mandatory code review in a "commit anything that is tested as often as possible" codebase without basically mandating pair programming. That wouldn't necessarily be the worst thing ever. I like pair programming, but I also enjoy programming alone, and I think they are both beneficial. In the projects I have worked on we tended to stay somewhere in the middle and the communication in the daily standups generally kept merge conflicts to a minimum, even when some branches lasted for a week or two.

in a perfect world "Continuous Integration" is possible, but our world is anything but perfect. :-)

Very insightful!

So, I still am pro-branching, but I minimise it to a semi-daily merges that guarantees the work is always very close to the truth. Having unfinished work in production doesn't seem to work for me, as it generates bugs more than good results for the devops process.

I think u making the assumption that there is one way of implementing CICD and that there is only one place where all feature branches converges which is PROD. I think with a good branching strategy (feature/(123) -> develop -> release/(1234) -> production ) with each branch or branch prefix mapping to a environment, life of that dev team would be much better. This allows for less conflict, two convergence points (merge) for all features (in develop and release) before prod and 3 test env (where 2 env: develop and release have the integrated changes) . Pretty sure there are other ways but a development team of atleast 15 members-without branching it would be a nightmare.

I've been professionally coding since 2008 and the best way to organize code I have seen was the one I thought was the worst. It was bank using IIS as the web server, and the site of the bank looked like a single site, it wasn't, it was hundreds of tiny little sites, each of them with its own repository, the manager assigning the tasks was the one controlling who was using each of the modules or tiny sites. And we needed to make a change, we had ownership of that module for as long as it took to make the change.

Since we switched to a model.broadly similar to this, we almost never have merge issues any more. We do not merge branches every 15 min, compared to merging once a day I do not see the added value. Developers usually do not work on the same piece of code on a single day, and having to synchronize your repo with the origin every 15 min seems like an overkill. But as said before, with a more manageable timetable, it's indeed a very good practice. But every video I see on the channel I can recognize myself in most if not all the advices given, good to see someone with some real experience take on youbute!

I really love this idea. But, we have developed an alternative way. Can I make a response video and than we talk about the trade offs?

I know nothing of programming, but this is just so relaxing to listen to and so interesting :)

I am guessing but one of the most challenging aspect of CD may be when APIs have to be changed? So in this case would there have to be a coding rule to allow API changes to happen without breaking everyone else's code? As you stated in another video, at the start of a project it's nearly impossible to have every aspect of the software worked out and so the initial assumption of the starting plan is that it is wrong (I 100% agree with this). So this would also mean that APIs could go into a malleable state during phases of code development leading to many small or one larger commit/push breaking other's code. Does CD talk about strategies for evolving code and hence also evolving APIs? Curious as I would like to kick off my next project using a (correct!) CI / CD plan and I am a bit worried about this bit. Plus I know other people in my team will bring this issue up as well. Thanks for the videos, they are all brilliant and very helpful. I have several books on TDD and other topics (the Martin books for example) and I am planning to pick up yours as well. There are several wrong opinions about CI/CD at work that I need to straighten out :) Cheers,

What about software which requires high amount of additional documentation (eg proof that code works according to software design, software architecture and software requirements - basically in V-model) What would you recommend? Or even: what about code review? Shall it be executed in trunk after merge, or within this 'small and minimized branches"?

This may work in a "code-only" feature, but in my world, many features require data changes in persistent storage like databases. I'd rather hold on to a feature branch for an extended period of time and (more than) daily pull in changes from main. This way I'm the one solving my own merge conflicts and push to main would be easy.

This channel deserves more subscriptions and more views in the videos

Dave, is there a systemic wave to do code reviews using this approach? Really well explained content thanks.

Is this assuming that before the pull request, people don't re-merge any new changes from the main branch into their feature branch?

Very thought-provoking. Thank you.

This is a big problem. Unsafe code ending up in production - waiting to get exploited. I think the demand for instant relief has gone to far.

a fascinating and reasoned argument.

Sounds too ideal to me. Never worked on a team that is even near to have what it takes to do true CI. Thanks for the vid.

Although I'm fairly convinced that the way we develop our application (News Site Backend) is fairly optimal for what we do and how we do it, I watched your video with an open mind and tried to see the benefits of it. However, I couldn't find a way to make this work in our environment and being beneficial to stability, increased efficiency during development and deploying realeases. There was always a tradeoff at some point. So my argument is that concepts which were developed maybe one or two decades ago are still valid concepts but with different constraining parametres. Your argument was that a code should be always in a deployable state - which of course is always given for any branch which is deployed on dev, stage, release or however you may call it. On the other hand it doesn't make sense to commit unfinished code with unfinished unit-tests to a dark release or feature switch - even in the dev-stage - when it is simply not finished because it will inevitably break things. Just for the sake of commiting code every 15mins (you don't open a bridge to the public if its only halfway built). So my argument is, that it is probably a good idea to work in that way but adjust the constraints to the environment they apply to. Maybe commit the code not every 15mins but only every 1-2days when a feature is in a state where it actually could be integrated without breaking things. Another parameter (might) be the actual size of the codebase in relation the changed lines in every commit and the number of devs working on it simultaneously. Either way...good content and nowadays it became equally important to actually know how to organize your code compared to know how to write it.

Ok so I'm 8 minutes in and it seems you're suggesting to minimize the size of the branches, not to be rid of them completely.

I'm just learning about CI/CD now - but is this compatible with projects that are in early development? For instance, I'm often making feature branches that are for large experimental changes/redesigns. If my teammates and I are constantly pushing to master, what happens when I find out later on that my experimentation was the wrong decision and needs to be reverted?

This approach works good with web-based projects, when you support only your environment and have a pretty straight-forward environments (testing->staging->prod). How can I avoid branching in application-based projects, where for example I can have beta and canary builds (like Chrome) for bleeding edge features, and I need for example to create a hotfix for a release version of the app?

I am curious how this helps/improves/makes worse QA efforts. While I can see it helps reduce the "merge conflict" issuses, are you suggesting that deploying each time a commit to the master branch should be put into QA environment for testing ? (assuming the code commit doesn't "Break" anything) also, assuming testing is being done on the code commit to ensure nothing is broken, how much testing is that ? Unit testing is such a small part of testing (only makes sure the snippet of code doesn't have errors and "passes" whatever tests have been created) Usually there is not integration testing done or more comprehensive testing (regression). So this makes me think that there is still a large effort (once the complete coding is finalized and "ready for Production") that regression/integration and such testing is performed - and if failures found then it is not released into production. Isn't part of CI/CD supposed to be the "code is in a releasable" state? So to me that means a full regression could be run (should be run) every time a commit happens to "ensure" that the code is "releasable". That takes a lot of time to deploy to QA environments and run tests. If you are committing every 15 min, there is NO way a regression testing could be completed in that time.

I think he is totally wrong. A branch is only a pointer to a commit, nothing more. Feature branches is a developing method for mainly creating a clean commit history. If you have conflicts in your team because too many developers are on the same code it's better to try to find a different WoW e.g. swarm on that task or don't work on the same code at the same time. So don't stop using feature branches it's the only thing that keeps the commit history clean which is really important thing for finding and understating how bugs were created

Fantastic explanation!

Thanks for the video , but how do you do code reviews if the code gets pushed to Dev or master branch directly ?

Having implemented ci and cd last century, I can tell you this is a gross oversimplification. Branches are necessary when the need to isolate changes justifies the overhead for having the branch. There are many reasons to branch ( yes, even by feature) and there are many reasons to not branch. The problem lies with knowing when to apply the method and when not to, and unfortunately many developers have such a low understanding of branchinh that they even conflate directories with branches. The factors involved with these decisions can involve everything from the sw architecture, the competance of tge team, the competance of the vc tools merge capabilities for tye files concerned, and yes, even the release management process. Over the decades I have seen so many people try to oversimplify this and have had to clean up the mess afterwards. At the very least your video should provide caveats like " if the merge tool for the code files is not reliably automatable for >95% of merges ( and yes there are tools that exceed this, and git ootb is not one of them) and your development is project based, not product based with product variants and/or your system is not a safety critical system and/or your dev teams are poorly trained on the effective use of branches etc etc etc. To give a real world example of the impact of branch avoidance, I jave seen an entire product line have to be redeveloped as each product variant was a copy pasted directory of the source code (12 product variants). Despite having the same people maintaining the codebases over a number of years, each copy of the code was so completely dissimilar that a core change across all of them worked out to be cheaper to redevelop the entire product line from scratch ( a $12m decision just taking into account the costs for re accreditation of the variants - let alone the cost of redevelopment and opportunity cost to the business.

How to combine every 15 min commit with code reviews? Pair programming is not a option.

Without a release branch, when do you test the feature? Prior or post merging to master ? What do you do when a whole feature needs to be rolled back in this model ?

Dave, thanks for the video. I'm learning about CI and I'm curious, how to prevent malicious code in a CI project?