 This up then, one second. All right, so welcome everyone. So my name is Carlos. I work for ThoughtWorks for quite a bit now. And all you need to know about me actually is that I'm a developer. I think that should be enough for this session. So let's get right onto it, right? So this title is like, it's a bit verbose, right? So why I'm even talking about this, like what does this mean? And why am I giving this session, right? So the reason is actually two-fold. So if you were at Martin's keynote yesterday morning, and Jess actually spoke about continuous delivery, and Martin kind of started to talk about some of the topics in here. So essentially like source control when merging practices. But anyway, we'll get to that, right? So the first reason for this talk is that continuous delivery, right? So that's essentially like people have figured out finally that it's better to actually deliver value sooner rather than later to your customer. And it can actually continuous deploy that value. So like any checking will go straight to production. But business requires changes inherently. So it's better for you to plan ahead for that, right? Which is not what the traditional approach to software development does, right? So then the second point is actually source control management, right? So you see images like this or this or even this, right? So you know that something is not right when you have to draw like stuff like this. Like it's too complicated, too complex, right? So in order to actually get to a continuous delivery or even like for continuous integration purposes, you can't afford to have these kind of structures, right? It's just too complex and then you can't really handle it. Okay, but this is like too abstract. So let's get, I decided to put like a little story in. So to actually make us feel part of something here together in this room. So think about an online store of whatever product. It doesn't really matter. So a couple of guys, like three, four developers, some QA, a BA, they start this project and they get it live like very soon, right? So just essentially they just sell it. They have a catalog of products, they sell something and that's it. They check out, pay the credit card, done, right? And then this is essentially, this is kind of, right? So like you commit and then you have releases off of that main line of that trunk. And it all works out fine, right? But of course that it's going well. So business starts to grow and have like more people involved. So then someone comes up with the idea of a shopping cart. So essentially you have it. You reorganize that team, you get more people in and they want to develop this feature that's essentially, sorry. You want to allow your customers to buy more stuff at once, right? So you get a lot of stuff to your cart and then there you go, you just check out once, right? But then this doesn't stop, right? And then someone else comes in and says, oh, I want the users to have profiles. Like they shouldn't have to put in the building address or the credit card numbers every time. They should have like a profile, they log in and they're all set to buy, right? And it keeps going, right? So someone else says like, they shouldn't even need a login on a website. They should be able to use like the Twitter or Facebook account to log in. So someone starts to work on that, but that gets dropped. Like it's too complex. They have like a lot of stuff going on already. So they drop that, which is perfectly fine. They don't lose all that work they've done. It's there. But then it's still, those guys, so they use a profile guys, the blue one, they like on the hallway they talked to some guys that work on the shopping cart project and they figure out, whoa, all you're doing is you should actually integrate, right? And then, but that's not, that just happened by accident, let's say, right? Which is not uncommon. And so they say, no, we're gonna start this and then we're gonna get your stuff and then we're gonna integrate and then we're gonna be all fine, right? But notice that that arrow is right in the beginning, right? So and then these guys, so they dedicate like a pair to work on that profile integration, but those guys don't stop working, right? The profile is still being developed. It was not done when these guys started. So you see how complex this gets, like it's quite easily, but then eventually time goes by and the guys call it done, right? The integration is done now. So yay, like they'll go like have drinks, but is it really done? Like can you deploy that production? Not really, right? So that depends on the user profile and the user profile is still that has a long way to go until we can actually deploy it. And still it is not really done, like not just because it cannot be deployed, but you actually have a lot of changes that happen on the shopping cart and the user profile and you have no idea what the changes were, right? Most likely they will be like, so you got your initial merge from the user profile. It was right at the beginning. So chances are they have to change the code structure or refactor a lot of stuff. So you have a lot of trouble merging this, right? So it's gonna be very painful in a lot of ways. It might take you, depending on the size of these changes, like I think like this, like merges take months, right? Because it's not just about merging. Like once you merge, you're okay. Like it's green, gets you saying like, it's all good, you're up to date, but nothing works. Like you run the tests, everything is broken. So I have a lot of regressions. So again, thing, right? And on top of that, of course, business starts with this idea of a loyalty program to build up upon the profile, the user profile. So they want to, I just have like benefits for like frequent buyers, et cetera. But so these guys, they learned something with the profile integration merge, right? They said, no, we're not gonna make the same mistakes with those guys, right? We know better, right? This is gonna be the perfect project. So what they do, they merge frequently, right? So, but they merge only from the user profile. It gives that where they're started from, right? Is that really gonna help? Oh yeah, you will, right? You'll make, you'll have less pain in the end. Like if you just decided to merge in the end, you might not have caught like big changes they made in between there. So yeah, it reduces the pain, right? But what have we deployed to production from here? Nothing really, right? You have some releases off of the trunk up there, but those are like bug fixes like small enhancements on the original product and you have nothing out the door. Yeah, so what's next? What do you do on this scenario, right? You have a lot of code that was written like valuable functionality, but you can't really deploy that because once you merge that to trunk, you can't really just merge your user profile because like that's the shopping cart integration that business wants, right? So it's not a lot of teams working on it, but it got very complex, right? So what do you do? So first let's simplify this graph here. So just with stuff that matters. So you see that there are four branches going on and they are not in production and there's like that big release ahead of us, right? So it's scary because you have no idea what's going on with those branches and you need to merge them and actually make them work together, right? Who would have thought that they actually need to work together? But there's a good side of it, that these guys, they merge their user profile changes into the loyalty program, so effectively you have only three branches, right? Whoa, that's much better, right? You're much better off. So, but it usually turns out like, of course it depends on a lot of different factors, right? I'm saying impossible is probably a strong word, but it's not too hard to see people just give up and like, no, no, we're just gonna get, we're not gonna try to merge this, we're just gonna get the ideas, talk to the guys that develop it and we're gonna do it again, right? Because it gets so complex and like each team, if they're working in an isolated fashion, they can easily just change the structure around because they're thinking, they're the kings of that branch, right? But then eventually everybody needs to merge and they might actually have refactored different parts, like the same part of the system in different ways and then how do you actually manage that, right? What do you do? Like besides crying, probably, right? So the feeling is actually something like this, right? You know what you should do, like merge, but you're not allowed to do it because you can't, right? You get like saying that you can't merge it, right? But then you were stubborn, right? So you go on, right? And then eventually you actually like merge, you end up merging everything and nothing works, so you start fixing everything, changing the tests, like months go by and then you eventually, you get through it, right? Also it's working, right? Someone says now it's working, we're gonna go to production, right? So again party, like big lunch, booze, however, there's one thing, right? Like someone figured out that there's like legislation that prohibits us from deploying that loyalty program, right? And now, okay, what do we do now? Like it's merged, no, no, no, it's the release is done, right? You keep saying the same thing, like you probably, the reaction will probably be like the business guys, no, we can't go live with the loyalty program and the developers say, no, no, no, we are going to production, like it's scheduled, it's tomorrow, and I say no, no, you can't, right? Okay, let's just go with the shopping cart and now the rest, so no, we can't because it's all together, right? And then that, again, that triggers a lot of reactions, right? So that business people like yelling at you, everybody, you get like, you go home, you cry or whatever you do and then there's this, like you had this feeling, right? So everything was okay, right? You were sure, right? But it was like this, oh, right? Shit, right? So that's essentially what happens in that scenario, like, no, we got all covered, right? Well, not so much, so you really want to avoid situations like this, I would say, right? I would, at least. Oh, wait, so we talked about a lot of the problems and that's, I have a deeper look just to understand better what was going on, like I know it was like a big example, but I wanted to get a message across, right? So the first one was that business couldn't really meddle into the software, right? So software was dictating business decisions, right? So that's like just wrong, it should be the order you're on, right? So software is there to actually make business run or like have something, you can have something delivered before your competitor does, right? So that's all about it, right? You can be like two years developing a solution, but then it gets like six months in, you discover that this guy just released something new, right? That does exactly the same thing. So what do you do? You can't just stick to that plan, right? Oh, in two years we're gonna release it, it's gonna be much better, right? You just need to change really fast, right? And Martin touched that on that as well yesterday morning on his keynote. So it's essentially that perception that you can just plan ahead and then like give someone to develop and actually release it. It's just wrong, it doesn't happen like that, right? So that was like the first problem that we see. And the other one, like this is a more technical one, is the merge hell, right? So those merges were not an easy thing to handle, right? But why was that? There was like, I don't know how many people working, it doesn't matter, like 14, 45 teams working separately for I don't know how many months or years. And nobody talked, right? Oh, maybe actually these guys talked on the hallway and then decided to merge that. But that was it, right? There was no formal, that was not frequent, right? So you had this painful merge and you had this even more painful merge. But then you can ask, why is merge, like what is the problem with merging, right? I mentioned it's not merging itself but it's like the side effects. What happens after you merge, right? Depending on the type of changes you have, like this change, like any source control tool will handle this for you, right? You don't even like SVN or Git, they'll handle like three way merges easily and then you don't have to worry. That's fine, right? But then what if you have something like this? Like you have changes that are completely the opposite, right? So one guy is adding 14 and the other one is subtracting seven, right? What do you do? And then remember that was like, I don't know, a year after that change actually happened, right? So do you like, you get up when you try to find a guy around, the guy quit, the guy's another country, he's dead, I don't know. So what you can't really do, like you need to actually investigate. So this takes a lot of time, right? You have no idea. I'm talking about like semantic changes, not even just like refactoring, right? So sometimes you have like a lot of, you have no idea what the guy had in mind when he was doing that refactoring and you can't talk to him. So you might just do it the wrong way, but it's gonna break someplace else. So it never stops, right? It's like a lot of small issues that will pile up and it never ends. And there are like sneaky conflicts as well, right? So if you have like you add a new file, there's no conflict in this, but it's gonna break, right? So including a file that doesn't exist anymore, essentially. So like if you don't have proper test coverage in that, boom, it breaks. And so far, so I think the idea here is not about merging code specifically, but that the fact that you're merging a lot of code will lead to regressions inevitably, right? However, like I said before, the lawyers team, they learned something from their peeps, right? So they merge frequently. But what good was that? Maybe they had like a little less pain when they had to merge, but they were just merging from this guy here onto then, and they're like forgetting that there was a whole lot of other stuff going on out of this universe here, right? But they had like a good intention, right? Because they figured out that this is true, like they figured this out, right? So like the longer you go without merging, the harder it gets, because like you have more differences, right? So if you don't stop and look, all this guy, all this is big refactoring here, like, if you know like the date the guy starts to refactor it, it's much easier to actually adapt or just sync up than to actually like after six months, and you say, oh, they changed everything, right? They're not using Java anymore, right? They moved to Ruby, right? You can't really afford that. But then again, this practice here, like I said, just to give it a name, like it's the merge monkey, right? Merge man. So it's probably the shittiest job one can ever have. So what usually happens like this is probably not the same guy that was merging all the time. So like that's usually a rotating role like you do like every couple of days or every week, like every Monday, it's merge day, right? So have a task on the border, someone has to do it, right? But you don't make the same person do it again because it's like, it's too hard. Hello? Anyway, so then the merge working kind of helps you in that sense, like if you were doing this, like on the original one against everything, it's like, I don't know, four, five merges in a single day and you have like all different sorts of things going on. Even if you succeed at that, it doesn't really help you because there's like a lot of stuff going on outside your world that like you can get this curve a little bit down, but over time, they're still gonna pile up, right? So then the difference are still gonna increase. So essentially that's just mitigation, but it like you were attacking the wrong front, like you shouldn't be focused like on that approach. So yeah, and the other thing is how do you even like continuous integration, right? How would you structure like pipelines and anyone has any idea what to do here? Like if you want to have like tests running against all of these, right? You would need that, I don't know, at least like five or six different pipelines isolated, right? So like how do you actually manage that and what good would that even be, right? So let's say you need like five or six pipelines. Yeah, like one for trunk, one and then for each of those colors, but then how effective would they even be? Cause like they're isolated, right? So they like shopping cart, maybe it works perfectly, but the moment that you merge that the trunk, it's gonna stop working, right? Nothing's gonna work. So like that's like a false sense of security that you have by having, so now I just have 100% coverage. It's all good, right? But the moment that you merge that, it just like even the tests are gonna break because tests have been refactored. So essentially like you work in an isolated way and then you still have that integration phase, right? That everybody has heard of. So essentially when you have like before that release, you will merge these three branches into the four branches like including trunk. Okay, you merge successful. So you have the whole integration phase to see if everything works, right? I'm not even mentioning like external services or anything like that, but you'll get the picture, right? It's too much to handle where it should actually be focusing on, I don't know, a new functionality. And I just wanted to mention also the formal term like Martin has on his Blicky promiscuous integration. That was essentially what these guys were doing, right? So if you look at the Blicky, there's like some more comparisons against other patterns, but in a nutshell, that is like promiscuous is not a good objective in this sense, right? Because you should actually, everybody should be committing, we'll go into that in a bit. And there's one more thing actually, refactoring. I mentioned a lot of times, refactoring people refactoring different parts, different branches, but what tends to happen in scenarios like this is that people are just saying, no, no, whoa, don't touch that. This is common code, right? Dude, stop, right? Someone might actually stop you from refactoring or making the code cleaner because they know I'm the guy that's gonna merge next week, right? So you're not touching this code, like wait until Tuesday, then you can touch it, right? So that's very common to happen. So you can't afford that, right? Like you have people willing to actually make the code better, but you stop then because of the process issue, right? So that's just wrong, right? And not to mention the undeployable, the whole pile of undeployable code you have. So like in any given point in time here, we could just deploy trunk. They in fact was being deployed from trunk, like people were working on the mainline and deploying from there, but nothing else was deployable, right? So it's just like strong. And like you can usually get people to understand you if you talk about money, right? It's much easier to get the people's attention and say now we're spending money here, right? Oh, wait, how, right? And just mention like all the time that I don't know how many months went by here, but like people's salaries, you pay people's salaries and then your customers are not seeing anything. And they're still using like the old website with no shopping cart, with no login, with no loyalty program. And they might not even see that, right? So it's essentially a money problem, like time is money and then if you approach it the money way, people might actually listen to you. All right, so that's a lot of problems, right? So what do we do? Like it's just, I've said a lot of times, it's wrong, it just, it doesn't feel right. You're spending a lot of time on the wrong fronts. So I like this quote by Dan Bothert, where it essentially says that feature branching, like using your source control to, to, sorry, to handle different aspects of your application. You're just like, it's like cheating, right? You should, it's your responsibility. They care of it like your application requires different behaviors to be plugged in and out. You need to do that yourself, like it's your responsibility to do that. But again, responsibility is overrated anyway. So maybe you just don't want to listen to him, right? But I got a couple more, like Jess and Dave Farley. They'll have like, it's a trap essentially, right? So this is, we just branch off and then they don't emerge, it's all good, right? But then all those problems that we talked about will eventually come up, right? And then Stacy Crow is more like straight to the point. I just said, don't do that. Use an abstraction instead, right? So this is like very neat. And it kind of tells you like some possible solution, like you see the word abstraction being used here or like, like on this, on the other, I Dan Bothert called, he would say, like ability to easily swap in and out features. So you kind of get an idea of like what a better way of doing it would be, right? So like I said, it's your application's responsibility to actually abstract features of functionalities and be able to handle them. So you take that responsibility on to, we take that responsibility on to us like as developers arise the development team, right? And then you move towards something that's much simpler like trunk-based development. There are like different terms for this but trunk-based development is like very clear, like you base your development off of trunk, like you see here. So this is like pretty much the same as the first graph that I showed you early on. But then you don't know what like features are being committed, like those commits, why are those commits, right? They're being released. So how do you handle like different like shopping carts? Like let's say different features like shopping cart or loyalty program. Like if I check in, like I start working on it and the first thing I'm gonna do about the shopping cart is add that icon, right? Click on the shopping cart and nothing happens, right? If I commit that and gets released, what's the value? I need to be able to like work on that and then wait until like a substantial amount of working code to actually make users use that. And the answer to that is actually very simple. This is like simplistic answer but we'll expand on that, right? And if statement, right? That's the simplest possible thing that will allow you to not have all that pain and then work on a single trunk, right? So everybody will commit to that. All your CI pipelines are gonna run off of that and you can run like different sets of tests. So for example, shopping cart, right? I want my shopping cart, I want to assure that shopping cart works but I also want to ensure that when the shopping cart is off, the existing website doesn't break. So but you will do that all of the same code base, right? So we just swap these zip statements, right? So there are many ways of implementing this but I can be a text file, it can be very simple. It's the simplest thing ever, like you just have like a hash of values and then I should shopping cart is on, you should see the link. If it's not, I shouldn't, right? And then they lay out nothing else should break. But this is like I said, it's very simplistic, right? But there's a name for it, like we expanded on it a bit but like people call it like feature toggles, feature flags, feature bits, like several different names to handle it. But like I said, at the end of the day, it's just like an if statement, right? Turn it on or off. But if statements are ugly, right? You can't really afford to have like if statements all over your application and like it's gonna clutter your unit tests and all your types of tests but then like anything else, you just like, you get a better design for it. So one thing that for example that you can do is like have an abstraction layer in between something, right? It can be like a shopping cart purchase or a regular purchase and a shopping cart purchase. And then all your client code is gonna go into like this single layer and then they probably like, like you can use like composition inheritance, it doesn't really matter. But the thing is like you have one central point and that guy is gonna decide what to actually route you to. And if for example like front end code, if you just like remove, if you have a link for I don't know a newsletter, like you work in the newsletter, if you just remove that link, people won't even know, right? So if the users of your website, they are not gonna like meddle around and like try different URLs, you don't even have to worry, like you just take the link out. So that's like a single if statement or a single place that you have to change and then you can keep developing that, right? And there are a bunch of approaches like, so if you look at this abstraction layer here, you can do it like a big bang approach. So like the shopping cart is a good example. You have your shopping cart being developed, but it doesn't really work until you have like a set of features. So you wanna wait a bit until like two months in when you have enough stories done to actually toggle it on. But for other things, you can do it like in small pieces, right, also this page is already done. Like I'm just like refreshing the layout or something. And then I don't mind having two different styles. You just like do it right away. Like you always, you can leave it around like if you're working on or if you just deployed it, you can leave it like the two states. Like in case something goes wrong, you just revert it back. But then again, you are in control. Like you're not depending. So I think the message is that you are not, you are doing that yourself and you know what you're getting yourself into. You're not relying like on SVN or Git to actually do that for you. I actually had a case on a project that SVN actually broke. So we had like four branches. We had to merge a lot together and SVN would just crash. So there's a bug open on SVN from our team there because they would just have to download the source code, like add some logging around, recompile it to see what the issue was and then we send the patch, right. So if you actually get the point that you break your, like SVN, you're not doing it right. But anyway. And again, you can like refractory becomes much easier. Like I said, you won't have that guys and now I'm gonna merge next week. So don't do anything. It just flows. It's like on trunk. Everybody is on the same page and then you can just do whatever you want and then people will know right away. Like as people are pulling or if you check something in that's actually gonna break, you see like the, your build is gonna become red because it's a single build. Like it's not working in an isolated way. But then it comes with the price, let's say, right. So there's some rules that you need to actually, you need to follow because it like if you were, especially if you were used working on like isolated branches, you need to be careful not to break other people's or not to stop other people from working. Essentially, I think that's the most important thing. So like some teams will have like actually a hook. If you break the build, you revert that change set right away. Like so you're never blocking anyone else because you can get very nasty. Like if you have different team, like let's say you have a team in the US, like in China and in India, working in different time zones and then the guys that commits something, build becomes red and he goes home, right. So like you have, there's a whole day of the other guys working and the build's broken and you have no idea. Like usually we just revert that and keep working and it's the other guy, right. But then you need to like, it's a different approach, right. So there's some rules like, so the first one that I would say that kind of goes, it's like the most important one and then put the other ones together. It's like continuous integration, right. So if you have one single pipeline running, like running from trunk from a single place, like everybody is on the same page at any given point in time. So like if that guy checks in and goes home, like you tell them, give him hard time about that. So the next time he doesn't do that or implement something they revert automatically, right. But this is what holds everything together with like, if you don't have automated tests or like a single build, you can't really afford to like have everyone work on the same place because they might just, might as well just create different folders for their things and like have different builds like doing trunk based development, right. But then if you look at a trunk, it's like siloed, right. So instead of having the branches, they have different folders inside. So it's important that you run like it's one big project going on. And of course, keeping the build green. Like I said, you can't really block other people. And they're not just being green, but always releasable. So this is kind of a stretch for some corporations. Like they have like traditionally, they have like long cycles, a lot of long release cycles. Like you start preparing for a release six months in advance. So this might be a stretch. But anyway, if your trunk is green, if the build is green, you should be able to just to call it releasable or like releasable to an integration environment. Let's say, right. But it's still, it's releasable. Like your tests are passing, like your builds passing, your tests, all tests are passing integration tests. And then you can actually deploy to a UAT environment and people can look at it. Or even you can just say, oh, this build is green. Just push the button. It's gonna go to production, right? If you're doing continuous delivery kind of thing. And again, like test coverage, it's like very important. Otherwise you can't really, we'll talk about branching patterns now. So I'm gonna go back on testing, testing coverage and testing patterns. I actually do that right now here. So one pattern that you might have, especially for, this is especially important, I think for big corporations, like I mentioned, if you have like a long release cycle, you need to stabilize, you need to have a lot of different themes. So like, you send an email, say, I'll have a release. Something to be released, right? And then from that point on, it takes, I don't know, six months to actually release it. That's like a lot of corporations who have that timeframe that you have to wait until you can release it. But that shouldn't stop you because like those six months, people are gonna be meddling around and like, you know, this is wrong, or they're testing it. Oh, don't touch anything. I don't want you to break anything. Just to stop doing work, right? So you can't afford to do that because everybody's working off of the same place, right? So the pattern here is you have like release branches, like numbered, release branches or whatever. So you have like 1.0, this is the release. So the moment that you have like, no, I'm gonna, I wanna go live with this feature set. You cut the branch and then you don't stop anyone else from working, right? So you will duplicate the suite of tests that you had at that point in time and then everybody else can keep going. You can even have another one, another release cut. And then this will allow, like let's say this takes six months, like that branch is gonna be there and you don't have to worry. Like if you find one or two bugs, you usually fix them like you try to reproduce them on the, on trunk and then later on merge them back because people tend to forget like I put it there. They should avoid fixing on the branch and putting it back because what usually happens, you fix something like take one day to fix and then you like go like, perhaps to have lunch or have beers and you never remember to actually merge it back, right? So but if you do it on trunk first, like right test to reproduce that, oh yeah, it's a bug. So you fix that and then you try to pick into your branch, right? So this allows for like this traditional approaches to actually work with trunk-based development. Otherwise everybody would just have to like go home and sit until the release is done, right? And another pattern, like, because branches, like it was written here before, like branches are not evil, right? Just people who use them for evil purposes, let's say. So this is a pattern, I think GitHub uses it, like a lot of different corporations will use. You have a trunk and then you have production, a production branch and like any time you merge anything into production, that is actually deployed to production, right? There's a hook that like right away deploys to your other production service or you can do like pull requests. I think GitHub actually does pull requests. You just send a pull request to production and if you want to have like someone review it or like a change board, check it or you fill some form out, you can do that. Like you just like one step. If you can't really like go out the way into production, once you check in, this is a nicer way. Like you just have one different branch and then you'll stop anyone from working. And then on top of this, you can actually have like an intermediate one that can be used for different purposes. Like some people do this like for QA. I don't like that very much, but there's a different topic, right, about how QA should work on a team. But I call it dog food. So the biggest example I think would be Facebook. So Facebook, they're known for having this internal Facebook version. So they're employees, the Facebook employees who use this version of Facebook before anyone else sees those features. So it's a way of like actually getting feedback, like if they're bugs, they can handle it internally. But like very few companies could do that. Like if I write a, I don't know, a system that sells car insurance, like if I, even if I let my employees use it, like I will use it once a year, right? So you can't really afford to do this, like especially the dog food approach. But again, it's still nice, right? Cause you don't have different, like it's everybody will be, it's just, it just changes over time, but then you merge only one thing. You don't have like those, like three, four way merges going on. And I want to just show you guys quickly, like this is like the link for the original article down there. I'm gonna make these slides available. This is like Paul Hammond just created. This is a, I think it's a very nice resource if you want to look like a different branching models, how they play together, especially like with the QA row. Like I mentioned, some people will have the QA branch that will merge stuff into, and then the QAs will merge into production and how to handle like toggles or rowbacks. So you see like the number of releases a day or a month against like versus all the other aspects of it. So I think this is a very nice thing, especially to get the conversation started. But yeah, this is gonna be available there. And I think to sum it up, I just want to leave this quote again, because I think this, if I could give this talk, if you just read this, you kind of get an idea what this talk was about. So again, branches are not evo, but don't use them for evo purposes. Thanks everyone. With the main and once the feature is complete, it's pulled into, it's like it's hidden rather than hidden in the main. It's in a separate branch, it's all the test and everything is passing and then it goes into that. Is there something wrong with that as well? So imagine this is like better because you have like main being, but what if you have two or like 10 branches, right? What takes man, but you don't take each branch between themselves, right? So in case of say main branch, the feature lies and it is a stand in two parts. So after first part, you open it up in the main itself. Likewise, this gives you a different back into the main function. So I think this point here is like, it's still much better than just being isolated. Like some tools will actually do that automatically. For example, branches, they'll merge, they'll re-base everything together and run that like several, if you have like three branches, they will run three different builds, merging main into those. But then again, like I said, if you have like say three different teams working on it, and then you're getting main. So like your feedback, if everyone is committing to main at the same time, you'll get much faster feedback than just getting main because maybe like feature number one, let's say, right, that finishes and then you merge that into main. But then those like feature two started at the same time as feature one and then they'll just get to know that those changes are actually there when feature one ends and then you merge that into main, right? You see the difference? It's just like, you know that the features work in isolation, but you're not sure that they work together, right? What do you think after which feature branch comes back? What a feature branch does have a life of six hours, two days? Is there, do you draw a line somewhere where this you think that now they're becoming evil? I would see it. So some people will say, and I agree with that, like your local copy is a feature branch, essentially, right? All the time, like if you're working on a given day, so it's hard to say like draw a specific line because there are different constraints. Like if you're on a plane for 14 hours, there's nothing you can do, like you're working on your feature branch for those 14 hours, right? But that's acceptable, right? So I think this is, it's not about the time, it's just the concept, right? If you are gonna merge it back, some people are actually gonna like local copy, right? So they would check out master and then they'll create a branch to work off, but that's like everything is local. So they are not impacting anyone. So I think that's usually okay. I would say like if I had to say a number, I would say one day, like you should integrate at least a day, but then we go back to like continuous integration and other different topics. But I think if you do it frequently, you just catch issues much sooner. Like for example, if I start working on a given feature in the morning, and then the other pair next to me starts refactoring, that's very feature, like if none of us are actually checking in, it might take like one or two days until someone checks in and someone pulls to see that, right? And we like, if you catch that and like in the first minute, you're just like, you're gonna talk among yourselves and say, no, maybe we should just wait, right? Cause we can't really start working on this because you guys are refactoring, right? So I think it's all about communication and like getting like input faster.