Coding Blocks - Comparing Git Workflows

Episode Date: September 24, 2018

We have some fun with our names, get ahead of ourselves during Survey Says, and vet Michael's tip on-air as we take a deep dive into comparing some popular Git workflows and when should we use which.

You're listening to Coding Blocks, episode 90. Subscribe to us and leave us a review on iTunes to learn more using your favorite podcast app. And check us out at CodingBlocks.net where you can find show notes, example discussion, and a lot of other stuff. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Zach. And I'm Michael Outlaw.

I'm Matt. I'm Outlaw. We're having too much fun with the names here. Well, okay, if he's Jerzak, what would you be? Alan Earp. No, I thought about thiszak, what would you be? Alan Earp? No, I thought about this. I think he would be Alun. Alun.

Alun. Does that make me sad or happy? If he's Jerzak, what does Alun make me? Drunk? Fair enough. Alun here. All right. As we do every time, the first thing we like to start off with are the

reviews and want to give a big thanks to those in itunes that's paul ketley rick foil and cole cole all right big thanks to uh stitcher as well um thank you president dumasi and Gilderm. I wonder how that was supposed to be pronounced, the President Dumazy. Yeah, I thought I did pretty good. I think we're all trying to skirt around how they might really want that one to be pronounced. Ah, yes. Light bulbs just went off. Ah, yes. Light bulbs just went off. Yes, got it. Well, if you head to the show notes, you'll be

able to see how it's spelled and maybe you can illuminate me. We don't ever put these in the show notes. What? Do we? Do we? Yeah. Okay, I've never seen them. Mad respect, yo. Mad respect. Man, alright then. How else are we going to thank people? That's a good point. Alright, speaking of mad respect, today we're talking about Git workflows.

And we're going to talk about a couple different types and a couple different things. But first, we want to talk a little bit about why we're talking about workflows. And a big part of that, because of the reason people even talk about Git workflows overall, why they didn't talk so much about subversion workflows or like visual source safe workflows is that Git is a toolkit, and we don't talk about visual source safe. There was no workflow. Locked file, nobody else touched file, unlocked file. No, that's not fair.

Unless you needed to touch it. It did have – there was a – like I would say there was a, quote, workflow about it. But it was like a library system. You check the book out, you have the book. No one else gets that book until you bring it back. Lock file, unlock file. Right. Anyway, sorry.

Yes. That was its workflow. Yeah, but everybody ignores those locks though. You could change stuff and you just email the person and be like, yo, you still got this thing locked. I edited it anyway. So you got to deal with it now. Boy, there was that. That is truth.

All right. Go ahead. Sorry. Yeah, pain in the butt. Oh, yeah. So the reason that we talk so much about Git workflows and why we've been using Git for so long and probably a big part of the reason for its longevity

is that Git is a toolkit. It was designed as a set of programs that you can chain together to kind of manage your code. And it's not so opinionated but a lot of people have had opinions about it and i've got a little list here of kind of controversial topics that you may have heard of if you are deep in the get scene things like branching strategies tagging strategies rebase first merges how you handle like dependencies whether it's like sub trees or sub modules or commit hooks or kind of controversial pull requests, forking versus cloning.

That's just like a little list off the top of my head that people have really strong opinions on. And depending on where you work or what experience you – or bad experiences you may have had, you may avoid some of those like the plague and favor others. So I took a little look at the source code actually because I read this thing was like a set of programs that got me wondering like is is get add a totally separate program from like get commit. And so I went and I found the, uh, the GitHub, uh, mirror of the code. Uh, it does look like they've got kind of interesting setup where they use that

as kind of like, um, a publish only version of the source. So I don't know where they maintain like the real kind of what I can't even say real because it's decentralized, right? But somewhere they have like a hidden repo where the people actually kind of contribute to and they publish to GitHub. So if you want to go see it or work with it, then you can find instructions there if you actually want to contribute. But if you do look at that source code, you'll see a bunch of C files. And so you'll see a file for like commit or add or bisect, but they aren't separate programs. They don't have their own main method. So there's some sort of orchestration going on there that I didn't really get too much into, but I did see a ton of other files, like things with PL extensions and PI extensions and SH.

And there's web servers in there and there's like testing executables all sorts of crazy stuff that i'm not used to seeing in projects so i thought that was really interesting when you think about it it's really not one executable it's a lot of different things it includes documentation there's just a lot of stuff actually checked into there and yeah it's really complicated and so so, you know, I mentioned those topics above. But another reason that people talk about it a lot is that your source control workflow is a really big part of, like, your day-to-day life, right? What you do when you get a ticket, how you kind of interact with your ticketing system and even your emails and your coworkers. Like, all this stuff is kind of built on and really kind of modeled with Git.

So it has a big impact on your day-to-day quality of life. And so ideally that's going to align really well with how you're actually using. You don't want to be fighting your branching strategy day in and day out. And we'll get into some of that, but it's true. Like it can totally change your quality of life during the day, depending on which strategy you choose based on the pros and cons that we'll be talking about. And your role within the team. Yeah.

This is the guy who's in control of a lot of the Git stuff that we do. Yeah. You know, do you guys, I don't know if we talked about this back in episode three, but have you ever looked to see where Git got the name Git? No. Oh, I remember something. It was like, I remember reading something about it. It was like just random gibberish or something that he made up.

So there's kind of four reasons that are kind of given now. And you'll see this in Wiki. It's actually in the GitHub repository. One reason is that it's a random three-letter combination that's pronounceable and isn't used or wasn't used by any other Unix command. So that's the kind of name I would come up with. But there's also the notion of this stupid, contemptible, and despicable kind of

simple. When you think of the slang, if you call someone a lucky git, then there's that and so um global information trackers if you're in a good mood and then there's the uh the fourth uh response which all of this kind of line is from else is like there's kind of four reasons for it and depending on my mood that's the one i kind of think about it but the the fourth one is the beep idiotic truckload of beep when you're having a hard time i kind of feel like the global information tracker, like you remember that old meme from like years ago? It was like kind of like a video kind of meme. I guess it wasn't really a meme, but it was a joke meme of like, you know, when Apple

designs a product, it's like, you know, it's very simple. It's iPhone with just a picture and one word, right? And there's no versioning. It's just word, right? And there's no versioning. It's just iPhone, right? But then there was like the Microsoft iPhone, and it was like Microsoft Productivity Edition iPhone, Microsoft Professional Ultimate Upgraded Edition for 2018 iPhone, right?

And it was like, well, if Microsoft were to create NameGit, it would be the global information tracker. Yeah. Microsoft. That sounds about awesome i'll have links to those guys in the uh the source code so you can check that or in the show notes so you can check that out all right so let's dig into some of these workflows and let's start with the centralized workflow so this is going to be your most basic of the workflows here. And the idea is you're going to have a main repository that's centrally available.

And everyone on the team is going to commit their changes directly to master. You're not going to bother with branches. Nobody's got time for that. It takes too much effort, whatever. You can't be bothered to type in that extra command. You're just going to commit your changes directly to master and merge them in. Now, in this workflow, that central repository is treated as your sacred, immutable source of truth, right? You're not going to go rewriting history on that. That's it. So we'll go through some examples. Now, we won't go through example commands for all of these but

just to kind of set the stage right i wanted to go through some of these so you're going to you'll initially create that that central repository but then as the developer you're going to clone it locally using a git clone then you'll make and stage and commit your changes like you normally would so you know using your editor of choice you'll make the changes, then you'll git add to stage them and git commit to commit those changes. And then when you're ready to merge the latest changes from the central repository in, then you'll do a git pull to pull down the latest changes.

Now, if you're a subversion user, this would be similar to an SVN update. Would I have a typo? All right. So it threw me off. Sorry. So then now if you want to, we've talked about the rebase option, if you wanted to keep your changes, um, at the tip of the history, then you can use a get pull rebase or get pulled dash dash rebase option to, uh, take all of your commits and move, you know, merging the latest from the remote, um, master move all your commits to the tip of that history. so they're all nice and together, right? And so that it flows in line and they're not intermixed in between, right? Yeah. So what he's talking about specifically for people that don't have experience in this

is if you were to do some work on your branch, commit that, do some more work, commit it later, do some more work, commit it later. do some more work, commit it later. When you go to pull in the remote repository into yours to merge it in, if Mike had also done some commits in that timeframe and Joe had done some commits in that timeframe, it's going to line them up with the time that those commits happened, right? So all mine are going to be intermixed with all theirs. And so it won't be easy to see what the logical trace of work being done was. Right. Because I wasn't working on those files when Mike was working on them.

I was working on them in my own time. So what he's talking about is if you then pull that stuff in and you do a get rebase, what it'll do is it'll take all your work and put it at the very end. Right. Like it'll say, hey, these were the last ones that went in and it'll be in the order that you committed them in. So you'll be able to see all your changes together. So to just quantify what you said, if you and I worked on the same file, and we had commits that were within a minute of each other, we each had two commits, so a total of four, then the difference is, if I didn't do a get rebase, then the commit order in the history could be Alan, Michael, Alan, Michael. But if I do the rebase, then it could

be just Alan, Alan, Michael, Michael, which is describing what you're talking about. Exactly. And that's really helpful, by the way, when you go back and you look at history on a branch or a pull request or anything, anytime you're looking at history, it's a heck of a lot easier to look at it and say, Oh, well that was the first change that Alan made. The second change,

the third change, as opposed to wait, Alan made a change and then Michael made this, but what, how does that fit into the plan? Right? So it's extremely helpful when you can line these things up. And I did want to give her,

Oh, sorry. I was going to say, have you ever seen a funny situation where you're like, look at source control and like, maybe you're not so used to get and you think like, okay, there have been no changes since yesterday. So I don't need to do a pool. And you don't realize that in the meantime, someone merged something in, but it was a change they made like yesterday. And so the change snuck in back in the history and it's not at the top of the pile because they didn't do a rebase. Yep, definitely. Yeah, so I mean some of these commands, I'm kind of glossing over the commands because I didn't want to get too deep in the weeds with the commands. So just know that there are other – there's extra options and parameters to add on to these commands.

But I'm just giving you the high-level get-add, get-commit, pull type of options, right? But when you do do the pull, that'll allow you to handle conflicts on case-by-case basis. And then when you're done with handling any conflicts, if there were any, then you can push your changes using a get push, which again, if you're coming from a subversion background, that would be similar to a SVN commit option. All right. So why would you use this? What are the pros? What are the cons of using the centralized workflow? Well, right away, like this one is the stupid simplest version of any kind of workflow that you could use, right?

It's easy to understand workflow, especially for a team. If one or more people on your team are transitioning from subversion, then this makes it simple for them to understand the workflow, right? And honestly, you might be thinking to yourself, like, why would I ever use this project or this workflow? We would never use this workflow. Right. Would you guys agree to that? Yeah. Except for your next bullet point. Okay. But we do use this, this workflow. This workflow is actually great for small teams and, or small projects. So if you're, if there's going to be few contributors

or few contributions to the project, then you might not need all the hassle of something else. Even in your work environment, you might have, you might have a large team of people that you work with. And that's why I say we actually do use this workflow. Um, it, but on some of the smaller, you know, parts of an overall application, it's like, okay, that, that one's in its own repository and it rarely changes. So why go through all the process? Right. So, um, the cons to the, to this workflow though, is that if the team does scale up,

or I should say, when your team scales up, resolving conflicts can become a huge burden on the team does scale up, or I should say, when your team scales up, resolving conflicts can become a huge burden on the team. So another way to say that is as the number of contributions or commits to this repository happen from various places, then that's where it's going to become a problem. And you're really not leveraging Git's distributed nature with this scenario, right? But like I said, if we go back to like, well, when would the seasoned Git guru might want to use this, right? Like the small projects that don't change. There's no sense in creating extra process when it's not necessary until it is hey so real quick i want to go back on the conflict thing because if you if you haven't worked in source control a lot you probably don't you don't know exactly what we're talking about

here the conflicts happen when two people change the same file essentially. Right. And, and you got the same area of the same, the same area in. Yeah, exactly. Like if you're both Mark, you know, playing around and around line 20 and 21, then,

then it's going to have a hard time resolving those. And it's going to ask you to say, Hey, make an intelligent decision here on which one of these should win, or you're presuming it's going to be an intelligent decision or maybe not so intelligent but it could also be hey maybe neither one of these win when the two are brought together and you're going to have to sort of modify this to make it right and the thing that i guess what i wanted to point out with this was the conflicts happen there are tools

that you can use to make your life a little bit easier. Like I use KDIF online, and it's a three-way merge tool. So there's other ones out there, but just be aware that these things exist. And Visual Studio actually has a very nice one built in. I was about to say, some IDEs might already have this built in. Yeah. Well, depending on your IDE of choice. Of course, if you're going to tell me that Vim is your IDE of choice, then you might be out of luck.

But it's worth pointing out, I wanted to bring this up though, because one of the key benefits, we're going to talk about the workflows even more in a second, but one of the benefits of using Git is you can have truly concurrent development going on, right? And that's awesome. But with that comes the conflicts. And so knowing how to resolve them and then also knowing these workflows will help you either get away from having to deal with them so much or allow you to, to handle them just when they come up and it's not that bad. Actually, that's another point too.

We didn't really discuss this at the top when we were talking about like why to discuss this or why discuss the workflows and, or maybe we did and I didn't over look at it or whatever but yeah thanks yeah uh but you know it's helpful it's helpful kind of like what you were saying you should know when to use which of these workflows and why so that it um to avoid it becoming a burden on the team. So it is good to know because you will use, it's not like one size to fit all in your entire organization. You'll use multiples.

And honestly, I mean, I think the reason we came up with this particular show is one, Outlaw loves Git. And I think all three of us are pretty seasoned with git i wouldn't say that we know the bible inside and out of git but we know how to work with it right but we've experienced a lot of pains with git depending on the types of projects we're doing the the you know whether or not you have support multiple or whatever so that's the reason why we thought this was an important one is because we've sort of learned through some massive pains, which ones work and which ones don't. Well, I still think this one works out really well. Like, especially if you're like a solo

developer working on like a GitHub project, like for like a side project, I think this is a great place to start because it's low overhead, but also because it can be really tricky to like name branches and do these other strategies if you don't have like a clear focus and you don't have this other process around like tickets or like clear-cut feature names like if you're just doing stuff or cleaning up the ui then it kind of stinks to have branches named after that because it kind of implies that you've if you have like a cleanup branch that means that you're not cleaning up other times and so it just the names get kind of messy and trip you up.

And so I think this is like the one I start with when I'm a solo developer. And same thing with like with Git, sorry, QIT definitely started with this method. And as more people started contributing, it just got unwieldy because it got really hard to tell like what's going on. And sometimes I'll be kind of working something or wanted to ask about something. And if you didn't have branches, you just couldn't really do that. So I think the branching strategies kind of start as an evolution of this. Like this is almost the base starting point for Git.

Like this is the subversion standard workflow. And, you know, we kind of came along to add functionality on top of that, but it still kind of supports that basic centralized pattern. That's a great point. Hey, real quick poll here. Do you prefer command line or do you use tools like Visual Studio or any one of these other Git tools out there? Command line.

Command line. Command line. All right. And the reason for me is just like, you know, I think the tools are great, but it makes me kind of nervous to not really know what the tools are doing. And I learned Git from a command line basis. So I like to know what I'm actually kind of doing on a very granular level. And I know like even the tools like you'll hit, say, merge and you'll watch where it actually generates.

And it's like merge DAX SF, you know, underscore whatever, like weird stuff, pipe it to this. I'm like, oh, wait, I don't know about any of that I need to be able to fix this when I inevitably get myself into a terrible mess I completely agree although I do use the merging the visual merging tools so KDEF or Visual

Studio or whatever I hate digging through the files looking for the alligators and all that kind of stuff like I don't want to deal with that you know I always I still digging through the files, looking for the alligators and all that kind of stuff. I don't want to deal with that. It hurts my soul to think about large, I guess not large, maybe medium organizations relying on Git for merge conflicts

because they help you line by line, but they don't really help you with intent or context. So if you imagine you've got two developers on a small project and one of them goes to a webpage and says, you know what? The title doesn't really match with the description of this, uh, the paragraph underneath it. Let me change the title. So it's more accurate to reflect what's in the paragraph. And then same day, the same time. And the developer's like, you know what? This paragraph doesn't really match the title. Let me change the paragraph a little bit to fit the title better.

And then you merge it and things totally went sideways. But it's always amazed me that this doesn't seem to come up as often as I would think it is. I thought when I first started about subversion, I was like, it's never going to work, guys. But it totally does work out really, really well, 99.99% of the time. Yep. So let's move on of the time. Right. Yep. So let's move on to the feature branch workflow. So like Joe said, the centralized one, we'll call that the de facto standard Git workflow. And then the feature branch is really going to be,

even though we were kind of saying that the centralized is the de facto, the feature branch is what everything else is going to build upon. So this one is, you're still going to have that master branch, but all your development for new features are going to be performed in a dedicated feature branch. And this will allow the developers on your team, it'll give them the ability to iterate on a feature without the need to modify master until the feature is ready. Right? So hopefully this means that master never gets incomplete code. Right?

Nothing is merged just because, you know, you're going upstairs to change computers. Joe. So convenient. Which makes it advantageous for continuous integration and continuously deployed environments. So you could also refer to this as feature encapsulation. And this feature encapsulation allows teams to utilize pull requests which is a great opportunity for the team to discuss and review the code before it's merged into masters right and like i said

this feature branch workflow is going to be the building block for other workflows. Not necessarily all, but several. So real quick, we're going to start from master. So we're going to get checkout master. We're going to create a branch off that. So we might do like a get checkout dash B, my new feature. And then same as before, we'll make our changes, stage them and commit using get add, get commit, push them up after we've merged in whatever changes were from the central repository or the remote repository. So we'll push those using get push. And then whatever the tooling is for our repository management system, we can use that tooling to create a pull request.

So like a GitHub or a GitLab or Visual Studio Team Services, Bitbucket, they all have the concept of a pull request where they will allow you to visually see what's going into, you know, what changes are being requested. All right. going into what changes are being requested. If there were conflicts, you would have had to address those before your pull requests can be merged in. So you will have to handle those locally and then push that back up into your feature branch on their remote source.

And then, what did I put here? Oh, if another developer, another advantage or feature of this is that if, say, Joe and I are working on the same feature together, I can push that feature branch up so that Joe can pull it down and we can iterate on the development of that feature together without interfering with master or anything like that. So, you know, it allows us to each have our own copy of it and iterate on it together. So the pros to this workflow is it allows, or I should say it promotes code review and team collaboration, right? And that can be taken in multiple ways, right? There's not only just the PR aspect of the code review and the team collaboration, but there's also the ability, like in the Joe and I are working on the same thing example, right? Like we can collaborate on that code together, right? And we can iterate on it together. And then there's the pro that this is going to keep your master stable while you are developing on this new feature branch.

So the new feature has all the code that's incomplete and it doesn't get merged in until it's ready. Now, the cons to this, though, is that if you have long-lived branches, those long-lived branches are going to be a higher risk of merge conflicts. So your best bet is to keep your features small so that you can merge your feature branches often. How often? I mean, that's going to vary, really.

I mean, there's no set, I would say, but I guess a big factor is going to depend on like how often the repo changes anyways. Like if the cadence of that, of that development, if it's an open source project and the cadence of it is, it's not seeing a change, but like once a week, then okay, fine. If you, you know, if you got two weeks behind, you're probably not going to miss a whole lot. Right. But if you went three months, it would be a problem. Whereas if you're on like a work repository that's changing massively every day and you got behind by a week, you could be in trouble. Forget about if you got a month behind, then you'd be in serious trouble. That's where these long-lived branches can be problematic. When should the seasoned Git guru use this type of workflow? Well, so my joking

answer here is like, well, always, right? And I say that kind of serious, kind of not serious, but kind of mostly serious, because like I said, this is going to be a foundation or a building block of other workflows. So whether or not you're using this one by itself or not, you're probably going to use aspects of this workflow. This is definitely going to work out better for large teams or projects when compared to the centralized workflow. And yeah, I already said that it was a building block. So a couple of things here. The thing where it's used by large teams or whatnot, this goes back to what Joe said a minute ago about when you have ticketing systems, it's a whole lot easier doing these branches, right?

Because you have a ticket that you're working on, and it could be ABC-1, right? Then you kind of have this outline of what to name your branches. And so it was kind of easy to line up your code with whatever the requirement was. And so that sort of eases it. Like what Joe was saying earlier is if, if you didn't have something or some sort of process in place to say that, you know, this feature is ABC dash two, then you're probably going to name it, uh, my clean feature dash, you know, I don't know, ABC, whatever you just start randomly creating branch names and it can kind of turn into a mess and it's sort of hard to keep up with all that stuff. It's not necessarily a bad thing though, to name your branches off of the features. I mean, I, my personal preference is

definitely to go off the ticketing system because then you have the ability to track it back to whatever the, the, the sources, whether that be manually, or if you're in like, for example, if you live in a, in, in the Lassian world entirely where you're using like Bitbucket and Jira, then those things can be tied together to where just the mere mention of the ticket name in the commit message or in the branch has the ability to allow a link in the UI back to the original ticket.

And Visual Studio Team Services has a similar feature. So that's why my preference is to go by branch name. But if you're not in, if you're not in a, a large enough project where you were using that, then naming it off of the feature, like maybe you, uh, you know, new left, not a left nav redesign, you know, might be your feature branch, you know, as long as it makes sense and there's some consistency in it, then that's where, you know, consistency is what's going to matter. I agree. Now, the other thing I did want to bring up was the whole multiple people working on the same branch. So that's awesome, right? I create a branch locally. I push it up to the origin, which by the way, that is sort of the

de facto name when you're talking about Git for the centralized repository is the origin. By convention. By convention. You can name it whatever you want, but by convention, it's origin. You can push that up there, right? So my feature branch, and then Mike and Joe can go work on that thing, and we can all pull it down, and we can all work on these, and any time we push up changes, next time I pull them,

I'll see their changes. Right. But you have to be careful with that because we talked about the rebase thing earlier and that it lines up commits. When you're working on a shared branch with other people, rebasing rewrites the history of that stuff. And you can just get into a world of hurt with that. Right. So you have to be at least mindful of what some of these things are doing when you're going to push them up, right? If you're going to rewrite history on

something that's already a public branch, you could be causing a lot of problems for other people. So just be aware of that. Yeah. A couple of things I want to mention too. A lot of people, I went looking for get opinions when I kind of read about it not being that opinionated and boy, I found them. There's a whole website titled Get Opinions and whatnot that offers some strong guidance on some of those controversial topics. And some of the ideas

I saw, we'll have links in the show notes and resources we like, but people advocating for initial prefixes. Especially if you have a system like Visual Studio does this. I think GitHub does too, where it will kind of see slashes and branch names and treat them as folders.

So you could do like your initials, jz slash and then ticket number or then feature name. And that way it kind of scopes it to you and makes it easy to kind of see like what branch kind of is owned or been created by who. And it's easy to see that in the pull request too so i think that's pretty nice depending on um you know your editor and maybe initials aren't good enough if you got a big team but um you know it's still kind of cool and i also wanted to mention too that i looked up specifically on the cadence and a lot of the

the strongly opinionated strongly opinionated get users, if you have a Git website, you're probably strongly opinionated. But I was really surprised to see so many people reference checking in, or rather committing and pull requesting your branch daily. Really? Just pushing it to the origin? Yeah, getting it pull requested in. But for, like, what was the cadence? They didn't specifically talk about cadence. They just said every day.

I assume they're talking about, like, a works situation where there are commits going in every day. So non-code complete. That sounds like the Visual Source Safe way of doing things back in the day where it's like, get all your code in by the end of the day. I don't, I don't understand that in the get world. I would never, I would never advocate for merging code in that isn't complete. I agree.

I agree. Just straight up. I totally disagree with doing it just because it's the end of the day. Yeah. That seems artificial. Yep. I agree. There are some techniques for kind of working around that.

So rather than checking in something that's not done, you would like either deal with a feature flag or some other way of kind of doing that. But the idea there is mainly just to avoid those long-lived branches. So you want to avoid having a situation where you've got a ticket that takes you three weeks and you either subdivide that into multiple tickets or multiple features or do ideally some other way of doing it. That said, I don't do that. It depends very much on the case. I definitely hate long-lived branches, but I think two or three days isn't going to kill anybody. Yeah. Like I said, that's why I was trying to say that it's really going to depend on the cadence of things are getting merged into that, to that repository where the length of time is going to matter. But

for those that aren't familiar with feature flags, I don't know if we've ever discussed that here, but the idea with feature flags is you could have a branch of code. Maybe you're working on it, but unless you know the, the special way to turn that turn that bit on, it won't get executed. So that could be a pre-compile directive so that the code compiles with that functionality in use. Otherwise, it's not even part of the compiled output, or it could be something as simple as a command line parameter, or maybe a query string parameter that triggers that execution of that code. But it's, the idea is you can slowly, but surely leak in your feature into the main, uh, code base, in this case, let's just call it master, without it impacting anything else. Yep. One other thing before we move on to the next one, the long-lived branches,

we've mentioned it many times. And like Mike said before, that truly just depends. Like, does it matter if there's only one commit happening per month? No, I mean, you could probably go for a whole year and it wouldn't matter. Right. But the way to deal with long lived branches typically to cause the least amount of pain is to constantly as frequently as possible, pull in the origin stuff, right? Merge in the latest changes from whatever you branched off of in order to do it. Now, that doesn't mean it's going to be painless, but it

does mean that you have less chances of conflict as you bring that in or the conflicts that you get will be easier to pinpoint because it'll be a smaller subset of code that you're dealing with, right? If you go for a month before you merge in the latest code, then you could get hundreds of conflicts and you're not going to be able to figure out the scope of what all changed. Well, that's not always going to work though. No, not always. That's why this is a great segue into the next workflow, which is affectionately known as GitFlow. So how this works is we're going to build upon the feature branch workflow.

So similar to that idea, but instead of having just a master branch, we're going to create additional branches. And these additional branches are going to have very specific uses and purposes. And not only do they have specific purposes, but they're going to have specific times when those branches should interact with other branches, right? And the master branch here will represent our officially released version, or versions, I should say. We will create tags off of master for the versions that we release, right? Typically in this workflow, you will have a develop branch and that is the branch that all of the developers on your team will use to iterate on the next version. So what I mean by that is in the feature branch workflow, we created a branch directly off of master, but in get flow, we're going to create

our new feature branches based on develop instead. And when it's, then we'll, you know, when we're done with that feature, we'll merge that into develop, back into the develop branch. Then when we feel it's time to release our branch, I mean, a version, or maybe we have compiled enough features that it's time to release. But whatever our reason is, we're going to create a release branch based off of develop branch and use that. So we'll do all of our testing off of that release branch. And if we find anything that needs to be fixed, we will apply those fixes to the release branch. We'll just apply them directly to the release branch. So what we've said now is you've got develop, you branched off develop to your release branch.

And then any fixes that are going to happen, you're going to basically just check those, commit those straight into that release branch. Yes. So now once the release branch has been tested and we have certified that it's ready for release to production or manufacture, whatever your choice of term might be for your environment, we will merge the release branch into both master and develop. Now you might ask, well, why would we go back to develop? Well, any fixes that we found in that release have to go back to develop. We don't want those to get lost. Now we've merged it into master. This is when we will take the opportunity to tag that version number. Now, so far we've talked about three branches so far. We've talked about our master branch, which is our default, our develop branch, and then this release branch.

And technically, now that we've merged the release branch back into master and develop, technically, we don't need it. So we could think of that branch as like short-lived. It's going to come and go over time. And there's going to be another short-lived branch like that. And those are going to be for hot fixes. So if the production version, i.e. master, in this case, if we notice that there are issues with master and we want to immediately address those without waiting on a new version, then we can create a hotfix branch based off of master and make our changes there, test them, and then merge that back into master.

This is the only branch that we're going to make directly based off of master. Everything else is typically going to be based off of develop or possibly the release branch. Oh, and I forgot to say this, this hotfix branch, we will merge it into both master and the develop branch, right? And again, we will tag master to update our version number. Now in this scenario, you know, we've kind of already laid some groundwork there for commands. And I was like, you know, it've kind of already laid some groundwork there for commands. And I was like, you know, it's going to get way too lost in the weeds if we start going over all the commands for every one of these workflows. So really what I wanted to point out here is like we haven't really introduced any new commands. It's the same kind of commands that we always did.

You're going to get the repo by doing a git clone. You're going to stage commits using a git add. You're going to commit them using a git commit. You're going to, you know, doing a git clone you're going to stage commits using a git add you're going to commit i'm using a git commit you're going to you know do your git checkouts your you know get pull get push like all the same commands we talked about before you're still doing all this so there's nothing new here so um but the only difference now is where you're doing these commands right like whether you're branching off master whether you're branching off develop or or where you're committing to and where these pull requests are happening from, it's literally just changing places, right? Like where you're initiating a lot of these commands.

Yeah. And, and, you know, to that point too, I'm going to have links in the show notes that will point you to, uh, places that are like list out out if you wanted to see very specifically, you know, every individual command and like what it'll look like. Because I thought that might be a little bit difficult to keep up to while you're listening on your commute or, you know, as you're cutting the grass or whatever, you know, riding your bike or whatever, you know. Okay. So I do want to call out the tags though.

The tag is the major difference, I think, between the previous and this one. And I think the tag is really important from an organizational level because that's really what we've added here is like we've kept the feature branches. It's just, we've kind of organized things into separate branches

in order to kind of streamline our release process because things, it basically models the real world. so i did want to go over real quick like as a developer when would i merge my pull request directly into master in this workflow yeah only on a hotfix yeah hotfix only okay hotfix. When would I merge into develop? When your feature is done. Yep. Yep. And what was the third?

I missed that. Merging off of a tag. We didn't talk about specifically checking out the tag. If that's what you mean. I think, yeah, I kind of think of that as being a third. But the idea there is like if you kind of have a hot fix out there and uh you need to kind of um you know apply a specific hot fix to something that's not master like for example if you've got like kind of um more than one concurrent release which is that we're about to get into but things get kind of hairy because in that case you would have to go and find the appropriate tag for the

server that you need to update make your change on top of that tag and commit that in there and then somehow get that back into your master development branches which is sometimes that's a change that you don't necessarily want to get in there and so that's where git flow gets a little kind of gross and i do think a lot of people kind of think of git flow as being the answer like this is how you do it and um they start kind of running into some of these problems, especially with the tags. And things get a little messy because GitFlow doesn't line up perfectly with their business. And that's why I think that GitFlow isn't a one-stop shop kind of answer. Yeah.

And we're going to look at a couple things here in a little bit that are going to deal with that a little bit better. But it does have a lot of great benefits. So I don't want to beat it up. No, no. So to go over what the pros of the GitFlow workflow are, this is ideal for projects that have a scheduled release cycle and great for projects where you only need to support one version. So for example, this might be your company's website. Typically, you're not going to have multiple need to support one version. So for example, this might be your company's website, right? Like,

you know, typically you're not going to have multiple versions of your company's website running concurrently. Now, if you're thinking of like a Facebook or an Amazon, you know, yeah, they might AB test some features and they might have like multiple versions depending on regions and things like that. I'm, I'm not talking about like the gigantic, you know, enterprise corporations like, like them. We're, we're, I'm talking about more of like the, you know, the small business owner that makes up the rest of the, you know, the economy. And this is really important. One version or maybe two versions, but a fixed number, right? A very, probably a very small fixed number of versions is, is where I think this would work the best. I think one, I really, I really, I really do think one. Yeah, that's probably true.

And we can continue this conversation when we get past the next ones. Right. Yeah. So, so put a pin in that one and we'll come back to it. So other benefits, this has all the benefits that we talked about with the feature branch workflow are still here because we back to it. So, uh, other benefits, this has all the benefits that we talked about with the feature branch workflow are still here because we built upon it. So, uh, the pull record, the idea of the pull request and the isolated feature development, the collaboration, all that still here. Um, there's also tooling that exists specifically to help stream, streamline the

process of using get flow. So if you wanted to get all in, if you've heard everything we've said so far and you're like, I'm sold, there's actually command tooling that you can install. So even from a command line, it doesn't have to be visually, but from a command line, you can use commands that support the GitFlow workflow. But if you're sold, wait until we get through the rest of these workflows. You should wait.

You should wait. All right. Don't jump off your bike right now and go do this. Just wait a few minutes. Keep pedaling. Yes. And you know, a lot of the graphical tools are kind of biased towards this.

Like even if they aren't specifically designed for it. So some of the graphical ones, like just don't look so good if you've got long lived branches. Um, and a lot of tools don't handle tags very well too. So it's just not, yeah, you know,

tags, tags kind of stink. If you have a lot of them, that's great. If you have a few, uh, so, um,

again, similar to them to feature branch master should theoretically only have stable code. Um, and this allows this workflow also allows you to split up your teams in such a way that you can have one team polish the release, for example, while another team is working on features or teams are working on features for the next release, right? As well as you can have hotfix in your hotfix branches, you could have a different team that's addressing production critical issues without disrupting the other teams that are trying to polish that build or develop those new features. Alassian, in some of their documentation that they had regarding this, they actually referred to this hot branch feature as a dedicated

channel for hot fixes to production. I kind of liked that terminology, the dedicated channel. And then I put this other pro here, and this is going to make a lot more sense now, but consider this an earworm. No commits left behind. So, you know, it considered that an advantage of, of this workflow. The cons like one stream, right? I'm sorry.

You kind of have like this one stream, like master is your master stream. You have one kind of thing that everything kind of breaks off of and goes back into. Yes. Eventually. And in fact, you know,

a lot of, um, a lot of articles that you'll read about Git and see about Git when you see – well, okay. Let me rephrase that. I'm going to assume that you read a lot of articles about Git. Daily. It's my morning wake up. I know I've read more than my fair share. And you often see a lot of like they're called the subway line drawings

for it. And, you know, there's some really pretty ones that, you know, try to describe the get flow, uh, workflow, but let's go over some of the cons for it. So this does not work well for projects that need to support multiple versions concurrently. So if, for example, let's say that you worked at Microsoft and you were supporting all currently supported versions of Microsoft Windows, this would not be an ideal workflow for you. Trust us. Yeah. This is true. So the extra con to this workflow in that regard would be welcome to merge hell.

Population you. Man, this is no joke. Like, seriously, we the three of us have tried this workflow on something that required multiple versions and your daily life was literally just fighting merge conflicts it was definitely some lessons learned and it's demoralizing i mean it worked fine for a while it worked fine until it didn't and then it was then it was it's like you know you're looking at the edge of the abyss and then you jump off into it. There was literally just a sharp drop off of productivity once you cross that line. Actually, I can tell you when I say that it worked fine until it didn't, as soon as I said that, it dawned on me.

It was like, oh, yeah, because in the beginning, we didn't have a lot of versions to support concurrently. But then as those backlog of versions that we had to support built up that's where it started becoming like you know when you only had like you know you had the first version out there and like woohoo and then you know you have two versions you're like okay well i mean how often am i really going to have to feel this pain and then you know the third one comes along man. Yeah, because you're constantly making these changes to each version, and this flow doesn't work for it. Now, this flow is awesome, like you said, when you have one A product that is always the latest that you're working on, right? This flow works great for that. But as soon as you step into the world of you've got several versions of iOS that you need to make changes to bug fixes, security fixes, you will just lose massive amounts of productivity. As well as your mind.

And your mind. And the thing is, the problem is if you Google this stuff, everybody will be like, use GitFlow. Right? Like I think, Joe, you even said like everything you look for says this is the way and that's a problem because this is the way for very specific probably a very popular use case which is you have a product that you're constantly iterating it's it's all about marketing you see and this one has a good name it really does GitFlow is beautiful. I think it probably works best for most companies these days that have one website or one kind of product that they're working on. But I was just trying to think of a good example of someone to the contrary, and I came up with Python.

Python's got the big 2, 7, and 3 split, right? But even in 3, there's 3, 0, 3, 1, 3, 2, 3, 4, 5, 6, 7. They're up to 3, there's 3.0, 3.1, 3.2, 3.4, 5.6, 7. They're up to 3.7 now. So imagine if somebody finds a terrible security exploit in 2.7 and it got carried over into the version 3s. Then this security fix needs to get applied in 2.7, latest 2.7, and then in 3.1 and 3.2 and 3.3, 3.4, because those typically have different release structures. And if you've got code that works on 3.1 and 3.2 and 3.3 and 3.4 because those typically have different release structures.

And if you've got code that works on 3.4, you may not want to upgrade to 3.6. And some languages will deal with that by saying, like, you have to go to 3.7, but not usually. That's a pretty big dot change. Like, people don't typically willy-nilly upgrade something from, like, a 3.1 to a 3.7.

Right. And so that's a case where you don't want to have 15 tags for this thing. Yeah. And I know we're doing a bunch of, you know, yeah, but yeah, on this. Again, nothing against us. It works great if you have that use case. Right. So just keep that in mind.

Yeah. So, you know, again, I think to sum it up, like in my personal opinion, like if you only have like the one version you need to support, this is a great workflow for that. But I also wrote like in the, you know, like when should the season to get guru use this? Like, you know, you're familiar with all the commands and, you know, you're getting familiar with all the different workflows. Like when should you pick this one? This works really well for projects where you tend to only roll forward. What I mean by that is if you never have a situation where you have to roll back, then this works great. If you have to roll back through previous versions, then maybe not so much,

but if you're always just rolling forward with your, uh, feature changes, you know, or, um, your repository, you know,

if you're able to just like, Oh, there was a problem. Okay, well I'll just fix it in a hot fix and then we'll just deploy the next master. As soon as that hot fix is merged in, this is a great workflow for that.

So it, it definitely has its place. Yeah. And can you imagine the merge conflicts trying to go from like 2.7 to 3.0 Python? Oh, man. Good luck. And then even like from getting from 3.0 to 3.7 without any conflicts?

Yeah, right. Yeah. Well, that's why I put the merge hell, you know, population you joke in there because it's like it's really not a joke. It's really like if you are in that situation, this will cause you some pain. And it's literally all day, every day. It feels like every time you go to make a change, you're like, oh, please, please. Like it's rolling the dice. And I can't reiterate what Alan said.

We're not trying to hate on this workflow. This workflow is awesome for its purposes. But if you try to use it for things that it's not intended for, you will regret it. Yeah, I think that's really the takeaway from this episode at the end of it. And hopefully you're getting that now is do not do this. This idioms used a lot. Don't try and shove a square peg into a round hole on this one. Don't do it.

It's not worth it. All of these workflows have their place. Yes. If you've ever Googled how to do a pull request from a tag into a tag, then you might want to consider a different workflow. Is that your tip of the week? Tip of the week. That's all.

All right. All right. All right. So, hey, let's take a quick moment to ask you to leave us a review because we really appreciate it. And if you've done it already, we really appreciate it. It's a huge help to us. And if you haven't, if you could take a moment and do it on like Stitcher or iTunes, that really helps us kind of, you know, find and grow and do our thing. So, we really appreciate it. And if you could just go to codingbox.net slash review, we try find and grow and do our thing. So we really appreciate it. And if you could just go to codingbox.net

slash review, we try to make it really easy for you. And don't be afraid to tell a friend. They actually say that's the best way to kind of spread and grow. So if you've got a friend or a co-worker that you think would be interested in the show, then you should tell them to check it out. Just walk in the room, check it out.

Alright, so let's get into my favorite portion of the show. Survey says... Alright, so last episode we asked, what's

your preferred password manager? You know, we can't do that well because we're recording ahead of time so for those listening now you're like wait a minute michael you can't do that and i would say you're right you You're right. That's why I actually clicked on the poll results for the wrong one. So instead, I'm going to skip last episode's poll survey, and we will come back to that next episode. Oh, that's so good. You're going to have to be wondering. Yeah.

And you're going to be thinking like, wait a minute. How long ago did they record this? You'll never know. That's right. Oh, that's a beautiful catch, man. I was like, wait a minute. this is a match on my screen why are my eyeballs tricking me it's like why do we have zero votes oh we haven't published this one yet that's right um all right yeah so much for a buffer well we tried guys we tried so consistency

be damned so eventual consistency yes uh so this we ask, what's your social platform of choice? And your choices are Facebook for the old world or Twitter. It's the best way to catch up on my cofefe. Or Snapchat, because a picture is worth a thousand words. Or Instagram, because a picture is worth a thousand hashtags. Or LinkedIn, it's all about keeping it profesh. Or Google+, I like the dust and cobwebs. And lastly, social. Get off my lawn, kid. What? You want the government to know everything about you? I tried to do my best old guy camaraderie voice there.

I don't know if it worked. You're there, man. You're there. Oh, really? I might have pulled that off a little too good. Pretty good. Dang. Yeah.

And hey, as a reminder, if you send me a LinkedIn Ponzi scheme invite, I will accept you eventually the next time I log in. Same. Same here. Yeah. You guys must have numbers. Never mind. We won't even bother. Yeah, we got a few.

Oh, man. Datadog is a software-as-a-service monitoring platform that provides developer and operation teams with a unified view of their infrastructure apps and logs. Thousands of organizations rely on Datadog to collect, visualize, and alert on out-of-the-box and custom metrics to gain full-stack observability with a unified view of all their infrastructure, apps, and logs at cloud scale. Datadog has 200-plus turnkey integrations, including AWS, PostgreSQL, Kubernetes, Slack, Java. You can check out their full list of integrations available at www.datadog.com slash product slash integrations. So is it Datadog or Datadog? We'll leave that up to you. It's whatever I said it was.

Who knows? All right. So some of their key features include real-time visibility from built-in and customizable dashboards, algorithmic alerts like anomaly detection, outlier detection, forecasting alerts. They have end-to-end request tracing to visualize app performance and real-time collaboration. And Datadog is offering listeners a free 14-day trial with no credit card required. And as an added bonus for signing up and creating a dashboard, you can get a really nice Datadog t-shirt.

So if you just go to datadog.com slash coding blocks, you can sign up there and just do that and create that dashboard and you will get that sweet shirt. All right. So jumping back into this, we just finished up with GitFlow. Now it's time to talk about this fork and merge and how this one works. So this one's kind of interesting. This one, rather than everybody working off the same centralized repository, every developer gets their own server side repo to work on. And you'll almost always see this in the open source communities to get hubs, to get buckets, those kind of things. This is where you're going to see this forking strategy. So what this does is this avoids everybody pushing code to the same central repository.

So rather than that, developers make changes in their own repo. And when they're ready, they submit a pull request from their repository over to the primary repository that they forked from. This is basically exactly what GitHub does on everything. And that's really important for a few reasons. One of the most important, I think, is that a lot of times if you're making a change to an open source library, it's because you need that change.

And so you want to go ahead and get that rolled into your own code. So you kind of fork the repository, you make your change in there, you update your stuff, so now it's using the updated library. But in the meantime, you want to contribute that change back to the owners. And this is a great pattern for doing that this is not going to work well something like a git flow or yet you know even try to figure out like well should this be a hot fix or should like is a individual contributor if you're not on the like the the collaborator list whatever for that repository you probably don't have a vote in that and so that's not really

an option for you but i think a big part of the reason that GitHub got so popular and along with it, Git is because it worked out really well for, um, for open source communities. This kind of this fork and merge strategy was a huge part of making code available and social. Yep. And that's, there's a couple of key points here. So when you say forked, that's the same thing as a get clone. There's no special sauce happening under the covers. When you do a fork behind the scenes, it's just get cloning that same repository into another named repo on the server. So if you, if you think about that, there's, there's nothing crazy going on behind the covers. That's it, except it's yours now, and it's a copy of that original.

Typically, when you're doing this fork method here, you'll have two upstreams. So I mentioned earlier that by convention or default, when you point to origin, when we were talking about the uh the branch workflow two i want to call them two remotes okay two remotes um the origin used to point to the central repository when you do this fork method though the origin is going to point to your repository. And then you'll have another one called upstream that would be the primary that you forked off of. And what that allows you to do is when you have both of these remotes set up is anytime you make changes, you're pushing to your origin, right? Anytime you want to pull in the latest changes from the original repository, you're going to pull that from upstream. And so that allows you to keep your code in sync with from the original repository, you're going to pull that from upstream.

And so that allows you to keep your code in sync with what the original repository was. And then when everything's ready to go, then you're going to make your pull request from there on over. Excuse me. And then I actually, I think that was it for that. So the example here, and I think I put on names on this one just because it's fun. So let's say that you have your original. I see some of these names. Yeah. You've got CodingBlocksRepo, right? Now, Billy Bob comes along and he's going to fork the CodingBlocksRepo, which is basically creating a copy of the CodingBlocks one on the server side.

And that's now his new personal one that he can mess with, but it's still public, right? So the coding blocks repos public. So is his, but it's his personal one that he can work on. And he's the only one that has rights to it. So then he's going to get clone that newly forked repo to bring it down locally. So he can make some, some changes to it. He's going to commit those and then push those changes up to his forked repo, so to origin, right? And then after he's done with that stuff, he'll make a pull request from his forked repository back to the primary coding blocks repo. And then at that point, the cool part is this can also open up discussion. Like Joe said, one of the big reasons why GitHub got so popular is you put that pull request in.

Now the maintainer of the original repo can go take a look at it and he can start chatting with you about the changes, right? Like, oh, I like what you did here. Or no, I don't think that'll work because we have some changes that are about to come in, whatever. You know, it opens up the door to people being able to discuss the code. Once once that guy gets that one and he's good with it, he's going to pull it down to his local, the maintainer of the original repo. He's going to merge it into his master and then he's going to push that up. And then that's how your changes will get into the original repository. So that's,

that's the, the flow of this one. And really the pro of it is there's two, and I should list the other one. One, it keeps the repositories nice and clean because you're not getting a ton of commits coming in just randomly and getting in there. Basically, once you're done with your body of work,

you're going to do a pull request on over. And then, then that guy can pull it in and decide whether or not to bring it in or not. The other thing too, is it also limits the number of people that have access to your repository. Right? So I think that was the other big reason why it became so popular in the open source community is you don't have to worry about giving a thousand people access to your repo. Hey, go fork it, make the changes that you want.

And when you're done, you know, send me a pull request and I'll decide whether or not this, this should make it in or not. Um, really the only con that I could see to this in terms of just how this works is it's a little bit more work than regular flows, right? I mean, it's, it's a little bit more convoluted in that you're making a copy of the repo. I guess another con that if I could come up with one is I would venture to say there's tons of forks sitting out there that never had anything done to them whatsoever, right? There's probably just tons of copies of code laying around. Well, I guess the way that Git works, though,

is probably just pointing to a – no, I guess – I don't know. No, because you have – it would be a separate repo. It would be a separate – so it wouldn't be a copy. Yeah, so – I mean, it wouldn't be – the server-side copy of the repo isn't going to look like what you're going to have locally. You're only going to have the compressed binary representation of it. It should be small.

But other than that, I mean, it works out really well. I guess that gets to the point is when should a seasoned Git guru use this? If you're contributing to open source, that's about the only time you're going to see this flow. Or I could add one more to that, too, is when you might want to use this. If you wanted to base your functionality on something that already existed, but you wanted to go in a different direction, you could do that. So WebKit might be a great example of that but you're not typically going to push those back to the main repo right like you're going to that's what i'm saying like you're going to fork the repo just so you can use it and then you're

never going back okay so instead of like you know there's no fork and merge it's just fork fork and leaving yeah and we're out yeah yeah And I wanted to mention, so QIT has got 13 collaborators. So you can imagine if those weren't, you know, officially collaborators on the project, then there would be 12 other forks sitting in GitHub of this project. So if somebody Googles for it, there's a good chance they're not going to find the original. So that kind of stinks. Actually, GitHub shows me the number of forks. That's pretty cool. I can actually go see who's got forks. So there already are

14 forks of it. But it just kind of muddies the water. You can imagine there's like 14 copies of this thing floating around. I think that's the way it's kind of got to be for the most part. Yeah, just kind of interesting. Cool. So, yeah, I mean, wildly popular.

This one's heavily utilized. Great for very large open source projects. Yeah, I think, like you said, you can't stress enough the ability of, or the pro of it limiting who has right access to the main repository, whatever you deem the main repository. And it's important to note, too, that what we're calling the main repository, technically there's no difference there. It's only the, quote, main or official repository by convention,

but that's it. There's nothing technical about it that signifies it to be different than the others. Except that's where people are going to be forking from the most, right? More than likely. That's really about the only way that you'd see it. But, I mean, you could totally see, like, your WebKit thing, right? Like, let's say that for whatever reason, my version of WebKit became super popular and people wanted to fork off that. I could probably have more forks off my repo than the main WebKit does.

So, that's even suspect, really. wanted to fork off that, I could probably have more forks off my repo than the main web kit does. So that's, that's even suspect really. Oh, you know, I never really thought about this, but like the Linux kernel is a great example of something that uses, you know, multiple concurrent releases. And it's also a, you know, big open source project. So you can imagine where somebody is like comes in and they try to add a feature to, you 3.0 because that's the one that they use or whatever. And I would think if I was a collaborator on the project, I would see that and be like, that's great, you got in 3.0, but I'm not going to bring something into just 3.0. Either it's going to be 3.0 and everything up, or else you don't put it in the latest version if it's not important. But it does put a big onus on any sort of contributor there. It's like, oh, you can't just sneak something into the backlog.

It's either got to be current or you got a lot of work to do. Interesting. I wonder what kind of branching strategy they use for Linux kernel. Well, for both the Linux kernel and Git, we're not actually, it's not necessarily the branching strategy i'm not answering that question but um they use the patch feature of git that we're not even talking about right like you know there's no pull request it's like submit your patch there and they'll include like even in the the git um repositories on github they have the email address listed there as

git at, what would that be? V-G-E-R? I don't know if that's supposed to be pronounced, but.kernel.org. Where you can submit your patch to. So you just email your patch in and then they'll evaluate it from that way. So it's a totally different workflow. I guess you want to see it all in one place. And if you've got three months worth of work in one patch and it's a ton of files, it's probably not going to get in because who's got the time to evaluate that? So unless it's a serious problem, then chances are you're not going to get in.

You need to get those things in in bite-sized chunks. I would think. I imagine they probably get like emails every day with patches that are you know like bitcoin miners or whatever right yeah i gotta imagine that would be a massive undertaking to keep up with that that inbox which which request do you like care about and which do you not so all right so you default to not like you better do a really good job with that opening letter if you want to get something into the linux kernel yeah your subject line better be really good yeah this is not spam oh that probably wouldn't work

probably not um all right so then so those are like the main workflows that you see a lot, but there's one that I don't really know how we can name it. We put like two different names here for it in the show notes, but one of the names we called it was Microsoft's recommendations. And then another one was Microsoft's branching guidance. And I did that one kind of based off of an article of the same name that they wrote on. They wrote about this. And basically a friend of ours pointed this article out to me.

And because I was really kind of like maybe bullish against some use of some commands, right? So that this particular workflow relies on. But after reading this article, it really changed my world. So how this workflow works. So this is going to be similar to GitFlow in that this Microsoft's branching guidance will use a release branches, right? I said plural, to track the releases. The biggest difference with this strategy compared to the other workflows, well, there's a couple. One, you will have long-lived branches.

So I should have said that. But maybe the biggest one that you'd be the most happy about, especially coming from some of the other ones, is the lack of merging that will happen in this workflow. Stick with us. This sounds bad. Yep. But stick with us.

Definitely. Hang in there. We're almost through it. We can get through this. Okay. So similar to a feature branching workflow, you're going to create your feature branches based off of master. And then when you're done with those branches, you'll merge those back into master. And these feature branches are the only branches that are going to get merged, right? So right away, you know, keeping up with what we said at the beginning, we're talking about small branches, right? These should be small things that are getting merged frequently. So,

you know, already our chances for merge conflicts have lessened, right? Maybe not completely gone away, but we've, we've, we're definitely lessening the need for it. Then when it's time for a release, we will create a new release branch for that version off of master and release the, or the, the version will be part of the name. Now, this is where Joe's strategy for the prefixing your branch names comes in really nice because depending on your tooling, if you create your release branches with say a release slash prefix, and so you do like release slash 1.0.0.0 and release slash 1.0.0.1, you know, and then release slash 2.0.0.0, et cetera. Then depending on your tooling, you'll have this nice little folder called release.

And then when you expand it, you'll see all of those versions right there. And it really is pretty, you know, in some of the tools. So it really helps to consolidate some of those branches that you might otherwise have. All right. Now, any fixes that you have to make to a release, unlike our Git flow where we would create a hotfix branch, instead what we're going to do is we'll create the branch based off of whatever release we're trying to

fix and merge that fix back into that branch, same as what we would do with the kind of treating it similar to as a feature branch in that case. But here's the big difference. We're going to cherry pick the commit to any other released versions that need to include that, right? Or any other place that we need to we need to have that fix, including maybe master it if the fix is applicable in that situation to that environment. Right. So basically what you just said, though, is you've got release version one release version one dot one release version two. Right. If you make a change to release version one or a hot fix, you would branch off version one off release slash version one, make your hot fix to that, merge it in. And then after you do that,

you're going to cherry pick those commits into version one dot one. If it applies there, version two dot O, if it applies there and potentially even into master. Yes. So say again, if it applies there, if it applies to master, yes.

At a granular level, you're saying, I want these guys over here, these guys over there, and these guys over there. And I'm going to skip that one. Yep. So right away, we're not even worrying about tagging our versions like we were with GitFlow because instead we're using these long-lived branches to represent our versions you know you still can tag if you really wanted to but i mean you don't really have a need for it necessarily um i i can't really think of why i might be inclined to i guess is the way i would put that i agree agree. I got one. So sometimes you want to get a specific version of something like, say, you've got a customer that's got a specific version and you need to reproduce a problem.

Then it's nice to know that they've got this particular tag and this is the particular tag I'm going to work on because someone might have fixed it since if they're not up to date. That can get hairy, though, as your number of customers scale but i mean i understand the intent of where you're going from basically you're at that point you're trying to use the get tag as a history of which customers have which versions installed which it doesn't have to be customer specific though it could just be like a you know 6.1.11 and like maybe you've got a 6.1 branch but you don't necessarily keep a 1.1 branch and 1.2 branch and 1.3 branch just i don't know if that's a good idea or not but that you would

typically kind of think about things that way depending on your setup like you know something like windows or python environment probably doesn't make sense to do that you'd probably have a branch for each one um but if you've only got, uh, a couple of major branches and sometimes, you know, you could still have like customers or people kind of using it like interstitial kind of versions of that branch and they don't all get upgraded at the same time, which is, uh, especially, um, relevant if you have like on-premise or white labeled software. Uh, and I know that's really common. Um, the guys that complete developer podcast kind of talk about, um, they had a great episode on white-labeled software,

which is like someone kind of takes your software and installs it somewhere, and it's like a snapshot of what that code is at the time, and it can kind of evolve from there. And that's a good case where you might have two people that are on a 6.1.11 and a 6.1.13, and if you're trying to track down a bug, it's important to know that you should be looking at the six dot one one because it might be something that you've already fixed or has changed that's fair okay i'll i'll take that um so in regards to like

the examples of how we're using this like really the new thing that we've introduced here is well one we've introduced more branches, more special branches being that these are the long live release branches. But specifically in terms of commands, we're going to use the get cherry pick command. Now, if you're doing this from the command line, I typically like to include the dash X parameter, which will automatically include in the commit message. Hey, this, this commit was cherry picked from this other commit, and it'll automatically get the ID of that other thing for you and include it in there. Um, and it makes it easy to like, when you look at it and it'll include the previous commit message from that commit as well. So it makes

it real easy to try to follow that. But it's kind of advanced to where if you're using something like a Visual Studio Team Services, they'll do this for you. Assuming that there's no conflicts, just straight from the UI, as soon as your commit is there, you can start cherry picking it into other branches. And they'll go so far as they will create branches for you that your commit goes into and then they'll merge, they'll create a pull request for that branch into whatever destination you ultimately want.

It is stupid easy. So awesome. I mean, it's just great. So real quick, I want to go over the pros and cons of this thing, and then we can elaborate on it. But the cons there, I mean, the pros of this workflow that Microsoft has here, no more merge hell. I mean, you're, like I said, you've really reduced the merging down to just the feature branches back into the develop, um, you know, option or possibly the hot fix back into, uh, the release branch.

But, you know, but those are, those should be small and easy. So you, for the all practical intents and purposes, you purposes, you've removed your merge woes. Like Joe said, you get total control over which commits are going to get merged into which branches. So total power over that type of decision. So if there's maybe a feature or I should say a fix that wasn't applicable to a certain version, but maybe there was something else that was, then you can just pick the commits that you need and, and forget the others. Um, whereas with some of the merging from say a get flow, you know, it's an all or nothing, right? So, um, going back to the use of the tags that

the get workflow, if we're going to like heavily, you know, compare these two against each other, right. Um, get workflow used tags for the versions, but the tags you could often, um, you know, those, those like a commit, they're local to your environment until you push them up, right? So with this workflow, there's no more, oh, I forgot to push the latest tag up. Like that type of issue goes away. works extremely well for large projects and large teams where there's frequent or extremely often, the cadence is high, I should say, on this. It works great for that. It works great for projects where there's multiple versions that need to be supported because it allows you to easily keep those long-lived branches out there

until you no longer need to support it, and then you can just delete the branch. But, you know, as long as you do need to maintain those, you know, as far back as you need to go, if you need to make a change, you can just cherry pick it from the oldest branch all the way up to whatever the latest branch is that you need to support, which could be the latest, you know, your latest master branch. Oh, you know, one thing we didn't really mention, I don't think we really

went into it, the merge hell, is that if you're frequently merging from like Python 3.0 to 3.1, you're going to handle a lot of the same merge conflicts over and over and over again. And that's a big part of the problem because something will have changed and you know you need to keep it, but Git doesn't know that you've already merged this in over and over and over again. And that's a big part of the problem because something will have changed and you know you need to keep it, but Git doesn't know that you've

already merged this in over and over and over again. So you can get in this case where you're just constantly dealing with the same things. And it's a real big pain in the butt. And I wanted to mention too that it seems like you wouldn't want to skip cherry picks that often, but it comes up a surprising number of times

in practice, I think. And what it would be like is you'll have a problem with the feature in an older version. You'll fix that problem. But in the next version, that feature is changed in such a way that the fix either is no longer applicable or actually does more harm than good because now the paradigm has shifted. Now it drives better. And so you don't need that code change at all because it's good. And you're just fixing something in an older version and um i think with uh something like um the gift flow where you're constantly having to merge that in you're just having to deal with the stuff over and over again and um it it makes for some really awkward merge conflicts where you're like you know this isn't a merge conflict as much as it is like

just an incompatibility that i have to code a custom solution to. So it seems like in practice for me, what I've seen that when supporting multiple concurrent releases, these recommendations have worked out really well. I want to add two here. I think I said while I was describing some of the workflow around this Microsoft branching guidance, I might have used the develop as the branch name, but really you don't need the develop branch in this scenario. You can just use master.

So you'll just have everyone developing off of master, creating feature branches off of master and release. You'll have a whole section of release branches. Um, so just to round out the cons here, um, you could easily forget to cherry pick a commit into, you know, any branch, uh, or specific branches that it needs to go into, or maybe it's not that you forgot so much as you didn't even know. So, you know, we said that the pro was you get total control over that, but that's also a big con because in the get workflow scenario, remember I said, no commit is left behind. Right. Um, and, and that's what I was referring to is that here in this scenario, you could easily

forget, you know, to, um, to cherry pick that into a specific branch. Or maybe you didn't know, right? So when would the season to get guru use this particular workflow? And like we said, if you have to support multiple concurrent releases, this is a fantastic workflow for that. Oh, I did want to add too. I, I said that I was a little bit bullish about the commands that this used. And I forgot to mention that at the time that I was specifically referring to the get cherry pick because for a long time there, I just, I just thought of it as a bad, it was more, I viewed it like I viewed your need for doing a cherry pick is more of like, you didn't have a good workflow already lined up. Like you, it was, it was making up for a lack of something. Right. And that if you were doing the merges,

then you didn't need it. Right. And this article that a friend shared with me really changed my view on that. And so now I'm a big fan. So, I mean, just a heads up on this. So we talked about earlier with GitFlow that it wasn't the perfect one for everything. Right. This one, this Microsoft strategy works very well. Like we were trying to use Git flow with multiple versions of a product. And like, it was not uncommon for all of us to be dealing with merge conflicts a good hour to a day. Like it got to the point to where you literally hated

being the guy putting the commit in that needed to go forward a branch somewhere or a version because it was like, man, here we go. You know, here goes two hours of this. And since we switched to this Microsoft pattern, which, by the way, they might have a little bit of experience working with multiple versions of a product. A little bit of experience working with multiple versions of a product a little bit maybe um since we went to this like i i remember that the fear that everybody had was well people are going to forget to cherry pick their commits right that that was the the overarching thing that everybody kept saying well somebody's going to forget and here's the funny part right like anytime something new is introduced you're going to hear a bunch of naysaying because people aren't familiar with it.

They don't know it, whatever. Here's what we found out. First off, that doesn't happen that frequently because when you're working in something, it's fresh on your mind and it's really easy to say, okay, well, this needs to be in version one, one dot one and one dot two. I'm going to go ahead and do those. And like Mike said, if you're using something like Visual Studio Team Services where they have this support baked in for it, after you merge in the first branch, it's like, hey, do you want to cherry pick this to somewhere else?

You click a button, then you choose the branch that you want it to go to. And it's almost like magic. It's kind of ridiculous how easy it is, assuming there's no conflict conflict, but I think that the kind of the, sorry, go ahead. The one last thing with this is while everybody worried about forgetting to take these cherry picks further along, what you eventually find out is you're way sharper on doing those because you're not fighting merge conflicts so much. Because in the previous flow, when we were trying to cram our use cases into GitFlow, you literally spent a third of your day fighting merge conflicts as you merged big older branches

into slightly newer into slightly newer. And it just got ridiculous. So when you go this route, it's so much easier that you're just sharper about getting those things done. So all the concerns we had literally went away. And I'd venture to say, I can't think of the last time since we adopted this strategy that I've heard anybody complain about the problems with merge conflicts. I don't recall any. I think the UI has really been a huge part of that.

I think if people had to use the command line, cause a lot of tools don't have good support for it. I think that might be a different story, but it's so easy in visual studio team services to do that. But I did want to say it to you. Like, I think that part of the reason we haven't seen a lot of problems with it is because you're hyper aware of the branch you're working in like if you have a ticket for uh you

know like a hot fix for some older version like you already have to like no matter what your strategy is you have to know what to check out in order to do that so you have to be on point and correct with where you're starting from and when you're starting with the older branch you're aware of it you've already probably got some special setup type stuff it's you don't forget about that you know right and so i haven't really seen um much of that after that kind of the initial uh kind of bumping the heads on the on the paradigm so i've been really happy with it overall and i also wanted to mention like a good sign that you might want to take a look at the microsoft recommendations is if you've ever created an interstitial branch when you're going from like branch 3.0 to 3.1 and you keep hitting the same merge conflict so many to take a look at the Microsoft recommendations is if you've ever created an interstitial branch.

When you're going from like branch 3.0 to 3.1 and you keep hitting the same merge conflict so many times that someone just finally says, screw it, I'm making a 3.0 to 3.1 branch and I will bring my changes from 3.0 into that branch where I've already resolved those merge conflicts and then we'll move this one to that one and we'll just keep this middle branch and so what happens over time is that you've got you know four or five kind of tags out there and now you've got these branches that are living in between these tags and you've just got an explosion of stuff you're having to manage and it's like this little kind of secret tribal knowledge that there's a secret branch that you can kind of merge to that helps you get your changes where you need them i forgot about about that. That was a real pain. By the way, I don't actually use the visual tools.

I almost exclusively do it all through the command line because it's so easy. I mean, like you said, get cherry picked. I wouldn't say easy. Say what? I wouldn't say easy. No, no, it really is. So, I mean, here's the thing. Like almost all the UIs out there will let you copy the hash for a commit. Like one of the things that initially was a bit of a struggle because I just didn't know how the commit, the get cherry pick worked is if I had three or four commits, like I would try really hard to make sure that I only have one commit Cause it was like, oh man, how am I going to cherry pick multiple?

Well, it's really easy. If you do a get cherry pick hash one or dash X, cause I do the same thing. So it brings along that nice commit message saying that, Hey, it got cherry picked from this branch, but then you can literally just paste multiple hashes after that.

And it'll bring all those commits along in the cherry pick. So it's actually pretty easy. And I started doing it locally because, you know, it seemed like it was hit or miss whether or not if I did it through the UI, it would come back and say, hey, there's a conflict. And I'm like, man, okay, well, I'm going to have to do it locally anyways. So I just got to the point to where I didn't even mess with the UI anymore. I was like, you know what? I know that I need this particular commit or the set of commits in version 1, 1.1, and 1.2. I'll just do it all locally, and then I'll just push up all three branches

and then do pull requests from each one of them, right? So it's not hard. The get cherry pick method is not hard, and it can save you a decent amount of sanity and some hair, which, you know. Yeah, I need all the hair I got. Well, I have a super pro here that I thought of that I didn't put in the notes for this workflow, and that is in the scenarios that you were, you guys were describing where you're trying to use like, and, and I'll say it like you're, you're trying to use

get flow for something that wasn't designed for, right. Um, by trying to support multiple concurrent, uh, released versions like that with those long live branches. Um, well, really it's not even, I wouldn't even say it's a get workflow or get flow. It's kind of like a bastardized version of get flow at that point. But, um, when you do those merges and you hit that merge hell of one old, you, you have, let's say you have three versions, three released versions, plus whatever your current master or develop branches that you're working off of. And you make a fix in, say, version one, and you need to carry that fix over to version two and then version three

and then back into whatever your current master is. When you do that merge and you resolve all these merge conflicts, you're not only like dealing with your own code, but you're quite often like dealing with merge conflicts for code that you don't own either side of. Like when you have a merge conflict in your own code, like you write, you write a commit or you write some code, you commit it, and then you merge in and there's conflicts, at least one side of the conflict, you know, about, right. And then the other thing is something else that somebody else did.

And you, you know, you can try to figure out like, okay, well, you know, I know what's going on here and you have enough context that maybe you can go on without having to work with someone else to figure out what was going on. Or at least maybe you only have like one person to deal with. you more often than not are going to be trying to solve merge conflicts where you are not the author of either side of the conflict that then you're going to go and try to track down. And then you're like, well, wait a minute, who like you guys fight it out. And then, yeah, I'm already in the process of merging this. So I guess just tell me which one to pick or how to merge this and then do it. But in this scenario where you're only cherry picking, then anytime there's a merge conflict, at least you're one of the authors. Yeah, you're at least one half of that. And because you just developed it, you're intimately aware of what you're trying to do.

Yeah. I mean, that's the thing, like going back to the Git flow, what you just said, the version one to version two to version three, that's every single time somebody has a bug fix to version one that has to go all the way up the chain. You fight that same battle every time and you lose your will to live or code or do anything. Another important part of that though, that like, as soon as I said, because you just developed it on it, you're,

you're intimately aware of it. That immediately, immediately sprung into my mind is that when you are going back through the version one to two to three, and you know, you're not the author of either side and you're like, Hey, Alan and Joe,

you guys conflicted on this and now you guys are scratching your head. Cause it could be months ago that you're like, well, I don't know why we did that or who did what for what reason. Like now you two got to like go back and try to remember. Yeah. Well, version one was released in 2016 and customer out there doesn't want to upgrade to version two. So. So, yeah, when you make that change to version one from 2016 now you're having to deal with code that is two years old trying to figure out what what i don't even know

what that did anymore you know so i i can't stress enough like for supporting multiple concurrent releases how much easier this this flow this workflow is yeah man, man. And outlaw's stress levels probably went way down because he's sort of like the get guru that everybody goes to when they have a problem. And prior to adopting this strategy, I'd venture to say that half of his days were filled up with people like, what do I do? I remember that.

It was horrible. Did we save the best for last or is this just the best use case fits this one? I mean, I wasn't trying to do it that way. I did. Okay, let me rephrase. I didn't structure the workflows in that particular order necessarily because I viewed this one as best necessarily, but I wanted to build the story, right? And so I felt like you needed to start with just a plain centralized one because that was just the bare bones simplest scenario and

then start building on that because everything or a lot of workflows build upon the feature branch. So you needed to know that. So it was just coincidental that it worked out is what i'm trying to say yep and to be honest cherry pick is a hard sell as soon as you realize that you could someone could just miss something and you know it's really hard to kind of notice and yeah i think there's some tools and some commands you can kind of run to find that sort of stuff but for the most part it's probably not a mistake and in practice we've seen it work out really well. I also wanted to mention that in the multiple concurrent release world, if you are not doing something like that along the branches, then your automation is kind of in a weird spot. Because if you imagine, you know, like the Orange County public school system is on version 1.1,

but Seminole County is on 1.2 because they needed some new library system or something of your code. And then you check in a fix in 1.1, you move to 1.2. What does your build automation look like for that? Is it looking for a tag to build and commit? Is it looking for, you know, like how do you hook that stuff onto to kind of run your tests and build that stuff for deployment? Like if you've got these long-lived versions, you know, that's a business

use case. That's not a good thing. That's like your business. And so this works out really well for that. And so, you know, like we said, like this isn't like the right way for everybody, but if you've got multiple concurrent releases and you owe it to yourself to check out these recommendations. That's another good point though. Another great way to say that, Joe, is that the workflow that you pick, you need to take a look at how your business works and how your business supports whatever its customers might be. And you need to pick a workflow that supports your customers and the business workflow. Because if it doesn't align, then you're in trouble. Yeah.

And, and that will sort of line up with, I think what you said, the continuous integration, the continuous delivery, right? Like if you need to support five versions of your product, you probably need to do something that makes that pretty painless,

right? Because you don't want to be fighting your, your integration pipeline at all. Or said another way, if you are trying to fool yourself into, well, we will only ever roll forward. But the reality is the business side of the house is like, no, no, no, we support like five versions concurrently. And you're like, no, no, no. We're going to roll forward. We're just always going to roll forward. That's where you're kidding yourself and you're going to set yourself up for disaster. Yeah. Don't fight it. I mean, again, like all of these strategies have a place. Pick the one. And I think we've covered a pretty big

swath of what types of problems you'd face in your source control world. Pick the one that suits your business needs the best, you know? Yeah, absolutely. And, um, uh,

like we've mentioned a couple of links to the show. Um, well, we're going to have a bunch of links there and the resources that we like. That's a really good stuff in there comparing different workflows. And of course we'll have the, uh, the links to the major ones and a couple of those opinions that we mentioned

yep and so with that we'll head into Alan's favorite portion of the show it's the tip of the week yeah baby alright so for my tip of the week I thought I would share

one that I found that I haven't had a need to use it myself. Thank you. So, but it does look like it would be a really cool and helpful resource. So, if you want to ace your next coding interview, you can head to codeprep.io. And here they've got not only challenges, but they've also got like a whole series of interview questions that are, you know, just interesting. Like, for example, if you wanted to see JavaScript questions, you know, one might be, an example

might be, what is hoisting in JavaScript? Provide an example, right? Things like that, like jQuery questions, CSS, HTML questions. jQuery, why jQuery? Don't hate on jQuery. Yeah, I'm leaving the site now. But I mean, they're giving you some examples here, right? So really cool resource. Check it out. Check it out. Dude, what in the world? So if you go there and then you hit the register button, it takes you to an IP address that's not secure. What? I can't, man, I can't believe you didn't vet your tip. That must be a new issue. I think this might just be a bootstrap template.

That's funny. All right, well well that failed go ahead and go register give your username password away well don't use one that you care about never reuse your password we already talked about password managers last episode don't reuse them oh man yeah all right so for mine i totally copped out on this one because my brain was completely fried. So what I did is I went and found like a huge list of get tips. So we'll have a link here. It's github.com slash get dash tips slash tips. And there are so many here that I don't know how many of them are useful.

There's literally so many. Like, I don't know how many of them are useful. There's literally so many. I don't know how you would find. What you need to do is just skim this list. It's almost like documentation for coding for me. If you ever get a third-party API that you're ever working with, do you guys do this? I'll literally skim through it all. Not read it, not try and grok any of it, but just skim through it all so that I'll see the things that are there so that when something comes up later, I'll be like, I saw that. So basically what you're doing is with your mind, you're making an index of the content. So you're like, okay, I don't know what that says, but I know if I need to reference that thing, it's about a third of the way down the page. No, seriously.

It's just that because there are times that you're like, I don't know what I don't know about this thing. So I don't even know what to search for. But if I saw it, then that keyword might jump back out my head. So treat this list like that is what I'm saying. All right. Well, for my tip of the week, Julia, the language, just hit version 1.0, and it's been kind of rising very quickly in, like, the Tyobi indexes, those things that kind of track the most popular languages.

And so I thought it might be an interesting time to go look at this language because people are still kind of building things, converting things for other languages, and just kind of a hot, cool space. And if you haven't looked at the actual syntax, it's actually pretty nice. It reminds you a lot of, like, JavaScript and Ruby and some other dynamic languages, but it's also got some features kind of like Go, and it's really supposed to be good for, like, mathematical and kind of precise mathematics and functional-type stuff, but it just has some really nice conveniences of like a dynamic language.

So it looks pretty cool. And now's the time to get into it if you are looking for something to get into. And it's gaining some popularity in the machine learning world too. Yep. And I guess MIT, it came from MIT, but I guess they're switching over a lot of their stuff. And so they're kind of pushing it because it's supposed to be easy to use, like Python or JavaScript. It's supposed to be precise,

like, you know, like a I guess, like a functional, I don't know, language that's precise, like Prolog, or what's the one I'm thinking of? Haskell? Not Haskell. What's the old school, like Fortran, is what I was thinking. Fortran, which is still kind of popular,

and like R, it's got some nice stuff for doing like cool mathematics type stuff. That's what I was thinking. Fortran, which is still kind of popular and like R, it's got some nice stuff for doing like cool mathematics type stuff. It's got multiple return types like Go and so it just looks nice. It's got options for types. Am I the only one

that was hoping that we would like just randomly, continue to randomly throw out programming languages until Joe was like, that's the one. Like that ended

a little too quick. Loose. Very nice. But yeah, check it out. That's our new Coding Blocks catchphrase. Codingblocks.net. Check it out. Alright, so with that,

subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. And as Joe mentioned earlier, if you haven't already, we would greatly appreciate if you left us a review. You can find some helpful links at www.codingblocks.net slash review. And don't be afraid to tell a friend. That's right. And while you're up there on the site, check out all our show notes examples discussions and more and send your feedback questions and rants to the slack channel

at codingbox.slack.com you can sign up for it at codingbox.net slash slack and make sure to follow us on Instagram and snapshot and was it elephant mastodon and instabook facegram

there we go yeah uh tweet in yeah if you just go to the cutting box like that and look at the top of the page we got links to uh all sorts of stuff so we can interact uh wherever you probably feel like interacting yeah link plus uh google in we're out we're there. Google in. The snapshot.