 All right, my name is Evan, like she said. I wanted to talk about kind of dev team workflow and processes, because that's kind of something that it's kind of hard to find and you don't know about it unless you actually do it sometimes. So getting started was kind of confusing and hard for me, so I wanted to talk about it just to give some people some ideas, things to work through. Oh, yeah, and I'm Evan Mullins, like she said. I've been using WordPress since 2006 and building for WordPress full-time since 2007. I'm a senior front-end engineer at TenUp. It's a WordPress-centric agency. And I've been there about three weeks, or almost a month. So when I wrote most of this talk, I wasn't at TenUp, so that's a little disclaimer. So I tried to update it with some things that TenUp does. It's kind of an interesting situation because I had one process. My last company I was at was Brownback Marketing. They're here in Atlanta. And I helped them build a lot of their processes and workflows. And then I moved over to TenUp, so now I'm learning a whole new set of processes and workflows. So I kind of got to see two different sets. And the slides are online at circlecube.com slash does WordPress if you want to follow along or skip ahead or whatever you want. Let's see. Oh, yeah, and TenUp is hiring. They hired me, and they're hiring more people. If you want to, TenUp is great. I'm working from home for them and doing lots of cool things. So they're hiring. So go check them out and apply. So here's kind of the bird's-eye view of what we're going to talk about today. The different pieces of building WordPress websites for developers. We'll talk about doing local development. We'll talk about our config file for WordPress. We'll talk some about version control, about good old database migrations, automated deployments, and then some code standards and reviews, code reviews. So that's just kind of like the birds-eye view so you can know what's coming. And feel free, if you have a question or a comment or a contradiction, raise your hand and tell me I'm wrong because that happens. All right, so one of my favorite slides is this one. I don't always test my code, but when I do, I do in production. So it doesn't happen as often as anymore, at least for me. But 10 years ago, web development, a lot of people were just, we called it cowboy coding. You would just jump onto your server and start editing files. You hit Save and you hope you didn't break anything. And if you do, then you hope you remember to go check to make sure you broke it before you closed your computer and leave for the day. And that's happened a few times. But so instead of logging on to your web server and actually editing files live, which is a no-no, we try not to do that, we do something called local development. So that is, in case you don't know, you can set up your own machine to act like a web server. And you can tell your browser or you can tell your local machine that you can set up websites on your machine that are running. And there can be clones of your actual production sites or your own personal site, whatever you want. And then you can make changes. You can do all your dev work locally. And you can feel safe that if you break it, it's not going to bring a whole website down. It's just on your machine. And then once you get it all built and you have it done, then you can push it up to your production environment, your web host, and then it'll be up there. So in the way we connect with our servers is a tool called File Transfer Protocol, or FTP, or SFTP, if you want to be secure about it, which I would recommend. There's a few FTP clients they're called. They're little programs you can run on your machine that will connect you to your web host, be it host monster or blue host or any of these guys that are sponsoring here today. So that's one way where you're going to be connecting to your server. So you'll have your files on your computer in a folder. And then you'll have files on your server. And you'll try to just sync those up with your FTP. Because in case you didn't know, all of your websites are really just text files that work together in different ways. We have PHP files and JavaScript files, CSS files, HTML files. And they all connect with the core WordPress files and then your database to actually make a running website. So it's really, there's no huge mystery about it. The cloud is really just computers somewhere else that have your files, too. So there's a whole bunch of different ways you can set up your machine to be a local development instance. A lot of them rhyme, actually. There's MAMP and WAMP and ZAMP and AMPPS. And they stand for WAMP if you're on a Windows as Mac, Apache, MySQL, PHP, just a whole stack that sets up. So these, if you want to look at the slides, these are linking out to those actual products. These are kind of the, I guess you could say the old school way. There's a lot of newer tools, but I wanted to mention these in case you wanted to start with those. They're pretty simple. There's normally a UI that you can just click through and create a server, create your site on your server, and you can manage your databases. Just like you would through Cpanel on your web host, you can do it through these tools on your local machine. And then there's some newer guys out on the horizon. There's one called Local by Flywheel. Flywheel is a hosting company. And they've made a tool that can set you up a local instance of WordPress really quick. I guess the specific things about these, well, some of these are that they're focused on WordPress. Whereas these guys are just focused on PHP and MySQL, which is what WordPress uses. So you can set those up, but then you still have to install WordPress. They have tools that can kind of install them for you. Some of these are kind of built around using WordPress. There's one called VVV, which was built by TenUp. It's pretty much command line run. You can install it, and you type in VVV, or I can't remember what the command is, type up, vagrant up, and it'll start your machine. And then you can go to your browser and load up your website there. There's another one called Docker, which does a whole lot of more things than just WordPress, but there is some specific to WordPress where you can just install Docker, which the concept is built like it's a big cargo ship, and you can put a bunch of containers on your ship, and as they all combine, you can save those, that set of containers, that's your whole, your Docker instance, and then you can share them pretty easily amongst others. So I would recommend looking those up, but my most, my highest recommendation is gonna be local by Flywheel. And I think I have, yes, I've got a few slides in here, so this is kind of what it looks like. You can almost see it. So this is kind of the home screen when you start a new site in local by Flywheel, you just type in what your website name is gonna be, and you can give it what domain you wanna use, and you can tell it which version of PHP you want, which version of MySQL you want, which kind of server you want. You can have Ingenix or Apache, and then you set up a username, or a user account for your WordPress, and it even works with multi-site. Can anyone actually read that? It's pretty, so you can do multi-site as well with this, and then you click add site, and it spends for a minute or two, and then all of a sudden, you have a little local instance set up, and then you can go in your browser to whatever domain you choose. I put local.circlecube.com, and then I'll give you a basic WordPress install, and then you can go in like normal and install a theme or any plugins you want, and you've got a local instance, so then you're not cowboy coding. So I think that's the very first step if you wanna be developing on a team or using a modern workflow, you wanna definitely make sure you're using a local instance of WordPress and not logging onto your server and cowboy coding. Oh, and there's another tool that uses Docker, but it's more specific to WordPress as a tool from TenUp. It's called WP Local Docker. You would run, so it's up on GitHub. You can, and we'll talk about GitHub a little bit more in a minute, but you can run a couple commands in your command line, and it will do a whole setup for you, and I think, yeah, so here's the commands. You would just clone this project with Git into your computer, and you would go into that folder, and you would type Docker compose up, and that will download all the files you need. It will get WordPress, well, no, it won't get WordPress, but it'll get all the Docker containers you need and set those up, and then you can run one more command and install WordPress, and it's really quick and pretty easy. I've been enjoying it so far. All right, so that's kind of a whirlwind tour of a bunch of tools you can use to develop locally on your computer. And so, raise your hand, I guess, if you know what the WP config file does. All right, we've got most, maybe half. So the config file in WordPress is where you put things like your database credentials so that WordPress, which is all of the files, can talk to your database, which is all the data and the content for your website. So you need to type in there, like during the five minute install of WordPress, if you fill in your database credentials, it's gonna actually add those to your config file for you. It's gonna ask things like your database name, your username, and your password on your database, and then how it connects. There's a few more details in there, but that's the main part of the config file. So, and environmentally aware config file, so if we have a production site set up on our web server that's live to the world, and we have a local site on our computer, the config file might, the database credentials might be different because we have two different databases now. So you kind of have to think through that. So there are a few ways you can actually have your local credentials in your config file and your production credentials, and you can tell your config file in certain instances, use local and certain use production. It's kind of nice if you want to have one universal config file. Okay, so yeah, here's the default config file. It's gonna have your database name, your username, password, and your host. And I wouldn't recommend these as your username and password, but you know. And hopefully this is still legible to some of you at least. So here's an example of an environmentally aware config file. You can have a bunch of different instances. So in here I've got a local, I've got a dev instance, I've got a QA instance, and I've got a review instance. For some sites, agencies where we work on big projects, we're each gonna have our own local instance. We're all gonna share kind of like a developer instance that's on like our dev hosting. And there's a QA instance so that whoever's doing QA on the site isn't using the same site as our development site so that we can be pushing code to it and not mess up their QA tests. And then we have a review instance where the client can go in and review it. So each of these would have different database credentials and URLs and everything. So here's an example of some code that we'll check out the URL that is loaded in the browser. And depending on that, it can go into the switch statement and load up different credentials for our database, depending. So that's one way you can go about it is having an environment. Is that four separate websites or is it just pulling in different references? Yes to both. There's four instances of pretty much the same website. So they have the kind of the same code base. Usually there might be slight variations. And then so there will also be a production instance which in my big switch statement is kind of the default. So if it doesn't match any of these, it's gonna default to production. And these are from two different files it looks like because this side on the left has a review instance and that one doesn't. So there could be as many as you want. So another option is you can have a unique config file for each instance. You can just have your local config file and then you can have a different config file on your production site. You have to pay special attention so that when you deploy your code, you're not deploying your config file so that it doesn't break your production site or any other instance of your site. So that's another way you can do it. I think, okay, and that kind of depends on how you're gonna be setting up your code. So that kind of leads me to the next topic is version control. Raise your hand I guess if you are familiar with version control, if you've heard of it at least, if you've heard of Git. All right, I think we almost got everybody there. All right, so version control is kind of like, I think I got a good, it's a version control system where you can use Git or there's one called SVN, which is older. So if you ever read online, people talk about VCS, they're talking about version control systems. Git and SVN are two examples. There's a few others out there. And that is a way that you can track changes in your code. So if you are building a site or if you're editing a site, you can save the state it is currently and then make changes and then save that state. And it's a really easy way to do it so then you can share code with other people and you can deploy code with this. And it's just like if anyone's used Photoshop, there's that history panel where you can see your changes in Photoshop and go back 10 steps or five steps or one step and start over. That's kind of what Git is, but for code. And it kind of helps us in these instances where you might, instead of having files where you name it, you know, underscore V1, underscore V2, underscore V2 final, final, final, hopefully we've not all been there, but a lot of us have. So that's kind of what version control kind of was introduced to alleviate. Having multiple copies of the same file and then it gets even worse if you start sharing the files with other people then they have their own copies and who knows which one is the most recent one. So there's a cool site called GitHub which kind of makes coding more social. You can share your code pretty easily on there and it's all built, you might guess, on Git. So you can sign up for an account, you can pull code down to your computer pretty easily, you can share code with people, you can edit someone else's code, you can, they call it forking where you kind of copy their code if they let you, you can have different branches they call it. So you could have a main branch and then you could have like a feature branch or versions. You can, there's a whole lot of things built in to Git that are really good for a developer's workflow. I would recommend you can have code reviews, you can have, you can merge code. So definitely use something for version control, I would recommend Git. If you want to, you can use SVN, I think it's a little more clunky and older, but it works. So this is a page WordPress actually has a lot of things on GitHub too. So you can go look at WordPress code on GitHub, even though it's not actually, they're kind of two instances, they use SVN and Git, officially they use SVN, but you can get on and see the Git as well. And then they have some, there are some programs that you can use. A lot of the hardcore developers will use command line for everything. So they'll type, you know, all of their commit messages and their cloning and their forking and their merging will be command line typing that they do. And you don't have to memorize all of the commands. You can install a program. My favorite one is Source Tree. It's built by the same people that you built Jira and Bitbucket, a few other tools. But you can kind of see here, like all of these lines up there are commits, we call them. So I made changes to a file and I wanted to save that state. So I would do a commit and it would save that instance there. So you can do, they're like, you can do one in a day or you can do 10 in a day. People do it like, either to save their daily work or to save that feature they were working on. There's lots of different ways you can do it. So Source Tree is a really good app I would recommend. And this is a, man, I wish we could read this better. But, so this is kind of a timeline. There's a thing called Git Flow. And if you're working on a team, I would recommend using something similar, at least, or inspired by this. Whereas, so each line on here is representing a branch in the code. So with Git, you can easily branch and that'll make kind of like a version copy of that code. You can make changes to that version but not the other versions. And then if you need to, you can merge those back in later. So this, let's see. This blue line over here is the master branch. That's gonna be like all, we normally master is like the default branch in Git and it's gonna be like, we kind of normally use that as like your production code. So if you have a, you can have a develop branch. So that's kind of where you're gonna be building your website and you'll have that, kind of like the, the instance of what is your, your dev version of your site. So you can make changes on there and you can see eventually they get pushed over into release branches or pushed over into the master branch and you can tag that as a release, things like that. But there's a lot of good articles out there. You can just search Gitflow. I think this image is from that first article from it, which kind of started the Gitflow model. But is there any questions about that? I kind of whirlwinded through Git. I didn't want to bore people that use it already but I want to give it a good introduction to people that don't. We good? All right. So then there's another question. Which code do you source control? Generally we try not, because WordPress is WordPress code plus theme code plus plugin code. Generally people that are building WordPress sites didn't write every line of code they're using on their website. So we try not to version control code that we didn't write because if you run an update in WordPress you're getting a whole bunch of new code from a whole bunch of people around the world that have contributed to WordPress but you wouldn't really want to commit that in your Git because that's not really your code. You're not really controlling it, but you could. So you could have, so each environment or instance of Git we call them repositories or repo for short. So if you hear people talking about repos they're talking about Git usually. So you could have a repo for your whole website. So all of WordPress, all of your themes and plugins and everything you could have one instance of Git, a repo and that could be all of those files. And if you ran an update you could do a commit and say I just updated WordPress. And you could commit that. So that's one way you could do it or you could have a repo for just your theme if you're building a theme for a website. You could have just your theme as a repository or if you're building a plugin you could do a repo just for your plugin or if you're building a big complex site that has a theme and a few plugins and custom plugins. You could have all those in one repo. You could have them all in their own individual repos. It's kind of up to you. And whichever one you decide kind of determines how you might end up deploying the code. You could have, so if you have a theme and you want to deploy it you could just, or you could push it over to GitHub and then you could pull it to your live website from there. We'll talk a couple of different examples of how you can deploy code. But I just wanted to mention like, not necessarily all the code on your website has to be in your Git repository. And you can even ignore files in your version control. So it'll just skip those files. You can ignore whole directories. So there's lots of different opinions out there that I don't want to burden you with one particularly. I wanted to give you kind of an overview. Normally what I do though is my theme will be my repository. And if I have, normally I'll have a plugin that goes along with the theme. So I'll have kind of two repositories that work together. And there's a good tool. Okay, it's right here. There's a good plugin for WordPress called GitHub Updater. Which, you know, on WordPress if you have a plugin that has been updated you have the little update button and you can update it and get that shiny new code on your site. But that goes through the WordPress repo of all the plugins and themes. If you're developing your own, you're not necessarily gonna be pushing your plugin that you built for your specific client or your specific site over to WordPress. You could host it on GitHub and then use this plugin which will then, it'll check GitHub for updates and you can update your site just like you would if it was an official plugin. You can update it through GitHub. So you would push your, you would commit your changes and push those to GitHub and then go into your WordPress admin on your production site that would say, hey, you got an update for this one plugin and you push the update and it'll pull all your new code in. So that's a really cool tool that I've used a lot that helps the workflow. So you don't have to, you don't have to deal with FTP in this case. You just click the button and it does it all for you. Okay, so now we're gonna talk, if you have a local instance, you're gonna probably want some build tools that will help your development run a bit smoother. And this could be for a theme or a plugin. Mostly I'm gonna talk about theming. There's a great tool. We'll talk about Gulp in a second more but there's a Gulp tool. Gulp is a build tool that kind of does a lot of things for you. We let the computer do the repetitive tasks for us, right? A big mantra of development is dry. Don't repeat yourself. You can write it once and let the computer do it the rest of the times. This guy, I'm on a waste. I'm not sure how to say his last name but he built a tool for Gulp which fits into a WordPress themes. I think the next slide talks about it. Okay, so this is generic to Gulp itself and it's not specific to his project but his project is a good starter place if you wanna start with this. So if you're building a theme and if you're using something like, if you're using SAS or any PHP or any CSS preprocessors or if you are using any modern JavaScript and you wanna concatenate your files or minify your JavaScript or any of these tools, optimize your themes, images, or one of my favorites is, well, we'll talk about that in a second, but so Gulp is a node package which you can install on your computer and you type a command, normally Gulp or Gulp watch and it can compile all of your files in your theme and actually prepare it to be released. So it'll compile all of your SAS files and clean up your JavaScript. It can do auto-prefixing and there's like so many things that it can do for you and you set it up once and then you can run it any time you need to do a release or any time you wanna check it and it'll do everything for you in the right order in the right way. My favorite is Browser Sync. It can actually, so you'll have your local instance of your website but you can also run it through a tool called Browser Sync. So if you're building your theme, you can have Browser Sync opened up in your browser and as soon as you hit save, it's gonna recompile your SAS, generate new CSS, push it over to the browser and refresh it for you. So as soon as you type like background red and hit save, as quick as you can like move your eyes over to the browser window, your background becomes red. So it really helps your Dev workflow go a whole lot faster and you don't have to save and then go compile or then go to your browser and refresh and then clear cache again and refresh again because it didn't load. So that's a great tool that I've been using for a good while and it's helped my workflow a lot. You don't get distracted with things like switching context into the browser. You can just hit save and keep going. Okay, so I got a little example of how you would set that up and this is assuming there are some tools I guess assuming we have already. There's a tool called Node.js which is a big package I guess for JavaScript. So you can install JavaScript onto your computer so your computer can run JavaScript to do tasks for you and it's a pretty simple install but in order to get this to run you first have to install Node and then you can install what's called NPM which is Node Package Manager and then you can type commands like this. So those two installs are pretty easy and I think they're pretty well documented but go online and search Node install or NPM install and it will kind of lead you through that. So Node is a library that lets you run JavaScript on your computer and then there's a whole million packages online that people write and then contribute so they're open source. You can install them on your computer so it's kind of code sharing. So then you can type NPM and that will access this whole library of packages. So here we'd be installing Gulp as a tool to run globally on your computer and then you can set up your Gulp file and your theme or your plugin and you would do it. So you type NPM install and it will install all of your packages for your theme locally and you just start it. You type Gulp in your terminal and it will start running. The type, I guess you would type Gulp watch usually to actually have that watch your files and update on the fly. And then you've kind of entered the, you've entered the Gulp watching state and to exit that you would type control C in your terminal on a Mac. Windows, it's something similar, I can't remember what. But so that's a good tool if you're gonna be working on a team and it's nice because then you'll have this Gulp file which stores all of your Gulp settings and you can put that into your Git repository and share that with your whole team. As long as they've all got Gulp set up on their computers you can all have the same exact build process on each computer. So if someone else is gonna do, if you have a front end person that's doing the CSS, if you have an interactive developer that's doing more of the JavaScript, if you have a backend developer that's doing more of the PHP, you can kind of all share the same build process so that you can all have a consistent local environment and there's a lot of different build and workflow tools. We talked about Node and NPM. There's Gulp, there's a missing image in the middle that's called for grunt. It's another build tool package. There's a newer one called Webpack and they all kind of pretty much do the same things just slightly different ways. So sometimes a different tool might be a better for whatever site you're on and there's one which is more PHP focused called Composer which is very similar to the idea behind NPM where there's a whole bunch of packages and you can run a script that will go grab them all and install them locally on your machine so that you can use them or even on your machine but also you can run that on your server and get all your libraries set up. So those are some places to go dig in if you wanna learn more about that. I think if you look at the slides that each of these icons links to landing pages for each project Oh, there's grunt. Okay. And if you really don't like command line there are other tools. I think one of my favorites is called CodeKit. There's one called Prepros which I think is cross OS. So you can set up a theme in there. You just normally would drag a theme into this app, a little applet and it can set it up and it can do a lot of the same things that grunt and gulp are doing as well. It can compile your sass. It can concatenate your files and minify them. It can do all these same things. You can have it watch your files and do it automatically or you can come in and hit the compile. It says compile the compile button and have it do it for you. And there's a lot less set up in this way and there's a UI for people that don't wanna remember command line commands, things like that. Okay. So I'd recommend those if command line scares you. But if command line doesn't scare you, there's another tool I wanna talk about called WPCLI which is a command line interface to WordPress. So if you have your local set up, you can get WPCLI installed and you can use this to actually do things like add users to your website or install plugins or update plugins. A lot of things you can do just by getting into your command line and typing a quick little command. And I think I have a bunch of them up here. So once you get into your project, you can download WordPress. You can set up credentials to your database. You can install WordPress and set up user names and passwords. You can create users, install plugins. You can install themes and activate themes. So you can do all these things just with command lines. You don't have to go log into the admin side of WordPress and click through and find everything. And it's really nice if you do, I mean, if you kind of go through websites rather quickly, you do whatever you could say, if you do a website a month, you could save a whole list of commands that you can then just like go back and paste in and it'll do your whole set up for you. That'll save you the few hours that you have to take at the beginning of every project to go create up your site and install your favorite plugins and create an account for your project manager, whoever else is gonna be logging in. So it's nice, you can, yeah, I'm a big fan of not repeating myself. So once I've done something once, I try to figure out a way so that the computer can do it for me next time because computers are really smart. Yeah, question? Can you do like a batch file where you can add like a hundred users to your website from the CLI? I'm pretty sure you can. I haven't actually done that specifically, but I'm pretty sure you can. So yeah, that'd be a great use for it. You can use your name and password in a file. Right, you just load it all in and it does it for you. You just called up and peed it fast before having it. Right, so yeah, that's the perfect use for it. All right, well that's gonna bring me to database migrations, which is one of my favorite things. So we kind of mentioned earlier, WordPress is a bunch of files. You're gonna have those on your computer or on your web host or both, hopefully. And then you're gonna have a database that WordPress stores all of its content in because it's a content management system. So it's got a database that goes along with it. But the hang-up we get to is once we have a local setup and we have our production site or our dev site, you can have as many as you want. Then you're gonna have a different database for each one of those, usually. And then, so if you're developing on locally and you create a new page and you do all the styling for it and then you're like, all right, we're ready to push this, those manually, so you could push it into your master branch and then go manually deploy it. But that's kind of my preferred way of getting a, I always like to have a second set of eyes look at my code before it actually goes live on a client's website because even though I've been doing this for a few years, I always make mistakes too, even just little typos. It might, you know, the classic, well it works on my machine. Oh yeah, and there's another tool I wanted to mention, Advanced Custom Fields. A lot of people are raving fans about this plugin that let them create custom fields for each post type or content type on their website. If you're working with a team, there's a feature called JSON sync or I don't know what it's called, but it can save out your whole custom field setup as a JSON file and you can put it into your theme or your plugin and then the whole team can share that set of custom fields pretty easily. That's part of ACF 5 now too. Right, so all you have to do is just, I think it's ACF.JSON, you add that folder to your theme or plugin and it'll just automatically save out a JSON instance of that, what do you call them, field group. I think, oh, so here's an example of it. So I've got a theme here, an ACF.JSON file and then it just saves a big gibberish looking JSON file to it but it actually, if anyone uses this theme then they have all the same field data too. All right, I think that's all I've got. I wanted to leave some time for discussion, comments, questions, anything like that, yeah. I have, have you managed to solve for the issue of you've made all these local changes in your local staging environments and then the client has made a bunch of content edits on their site and tried to merge those two data pieces. Right, yeah, so the problem would be, yeah, so you've got a production site and then you've got a dev site or a local site. The client says, hey, I want a new page that does this and this and you build it locally and in the meantime, they've written four more blog posts and had like a hundred comments on their blog and a whole bunch of changes. So if you do a database migration, you're gonna step on all of those changes they've had since your last database pull. So there are a few ways to do that and they get kind of hairy sometimes but the obvious way is you can manually, so you deploy your code and then manually go recreate that page. You know, you'd have a side-by-side copy, paste all your fields or whatever you need to. That one's kind of the land way, no one wants to do that. Especially if you've done like, you know, 12 pages or a hundred pages, you don't want to do that. There are ways you can set up, you can write my SQL scripts that will actually inject that data over into your database. I haven't done that very many times but we could talk about it, I guess in the happiness lounge, yeah. Delicious Frank has a tool called Mergebot. Oh yeah, Merge, records what you're doing and then we'll push it. That's right, I should have mentioned that. So yeah, the same company that did the MigrateDB Pro, they have one that, it'll kind of do like piecemeal, it'll take two databases and you can go change by change and tell it which one you want to keep. That did just come out of beta, like earlier this year, I think. There's another one called Version Press. Right. Which is, leverage is get for versioning of database. I haven't tried it yet. Okay. There are some tools, I've even seen a few plugins. I think there's one called Content Sync or something which would install on both site and then you could deploy like a single page to a production environment instead of your whole database. That could be useful. I think that's what it was called. There's a few that do that. Yeah, that's the tricky situation to get into because you're like, well I have, I can't push the whole database because I know they're gonna lose a whole bunch of stuff. Looks like it's tricky. Anyone else have any tools that they like to use for that? Other than like a pen and paper and like write down every change you do? Any other questions or yeah? Can you just talk about the privacy of repos on GitHub versus big bucket, premium versus free? Yeah, so the GitHub is kind of built with the idea of open source. So they want all of the repositories to be publicly available. If you're building a website for a client, they might not be too happy that their theme is publicly available. You can pay for a pro version of GitHub, I believe. I don't know what price it is. Probably a hundred bucks a year, something like that. But then you can have private repositories which then you have to have an account for and they're not gonna show up in Google searches or GitHub searches. There are other tools like Bitbucket. I think you can do private ones on a, what's that? It's the opposite of GitHub. All right, yeah, so you can do private ones for free and you can do public ones as well. Yeah, you pay for public ones. Okay, now that there's a new one, GitLab, which I really like is, I think it's free unlimited private repositories. So yeah, if you're working with a client, I would recommend keeping it private unless you've cleared it with them first because you don't want them to find it and then say, what is this? So yeah, does that answer the question? GitHub's $9 a person a month. $9 a person a month. So yeah, it can add up if you have a team of 10, but if you have a team of 10, you can probably afford it too. So yeah. Once inside Bitbucket is free. Okay. And there are a few other, like there's one called Beanstalk. I don't know what the version, what's free and what's not on there, but there's a whole bunch of Git hosting tools you can use. Any other questions or anyone, want to make a shout out for a tool that I didn't mention or something like that? We've got a few minutes we can keep talking or we can break and go get some coffee or whatever you want. Yeah, you got it. I guess I have another type of workflow thing. Yep. If you or anyone else has been able to figure out a really good workflow for how to handle feedback and edits. So like, so feedback and edits, like if you're building a site and you want the client to review it and then approve it or tell you. Once you came back or your team tested, and then when you came back, you know. I would generally use a tool like Gira, which is like a task management. You can reassign a task to someone else to review it and they can write a comment like they approve it and you can do things like that. Or other tools that are maybe more simple like Basecamp or even Trello, like. But I haven't seen anything that will like. All right, there probably are tools out there that will give clients access and they can actually approve it through the app and stuff like that. I don't know anyone use. Yeah. Can you repeat that tool that you just mentioned first? We didn't hear it clearly. Gira? Yeah, J-I-R-A. It's kind of like a big. And you're gonna have tons of different workflows set up in there. I'm not sure the pricing structure on it, but it's kind of a big player in that space, at least. Anybody else? Yeah. Do you know if I use Google to keep a change law for the dev team so that they work non-serving files and you don't know? Yeah, I mean, Git itself does a lot of that for you. So if you're using Git as a team, then people like, if someone does a push to like your dev branch, all the other developers can pull that dev branch and see those changes and it'll actually integrate into their environment automatically. So that would probably be the easiest one. There are some plug-in, like you mean like for code or for like content? Well, for like, I guess, override the customizations to the basic coordinates that you use in customizations, basically. Right, if it's code-based, then I'll definitely recommend Git. When you do an update, it could erase something. Right. If it's done to a core file because it's not another way to do it. Right. Yeah, I recommend any file that you actually make a code change on. That would integrate that into some sort of code repository so you can track those changes and then you can sync it across your team pretty easily and it can not be forgotten. Does GitLab work with that too? Yeah, so GitLab and GitHub and Bitbucket all use Git. Each have kind of like a different interface, but the overlying like use is the same, like commits and branches and everything. Okay, all right, thanks everybody. If you have more questions, come see me and we can talk and have a good time. Thank you.