 All right, so my name is Micah and I am going to be talking about working with version control today. So if you have any questions or specific things that you would like to hear more about. I know we haven't covered anything yet, but it's always good to get a general idea of kind of what people are expecting to get out of this. The chat is the place to do that. So if you want to go ahead and just post, you know, maybe what you're expecting this to be today. If I need to, I could potentially adapt it a little bit. But, but yeah, generally the chat is the place you'll go to ask questions as we go through. I've got the chat open on another screen so I'll try to keep an eye on that. Well, we go through the slides and then go from there. So yeah, and so as far as working as a solo developer with version control. A lot of my talking points are kind of in that direction because that's where I was when I started working with version control. So hopefully hopefully we cover that well enough. Let's see. Yeah, so we do have some best practices that we'll be covering. And then of course for those that have no idea what it is, we will introduce the concepts and even do a little bit of a demo. I think here in the middle of our middle of the talk. So, and we do cover multiple workflows and kind of the pros and cons of, of what those are. So that's looks like everything that's been mentioned so far is, is in the, in the queue. So hopefully, hopefully this should be pretty on. So, like I said, my name is Micah. I'm a WordPress developer at Bluehost, and you can basically Google WP scholar to find me online. Everything from my website to Twitter to word camp talks and everything in between. So, a few things we will kind of hit on from like a definition standpoint just to make sure it's clear what we're talking about and some of the tools that we're referencing. So version control in general is basically the practice of using particular software to track and manage changes that you make to your code. So, so that's the idea of version control is just being able to track these changes right. So, one of the tools that we used to do that is something called get get is an industry standard tool or version control. It is a CLI tool. And it is also a free and completely open source tool as well. So that is has a lot to do with why it's an industry standard, but ultimately get is what most developers are going to use when you talk about version control there are other conversion control systems, particularly if you do WordPress core work on WordPress plugins you will probably encounter SVN. But we won't really hit on the specifics of that, but the concepts that we cover as far as version control will basically apply to any other system. And then we have something called get hub. So if you're using get get hub is a cloud based service where we as developers can store manage and share code. And we'll talk a little bit more about how that works. But ultimately, you know, get and get hub are kind of the tools that we're going to be using. And like I said, get is a CLI tool. And for those who want to follow along later with our demo. If you want to go ahead and download. There's a tool called source tree, which is a free cross platform tool that you can use which gives you a good UI. GitHub has its own tool. I'm not a huge fan of it. I prefer source tree. But there are plenty of tools out there that you can use for version control. I want to make sure that you're aware, but I'll be using source tree and thank you Michael for posting the link for that in the chat. Yeah, and CLI stands for command line interface so if that's not clear to anybody. That basically means you'll go into the terminal and your computer and be able to type commands. So if you're first learning get, get slash version control, you'll want to have a UI tool that you can use for that. So why should we use version control. So first of all, you can track changes in your project. There's a way to keep track of every change that happens, or at least the important ones. There are kind of some ways to kind of clean up the history a little bit. But ultimately it's a way for you to keep track of those changes. If you're an individual developer. This is good just because you can see every little change that you made and when you made it. Another thing about being a solo developer. I mean, obviously this works with teams as well but is the ability to undo a specific change or roll back to a certain point at any given time. So you can basically say, Oh, there's a bug. Let me undo the last change. See if that particular state of the application works. You can undo some more you can roll back and roll forward and kind of jump around until you figure out where where that issue came from. It kind of serves as a code backup as well gives you a safe clean copy of all the code that you touch. So if something gets hacked, you know that you have a clean copy of it in your repository, essentially. It gives you the ability to try new things. So basically you're able to create deviations of the stable code. Just to try stuff just to see if it works if it works, you can run with that code if it doesn't work you can trash it and it won't impact your production code. As we mentioned, it helps you to find breakages. So if you do have bugs that sneak in a lot of times we don't notice them right away sometimes bugs can linger in our code for weeks or months. And being able to, like I said, roll back to a pretty good point and and find when that bug didn't exist or, you know, when it was fixed maybe it was broken again who knows. And then teamwork right so we have version control is going to make it easy for you to work with a team of people who might actually edit the same files without having to worry about losing your work. So, unfortunately, there are still web agencies out there that don't actually use version control will jump into the server and change files on the live site and it makes me cringe but you know all it takes is two people changing the same file and you trash the other person's work. So with version control that kind of thing doesn't happen. And that's also why I tell people if you have a developer that doesn't use version control finding a developer, because I think everyone should be using version control. But even if you are just a one person working on a project, you might have multiple computers, maybe you have your desktop computer you have a laptop that you travel with or whatever the case may be, you can actually makes it easy to work across those multiple, multiple computers. And there's still plenty of benefit, even if you just use a single computer and do all your work, being able to track all those changes across the project. So version, version control lets you do code reviews. So you can have someone else look at your code. However, I even review my own code by creating PRs on my own repositories and, you know, sleep on it come back the next day look at it with fresh eyes and kind of do my own code review in that way. The other thing that's great is version control you can actually integrate it with different deployment tools, and that can help you streamline your code deployment and basically prevent human error. It is very easy to make a mistake in deployments. And so having that automated will save you not just a bunch of time but a bunch of potential heartache had something go wrong. So, so that's why we should use it we're going to take a look now at some of the basic concepts so. So the first concept or idea behind version control is we have what is called a repository. Also, shorthand repo. It's nothing more than an instance of the project that's stored either on your local computer or remotely on some service like GitHub. So it contains a collection of all the changes that you've made on the project you can think of it as a database of changes right that lives in a particular location. So then we have what we call cloning so cloning is when you basically copy a repository from one place to another, typically you're copying from a remote repository from a place like GitHub to your local machine. So that clone, it's grabbing it from this particular location and pulling it to your local computer. And then we have what we call a commit so commit is when you've made some code change on your local machine, and you want to basically store that change into this database into this repository. So you will, you know, you can commit an individual file you can commit individual lines of code, but ultimately you'll select the files or lines of code that you want in the commit. And then you can leave a commit message, basically saying you know I changed this because blah blah blah, and then you can make that commit and that basically gets stored into this repository. And then, so we've made a change on our local right so we have a local copy of our repository that we've copied from say GitHub. So we've made a change we've done a commit. And now we want to take the changes that we've made locally and push them up to our remote repository on a service like get up. So pushing is nothing more than saying hey, here's all the stuff I've changed. I'm going to send it up to the remote repository where it's then able to be shared with other developers or you know code reviews and things like that can happen. And then we have the pool right so if somebody else has made changes, maybe you're on vacation and now you're back and there's been a bunch of changes you need to pull those things down. So pulling is nothing more than grabbing whatever those changes are from the remote repository and pulling them down. Ideally when you pull code you should do that on a regular basis. So you don't want to be waiting weeks at a time to pull code down and then realize that you have, you know, very different. The more changes that happen that you have to reconcile the more of a beast it is to kind of deal with those particular those conflicts so the more often that you can pull the code in and deal with things at a smaller scale gets to be a lot easier. So you do want to pull code. You know, at least once a day in my opinion. Then we have what we call branches so branches allow you to basically create a divergence from the production version of the code. And they are usually created so that you can create a new feature or fix a particular bug. And the idea is that you create this branch you do your work and then when it's done, you'll essentially merge it back into the production code. So merging is the act of combining two different branches into a single branch and may also require reconciling any conflicting changes. So like I said, if someone hasn't changed the same files, then there's probably no conflict. But if two people touch the same file, particularly the same line inside of the same file, you're going to have some sort of merge conflict so you'll have to kind of deal with that. And then we have what's called a pull request so pull request is essentially an event where a contributor will ask a maintainer of a repository to review code right. So, if I wanted to, for example, contribute to the Gutenberg project for the WordPress editor that lives on GitHub. I would have to create a copy or a fork of the Gutenberg repository. I would then loan a copy of my fork, which would live on GitHub to my local computer. I would then make my changes, commit them, push them up, they would now live in my fork or my copy on GitHub. And then I have to find a way to get that from my fork into the original repo that WordPress manages. In that case, I'd create a pull request from my fork or copy of repo to the WordPress Gutenberg project. And then if that is approved, that would get merged essentially into the WordPress Gutenberg project, and then I will have contributed to the project. We'll look more, we have some visuals for this later, but just as an example of how you might use a pull request. And then we have what are called tags. These are basically just labels that you assign to a specific commit in the repositories history. And they basically can be used for anything really, but usually are used to tag specific versions. So if you're doing a release for version 1.0.0 and then 1.0.1 and so on. Those are the kinds of tags that you might use for saying, hey, you know this commit marks the end of version X. So that is what those would normally be used for. And GitHub actually has a concept of a release, which is associated with a tag. So tagging is a fine way of indicating where a version lives or what commit makes up that version. But it's better if you're using GitHub to actually do a release and associate it with a version tag because you get a few other things with that. But anyway, so we're going to run through a little bit of a demo. So let me see here. So this is source tree. Hopefully everybody can see that and it's not too small. I know I have a big screen. So, so what we're going to do, we're going to say new, we're going to do. Sorry, Michael. Yeah, I mean, sorry, Micah, is there a way for you to enlarge even more because it's filling part of the screen. Yeah, I can make it all the way big, but I don't know that's going to make any of the text bigger. I think it's probably more helpful this way. So, yeah, so this is the source tree. When you first open it up, you'll have kind of this panel. And then, you know, you can, you can do a number of things. So here we say I want to create a new, you can create a new repository on your local machine. You can create a new repository remotely. I think you do have to link this up to your GitHub for that to work. And you can also clone from a URL. So, before we get into that, I'm going to jump back into my, where my browser tab went. Okay, I lost it when I was doing this here. Hold on. Where did my, where did my browser tag go? All right, well, open a new one, I guess. Let's see, surely it's in here somewhere. Oh, there it is. Okay. I was just in full screen mode here, I think. Okay. So I'm going to go to github.com. That's my GitHub. And we're going to find a repository that is called Hello World. Hello. So this is kind of the repository I used to test all kinds of stuff. So there's stuff in here and nothing important. So if you want to create a new repository, you would, you know, you'd need to have an account with GitHub, so you have to sign up. And then you would be able to come over here and say new repository. And then that would take you to a screen where you give it a name. You can make it public or private. I think if you can't remember, you may have to have a paid account to do private repos, but public repos are free. But anyway, so if you want to create a new repository, that's how you go about doing it. Mainly just give it a name and hit create. In this case, we have a repository. It's got some code in it. So we're going to run this. So if you have an existing repository, you'll be able to click this code button, and it will give you a URL. Similarly, you have two options. You have the clone with HTTPS and clone with SSH. So HTTPS works fine. The only thing there is if you clone with that, every time you make a commit or try to do a push or a pull or a fetch or all the different things that you need to do. It'll make you type in a password. A source tree can remember your passwords for you. So there's that. But in my opinion, I prefer SSH, which does require a little bit of extra setup. So you would have to set up some SSH keys on your local computer, and then you would have to upload your public key to the GitHub settings. I'm not really going to get into all that because it's not really specific to version control directly. Although it is something that you'll probably want to do. This basically means that you have some SSH keys on your machine. And anytime you run a command against a Git repo, it just works. No password required. And you can run with that. So we're just going to copy the SSH URL since I already have that set up. We're going to jump back over to source tree. And we're going to create a new repository, but we're going to, so we're going to clone from a URL. And so we're going to say, okay, this is the source URL. And we're going to call this hello world. And it's just going to go into our user directory here. So this kind of does all that automatically for us. You can change it if you like. There's a little dot dot dot icon to the right, which will let you go find the folder that you want to put it in or things like that. So we'll hit clone. And this will create a copy of that on your machine. So you can see kind of opened up a new window here. And this window has a bunch of stuff in here. We'll go ahead and say, as a best practice, if you make a code change, the word test is a really bad description of that. But again, this is just me playing around and testing random stuff that no one's really supposed to see. But it's also, we're going to use it as an example of what you shouldn't do. Okay, so what we're going to do now is we're going to kind of go through some of the actions that you might normally do with a repository, right? So visually, you can see we have something called a master branch. Now, technically, this is a much older repo, but a lot of the newer repositories that I create actually use main as the main branch, whereas master is kind of the traditional name. It does have some negative connotations. So GitHub has kind of been moving towards having main as the default branch name. But if you do see master main or even trunk, those are usually kind of the same thing. They usually indicate the primary branch of code that would represent where all of the production code would live. So let's say we wanted to do some work here. So, as an individual developer, you can see I've literally just made a change, committed, made a change, committed, made a change, committed. But anytime I could, I could double click here, and it'll say, are you sure you want to change to this copy of the code? Hit OK. And boom, you are at this state of the code instead of way up here. So any of these changes, they don't exist right now in the code that I have. So let me do this just so we have a reference here. So this is, so you hit the terminal button. I'll let me do that again just for anybody who missed it. So in Source Tree, there's a button here for terminal. You can click that. It opens your terminal. If you do want to run some CLI commands, get commands, you can do that. You can always do things like get status and it'll tell you, you know, the current state of things, if there's files that have changes, those kinds of things. So colored things at the top of the tags. Yeah, so the question was, what are these these colorful things up here? So the branches will get different colors. And this is actually the red thing that forks off here is actually a separate branch. So we have different colors. These things here, these are tags essentially. Well, kind of. We're essentially any tags that we add will look like this. But these right now are representing the state of master branch. So if you see origin slash master origin represents the original source of the code, which is actually on GitHub. And then if it just says master that represents the local version of the code. So master on remote and master on local match up. And so this is, and then we have this special thing called head. So we have origin head, which is the current state of the code. And as you can see, our local head is now in a different state from origin head. So hopefully that makes a little bit, a little bit more sense. But yes, if I had tagged say a 1.0 version here, you might, you would see something colorful like this and say 1.0. And those, yeah, the colorful things they're all added by source tree. So we'll, we'll get into tagging a little bit more here in a second. But I do want to pull this one up. I'm just going to do open dots, that's going to open my finder window to here. So this is the code that lives in this repository. So source tree has this really cool thing where you can actually, if you set it up, you can actually type S tree space dot and it opens up from terminal directly into here. So open dot, it'll open from terminal into your folder. And then let's see what was I trying to do here. Oh yeah, and then code space dot if you use VS code will actually open it into code so it's kind of a nice little shortcut because you can always hit the terminal button from source tree, which you can then access the finder or VS code directly. So this is our code in VS code that just opened up so we can see we have a Hello World file. And apparently haven't updated that in a few years, a copy right here. So let's just say we want to change some stuff. But before we do that, like I said, we've got a lot of files, a lot of files going, windows going on. So we're going to jump back up here to, I'm just going to double click over here on the left where it says master. And that will switch us back to the master branch. So this puts us here so you'll notice that the bold text indicates kind of what commit you're on. And this is the one here. So let's see if the copyright change copyright didn't change. So let's say hey, we want to change the copyright. We're going to come in here and we say okay 2022. Obviously that's not the current year but we're just going to go around a little bit. So I'm going to save that. And then we're going to switch back over to source tree. As you can see we have this thing that says uncommitted changes. And we have a little gray line here. I'm going to click to file status. And this will show us any file changes that have happened. We have the world PHP. And we have this copyright change. So to commit this code, because this code isn't saved in the repository at all until we commit. So we have to select the code that we want to commit. And then we have to add some sort of message of the copyright. And then we'll hit commit. Now as you can see we have this little arrow pointing up with the one basically it's saying hey, your master branch is one ahead from the origin master so this is the node here. And we follow that up to here we can see that we're one ahead on our local so in order to get that bit of code up here. So let's open up this hello world PHP on GitHub. As you can see here we have the old 2021 still here even though we just changed it and committed it. We haven't pushed that code to get up so to do that will hit the push button. And we will, you know, we have origin, which is going to be our GitHub URL you can kind of see it maybe faintly here. So we're just going to go to master branch, or from our local master branch to the remote master branch you can actually change these things around but typically they should match up. So we're just going to hit okay. So that's pushing it up to GitHub so now if I were to refresh this on GitHub, we should see. There we go. A new 2022 year. So let's see the source tree a tool instead of or an addition to VS code. I would say it is an addition to so typically you'll have your code editor, and then you'll have a way to manage your version control. You could do like I said you can do it from the terminal, but you have to be really good with knowing and formulating the commands for all of that. So the source tree would be the visual tool that I think makes makes it much easier to work with version control. So we've seen the idea of slowning a repo. So we pulled the repo down from GitHub to our machine. We've made some changes we've done a commit. We've pushed back up to GitHub. Yeah, maybe a couple of other workflow items here real quick. So let's say that this update copyright represents a version 1.0 of our application. So what we could do is we can right click here and we can hit tag and tag. We can give it a name so we can say 1.0.0. And then, yeah, so VS code, source tree, GitHub, all those three things combined. Yeah, they were they they're definitely a good pairing together. So we hit. Well, let's see we want to push this tag so we can create a tag that only lives on our local copy. But I'm going to check this so that it makes sure to get the tag up to GitHub at the same time that we had it. So we're going to add. And as you can see, we have a new. And like I said, I'm not really sure how to make this text actually bigger, but we're seeing a 1.0.0 tag here in the blue. So if we were to go over to GitHub. Just go back to the main main section here so we have five branches 50 tags now technically I've made many tags. So I don't know if 1.0.0 is duplication. I don't think it would let me create two tags with the same name. But as you can see, I have two tags that I've created in the past, but none was 1.0.0. I created a 1.0. So, yeah, so the concept of tagging is just to kind of bookmark a specific state of the code so that you can get back to it. So for versions, it makes a lot of sense to say hey version one is this version two is that. You might have 100 commits in a single. Essentially what you call a release right so any, any changes you made since version one. You can have multiple commits before version two right. So in this case. You know you can also go to GitHub and create a release and a release usually will create a tag as well so we can say we wanted to do a release for the 1.0.0 tag that already exists. Call it the version 1.0.0. So this would be a way that you would actually do a release. If a tag didn't exist, you could do a release and it would create the tag so that's just another way of essentially doing the same thing generally the reason you would tag a version is so that if you're using a tool like Composer or if you're for PHP or NPM for JavaScript, creating a version will allow you to pull that code into other things. So committing is very different from tagging committing is more of the day to day action. Tagging is more of a, we're ready to release something we should tag a version of the code. So, let's take a look here at a slightly different workflow. So let's say hey we want to create a new feature. Let's create a branch someone click the. Let's just click this branch button, and that's going to say hey let's create a new branch we just got to give it a name. I like to use a. Well, there's something called get flow and there's kind of a naming and within Source Tree, if you name the branch a particular way, it'll actually create nested folders for you. So I can call I can create a branch and just give it a name like test or something right. And that that would be fine, but in this case we're going to say update slash, and we'll call it copyright. So we're going to treat the copyright update as a feature in this case, and it creates a branch and as you can see, we have an update folder now with copyright inside because we named it update slash copyright. It creates a folder and so it just gives it an easy way to find things and collapse things down. Usually I'll follow a convention of saying update slash try slash add slash fix slash things like that. So, you can kind of classify things that are that are enhancements versus bug fixes versus just experiments. So what we're going to do now is so we are on this copyright branch so let's go edit our code again so I'm going to switch back to VS code here. We're going to change this to the correct year so we're going to change this from 2022 to 2023. And we'll save that. And then we'll jump back over to Source Tree here. So we can see we have uncommitted changes. We come to file status. And again we have this hello world file with a copyright changing from 2022 to 2023. So we're going to check that. And we're going to commit it. So we're going to say update copy rights again in this scenario. Alright, so we're going to commit that change. Right now we can we can make multiple changes. So let's say oh shoot you know we forgot to change this version number. Maybe this version number should be 1.3.0. And of course we have that in two places here so we'll update that. So then we come back to Source Tree. You know we've got some more changes. So we're just going to call this bump version. And so that'll add these changes here. Now if I wanted to I could do one line of code at a time. So this is un-staged. This is staged. We've staged a single line of code in the same file and decided that we're not going to stage this one. In this scenario they they're related changes so we'll keep them together. But you do have the option of selecting specific lines of code in a file. So we'll do a commit. We bumped the version. So now we've made two commits. So if we come back to the copyright branch we can see okay from 1.0.0 we made a copyright change and then we bumped a version and that's the current state of our code. So again we're working on a branch so this branch is called update slash copyright. So if I were to do a push it would say well what do you want to push. I want to push the update slash copyright to origin which is the GitHub copy of that. So we're going to push it to update copyright on the remote branch. Hit okay. So what that will do is that will create a new branch and it even tells you here as I load GitHub backup update slash copyright add recent pushes less than a minute ago. So if I'm looking at the list of branches. You can see we have the master branch we have this update slash copyright branch. If I wanted to see the state of code in this branch I could click on this. And it would show me the state of the code for this branch which includes the version bump that we did to 1.3.0. So I went to the repo and I'm looking at the state of the master branch, and I go into the hello world file. We're not going to see the recent version number or copyright because that's on a. It's not in the production code yet. Right. So we've created a divergence from the production code that lives in its own little isolated location. With that being the case. We will, and I'll get that question here in just a second. So with that being the case this, we want to do what we call pull request so the pull request is again a tool that we use to do code review, and I like to use them to code review myself, even if I'm not working with a team on something. So here. Now I've said stuff that it pre populates a lot of stuff you'll probably come in when you create your request and look more like this. But you'll say, you know, maybe prep for version 2.0 or something be whatever you want to call it. And so you can say, well, hey, you know, I updated the copyright updated version numbers. So those are the things that we did. If you're working with a team, you can even say, hey, I want to pick some people here to review my code. You can assign this to yourself. You can add some labels. So you say, hey, this was an enhancement, for example. But ultimately, it'll show us, you know, here's all the changes that are different from what's on the master or production branch of the code. So this shows us all of those changes. So when we create the pull request. What it will do is look something like this. And so it'll, it'll give you a place where you can have some conversations. It will show you the specific commits that happened. If there's any checks. There's something called get up actions. It's really nice, but we're not going to get into that. It can run checks. And then we have the code you can see the specific files and things that were changed. So let's say we were doing a code review. We pop in here and say, hey, you know, at a peace caller. That's me. Are we sure this is the right year. You've changed this a few times, right. So we can start a review. And then, you know, when we're done, we can finish that review and we can say, okay, well, we, we have some changes or this is just a comment. And so that makes it easy for you to interact with other people, whether they're on your team or they're just people on the internet that you said, hey, can you come look at my thing. So if you're learning code, you can you can use PRs for having a mentor look at your code or things like that. So that's just a few quick things that you can do with the code. So let's actually jump back to the slide deck here and kind of talk a little bit more about, you know, when do you create a branch, what are the workflows look like some of that kind of stuff so typically when you create a new branch, the idea is that you're working on a new feature or you're trying to fix a specific bug. So you might branch and you say, oh, I'm going to fix this bug and then you realize it's a one line change. So your branch only has one line changed in your code. And that's fine. Somebody could review that. But it's also possible you're working on a new feature and there's hundreds of lines of code that are are changing. And at some point you're going to need to get that back into the main production branch. But, you know, you might want to code review before that happens right because when you're changing lots of code it's easy to miss stuff and it's always it better to have a two sets of eyes. But we're going to kind of talk through just some of the workflows that you might actually use. So this is what I call a basic workflow. It's where most people start when they first use version control. All the commits are made to the main branch as you saw I had that very straight line and source tree of all the things that I had done. So, anything that's changed upstream a lot of times it gets ignored until you are trying to push stuff up and you realize that you didn't pull other people stuff down. If that's the case. Sometimes it happens when you're working across multiple computers right you made some changes here and then you made some changes there and then realize you forgot to pull the changes that you had made from the other computer. So, but ultimately you're just working in a very straight line fashion so your your branch changes are going to look like this you're not really creating separate branches you're working on one branch, and you're committing in a very serialized fashion. So the pros of this is it's easy to understand it's really great for small projects. And you know it works with teams as well. As long as there's not too much activity, the more activity that you get on a repository than the more conflicts and and the more this this approach is not really ideal. So, if you're first starting out. You know, you don't need to do anything super special. The most important thing is you track the individual changes, you have the ability to roll back, and you're learning about version control. As you, whoops, guess I should be in slideshow mode here. So then as you're kind of advancing a little bit scaling up with the team or whatever the case may be. So you can start to change things a little bit so we have what we call the feature branch workflow. And so this is where we're talking about the whole idea of creating a new branch when you're working on something new. Whether that's a new feature or fixing a bug, you'll create a branch for each of those things individually. So, this is where we have our master branch and we have commits and things happening here. But you can see that we're taking a feature here, working on it. So very easy thing to work on maybe a one line bug fix. And then eventually that goes back up into master. And maybe somebody else had some other thing that came in during that time, maybe they were working on some other feature and it got, you know, bumped into this dot. But at some point, you know, that feature will merge back in. And of course you can have, you know, a longer term feature or something that's going to take a while. And it could go, I don't know hundreds of commits, and then eventually make it back up into master. So this is a basic feature branch workflow where you're creating a branch for a specific purpose. And then when that purpose has been served, it gets merged back into the main or master branch. So pros and cons of this, the whole idea there is that the main branch represents your production code production ready code so at any given time, you should be able to deploy what is in the master branch at any state. Everything should work and nothing should be broken by doing all of your feature work and your bug fixes and things in their own branches. By the time that comes back around to the main production branch, it will be production ready. And then the other nice thing about the feature branch workflow is that it really helps with collaboration and code review, right? Because now you're actually able to use the branch that you created to create a whole request on GitHub. Somebody can then go in and comment and go back and forth with comments on the code. And then if things need to change before they finally get merged in, you know, all those things can happen. The big con here is that the longer the branch goes before it gets merged back in. So if there's a lot of activity on master branch, there's a lot of activity on your feature branch, and then you have been working on it for three months, and then you decide to merge it in. It's going to be a little bit of work to deal with all the potential conflicts. I have a question here. When working on a feature branch, how do you handle changes to the main branch? Would you incorporate the main branch changes into your feature branch? And the answer there is yes, right? So at any given time, let's say I'm working on this feature branch here, this little blue one. You know, on a daily basis, I should really be pulling master branch into my feature branch. So if you're following that, then you're kind of eliminating the con here of having two branches that are going for quite a while without any, any migration along the way. But if you're properly pulling from master into your feature branch and dealing with conflicts as they arise on a daily basis, even if it takes six months to work on your feature, by the time you're ready to merge it back into master, it shouldn't be a big deal, because you've been handling those changes. So then we have something called get flow, which is a much more advanced workflow works. It's better if you have like maybe a bigger team or something like that. You could do it as an individual but it's probably overkill. A feature branch workflow is probably a nice advanced workflow for someone who's a solo developer. But if you're working with a team or you're handling like releases and things like that on a regular basis, this would probably make a lot more sense. So basically, it assigns very specific roles to different branches and defines how and when those things should interact. And what we mean is this. So, you have the master or main production branch, which is what's represented by that the line there has the blue dots on it. We have a hot fixes branch, which would represent any time that something needs to happen fast to fix something, you know, we accidentally deployed a change and it broke something and we need to fix it. You know, we need to get that fixed, right? So we would create a hot fix branch, we make the change and merge it right back into master. And then, you know, we'd get that fixed. But most of the time if you're doing development because again master should always be production ready to be stable it should be free from error, as much as possible. That's the line that has all the yellow dots. You can see there's a lot more activity on the develop branch. This is where people are, you know, merging code into and everything kind of goes on develop branch. And then it gets tested and then when that develop branch you're like maybe we're ready to do a release. It'll go into a release branch where it can then be, you know, development can continue. And nothing's going to impact the potential upcoming release. So you can kind of solidify that, and then it can go to master. Yeah, so then we have, you know, of course the normal feature branches and things like that that would come off of that. So, like I said, a lot more advanced, but makes a lot of sense as your team gets bigger as you have more, you know, if you're really doing releases versus maybe like pushing changes to a one off website. If you're actually working on a product this will this would make more sense. So, in this case the main branch, like we said is stable. We get the benefits of being able to collaborate well with pull requests. It's great for frequent releases teams can work on specific parts of the code independently without having to worry too much about conflicts. If you have to support multiple versions concurrently. If it's not going to be done. It's just not exactly built in to this. But it wouldn't be too complicated to do so what I mean by multiple versions concurrently. If you have like a 1.0 version. Maybe it only works on PHP seven and maybe a 2.0 version only works on version eight, and you're trying to support them both for a while so that things can work for both versions, but they have to be a little You know something like that is what we're talking about with the con that And then we kind of demoed this but the fork and merge where a developer would create their own copy of a repository there's two ways of doing pull requests by the way. You can do a pull request from from the same repository which is what I gave an example of earlier, or you can create a copy of a repository. Which is the example I gave of Gutenberg earlier where if you were to make a copy of or a fork of Gutenberg, what a fork is what they call copying an existing original code base on GitHub. So you can you can kind of go two ways with this but the fork and merge is usually more of the open source approach where you've got one repository, and this represents that repositories code. And then you end up creating a copy of the repository, which essentially serves as a feature branch, and then when you're done making your changes, you do a pull request from your repository to the original repository. And that will essentially apply those changes so. So cloning is making a local copy of a repository, which is usually your own repository that you have access to forking is basically going into to let me give a more solid example here forking is where you would say okay let's go to Let's come over here we'll go to WordPress slash Gutenberg, and I'm going to create it actually has a button here says fork, you can click fork, and it will say, let's say this will be a say blue host or whatever so you are actually already have a copy of it but So you could say, well, you know, we're going to make a copy of the Gutenberg repo, and then go from there. So that's the idea of a fork. So the idea there is, and let's take a closer look at this. The idea here is the primary repository stays clean. It's also stays separate and, you know, no one that you don't want to make changes will make changes to your code. But it is publicly accessible, and other people can contribute and assuming you accept those contributions, then the code can be added to the code base. So primary repo stays clean limits to your right access. You still have that collaboration ability. So that's why, again, it's great for open source. It is a little bit more work and a slightly more complicated so you do have to understand a few more things before you kind of get into that workflow. But, but again, so I think you just kind of have to take it one step at a time if you're just starting out, start with a basic workflow. If you want to contribute to an open source project, learn the fork and merge workflow. If you want to learn a more advanced solo developer workflow, the feature branch workflow works great. If you have a team and you're doing product work and you're doing releases and things like that, then the get flow is a good workflow. So, I think we're almost out of time but there's just a few quick best practices here that I want to run through. And we will end it with that. So, for best practices. If you're doing a commit. Make sure that your commit makes logical sense right so you don't want to be committing. Oh yeah this line of that and that line of this and they're all random different changes but we're going to mash them all in there together anyway. Keep them separate keep them logical. Like I did with a commit for version changes, which was multiple lines, and then maybe a commit for the year change, different things like that. You want to keep your commit small and incremental as possible. It's going to make it easier to kind of track track changes, especially if you're a new developer, those little changes. If you get too carried away trying to make bigger changes and you don't commit frequently, you will completely break things and and you won't be able to figure out why. And you want to make sure the commit messages are descriptive don't just say test or updated or change something. Make sure you say, you know, what it is that you changed. If you're creating a branch, you want to create a branch for every feature big feature that you do, which again could also be bug fix when you're done merging that it's to keep things nice and clean, you want to delete the branch when you're done. And then again make sure that the main branch is for your stable production code only for tagging releases typically are what you're using tags for, and you should be using semantic versioning if you're not familiar with that. You should look it up there's an entire website dedicated to semantic version. I believe it's simver.org. So pull requests so pull requests are where other people will be looking at your code most likely before it gets merged in. Just to avoid mental fatigue, you should try to limit the amount of code being reviewed at any given time to 200 lines of code. If that means you need to create a branch for your feature. And then, like an integration branch that occasionally you say hey I've made some more changes I'm not done yet but I want you to look at them. I want you to be able to piecemeal and make those things a little smaller. But again, pull requests can be created across branches or or repositories. But they should be created only for code that's actually ready to be merged if it's not ready to be merged there is something called a draft pull request that that would be the way to do that. Refactoring. If you're renaming and moving files around. You should do that in its own pull request if you're reformatting code, you should do that in its own pull request. If you do that in conjunction with actual code changes. It gets very hard for somebody doing a code review to identify the actual lines of code that were changed versus just everything having different indentation or files getting renamed and stuff like that. If you have dependencies don't version control those you do want to track the dependency versions but maybe not the actual code that itself. This is what tools like composer or for is to be able to track dependencies so learning about composer and then how to exclude something from a get repository so we take a quick peak here at the. The code here so we have a dot get ignore file. The dot get ignore file take a file name or a path. And that will make sure that those things don't end up in the repository itself. They may exist in the file structure, but they won't be added to the repository. All right, so switching switch back here. And likewise with files that are generated so let's say you're using sats and you're generating CSS files. You don't actually want to commit to CSS files just the SAS files. And then ideally you'll have some sort of build process when you deploy the code that will generate those files for you. The branch names to be descriptive. This is kind of an example of how I like to prefix things to add a new feature to update or maybe do a bug fix, or to try something as an experiment. And then finally, requiring, let's see. So PRs to merge into the main branch. So you can you can set up restrictions on GitHub, where somebody can just push directly to the production branch. So to enforce a better workflow where someone is required to open a PR first, and then to have that approved and then merged, which typically you can set up some workflows as well where if a PR is opened, all requests is opened. It will run some automated tests or something like that to validate that things aren't broken. That introduces a much better workflow than having a few people who are like willy nilly hey I'll just commit this to our production code without actually having anybody look at it or that kind of thing. And lastly, you want to make sure that you clearly document how your team uses get. With these list of best best practices, you know, clearly outlining what your expectations are around that helps everybody to to work together in a reasonable fashion. So here's a few resources, I will, by the way, I will post the link to the slides on the meetup page in the comment section after this but so as we mentioned we've got get GitHub. There's also something called GitHub CLI not to be confused with the Git CLI, which is what it is. GitHub CLI actually allows you to do things like create pull requests from the CLI, which is not normally something you can do, but if you really love command line, you can do it. Source tree, which is the graphical tool that we've been using. And this link actually has a bunch of other links on it. So if you don't use version control and I picked your interest and you want to learn more, there's entire tutorials and walkthroughs and classes and things like that that are actually at this link. And there's a link here that kind of goes through some of the workflows we talked about in a little more detail. So the flow specifically the original posts from the guy who kind of came up with it. And something called get bisect which is also a really cool way of having some automated ways of jumping around the code to figure out where bugs exist so something we didn't have time for today but definitely worth looking into. With that, I think we are basically done because that was a lot but if anybody does have questions feel free to ping me on Twitter at WP scholar or you can go to WPscholar.com and submit a question through a contact form. I do appreciate everybody who can make it. And yeah, like I said, I'll post the slides.