 Uh, first lesson is it's git. Git, oh, yeah. That's the very first thing. That's the first thing you need. Is it? Git? Yeah. Oh, OK. That's the first word. What's that? No, I think I just got it closer, or turn the volume up, bend the back. I'll put that down. I'll adjust this a little bit. OK. I had plenty of time to adjust this before I started, but no, I'm going to do it right now. Hey, everybody. As I was introduced, I'm Dwayne. I work at a company called Pantheon. I'll get back to that in a second. I make things. I like reading comics and web comics, and I love karaoke. I didn't find any karaoke last night, but that's all right. I'm sure somebody did, and karaoke happened in the city, and that makes everything cool. The slides for this and everything else I do is out on mcdwayne.com. I would recommend going there and following along in the slides if you have a laptop or other machine in front of you. There are slides that I won't be showing today that have animated gifts that show exactly what all these commands look like when you actually run them. So if you get lost, you can go back and see it as a tutorial and play along at home. That's the intention. One of my favorite books I've ever read in my life is, you can't teach a kid to ride a bike at a seminar. And it's true, I can't teach you get today. I can teach you the fundamentals, and you walk out with a better understanding. But until you actually put the stuff in motion, yeah, you're never going to learn it. So go to get the slides, and I'll give you a jumping off point as a template to get going. Or take many, many, many, many online classes to forget. Anyway, a quick plug for Pantheon. I work for a company called Pantheon. We are a platform as a service for running your Drupal and WordPress websites. Hosting is definitely one of the feats we accomplish. But scale is our whole game. If you need scale for your team or for your sites, you're doing a lot of things, talk to us. We can make your life a lot better. But I want to know who's in the room. Who am I talking to? Like, there's more people here than I thought would be on a Sunday morning. So thank you very much for coming back to WordCamp Asheville 2019. So who here is a designer? Awesome. Who here is a developer? Awesome, a lot of the same hands. And anybody a project manager in here? Cool. I think it's actually super practical for everybody. Who here is a content creator, content editor, major? Yes, I use Git for all of my content storage needs. And it makes my life really simple as a writer. Because I can go back and see all of the things I've written and why I wrote them that way. But I'll talk about that later. I know we started a little bit late, but I still want to take a minute. And we're at WordCamp. And WordCamp's real value here is talking to other people. The sessions are valuable. Don't get me wrong. And that's part of why we're here. But really, do you have it connected with all the other people at WordCamp? We should do that. So just take a second. Just look around and see somebody you don't know. And just go introduce yourself real quick. Just a minute. Tops. You see him? Nice to meet you. I'm Dwayne. Where are you from? Horsetown. Horsetown? Oh, OK. Wow. Everybody drives in for this. Yeah. Everybody comes in just for this. Well, this is a special camp, I think. Yeah. All right. Use it like a business-like vacation trip. Nice. Nice. Nice. All right. That sounds about good enough. But thank you for indulging me. You can find our seats again. Well, you can find that person later and have a full-blown conversation with them. But for the sake of WordPress TV and the folks at home, I'm going to move on. So if I could get us back, everybody, I've lost the crowd. This happens sometimes. All right, everybody. Let's get going with Git. All right. So why are we talking about Git today? Why did you come into Room Talk about Git? Like, what the heck are we even talking about? Why are we talking about this thing? If you don't understand the why, the what doesn't make any sense. This happens to everybody eventually, where you've renamed a doc a thousand times, and you don't know which final, final, final is the right final. This is the old-fashioned way of doing version control in documents. And then we have the Dropbox method. Who wins? Who wins here? They both edited the same document, and they both uploaded them. And those are the timestamps. Blue, blue wins. That's correct. That's a problem, because what happens to yellow is work. And we've all been here. This is a white screen of death, because we edited something we shouldn't have, and we pushed something around, and we're like, oh, well, that doesn't work at all, does it? Who here has ever used the in-admin editor for anything? Yeah, we all have eventually popped it open, like, I just got to put this little thing in there. I just got to do this one little thing. And then it becomes this, and then we got to figure out what the heck we even did. And ultimately, I use Command Z almost every time I touch my keyboard, because I can't type that well. But this is a terrible strategy for managing documents. It's a good tactical solution for when you're just typing in a text doc. But it's a bad solution overall for getting back in time. So that's what we're talking about. We're talking about, get the version control system. If you go to Wikipedia, it says something like this, completely, completely accurate, but it's a bunch of gobbledygook if you don't know what it means. And the manual for get, if you type man get into any terminal, this is probably what I was going to tell you. It's the stupid content tracker. Notice it's not the stupid code tracker. It's not the stupid developer tool. It's a content tool. Ultimately, that's what get is. So it applies to anything that's in a text doc. But we'll get back to that. I always think it's important to see where this stuff came from and the faces of the people who wrote it. So we probably should all know this guy. If you use Linux at all, or use anything that uses Linux like everyone in the world does, we can think Linus Torvald. And in 2005, he said, the best decision I have made in my entire career is putting junio in charge of the project, of get. And this guy to this day maintains the get repository on GitHub, or all the other get repositories. This is the master key holder for get. Really funny guy. If you go read his pull requests, they're actually very entertaining. And what they had the problem with and why they worked together to make get, it wasn't just some idea they cooked up. They were building Linux, literally inventing it. And said, there's over 1,000 people around the world who need some way to access this code and communicate with each other about how we are interacting and building this code. And they borrowed the old IBM term knowledge worker, which I think IBM coined in the 60s, I think. It's the earliest record I can find of a knowledge worker in this context. I said, knowledge workers do things. They modify objects over time. So what we're really talking about is a knowledge worker creating a document, saving a document, editing that document, saving it again, and keeping track of every time they've modified that document, including an explanation of what they did so that you in the future know exactly what you did. More importantly, other people in the project, without having to dig through lines of code, can quickly summarize, what have we done here? Why did we do that thing? But really, we're not talking about single tech stocks. If we were only talking about single tech stocks at a time, it probably wouldn't exist. But who's ever looked at the internals of their operating system? Like, just cracked it open, and we're curious, and like, just started digging through files. It's fun. Your machines are yours. Part of the beauty open source, and that's why I embraced Linux. I used Mac for work stuff, but I embraced Linux in the rest of my life because it's ours. Literally, it's our code. We can go do anything we want with it. And looking through it is kind of a fun thing to do. And there's so many files. There are so many files. And what do they do? And that's not just Linux, WordPress. There's so many files in WordPress. So we're talking about whole projects at a time, giant sweeping changes, and folder after folder after folder. And we create these projects. We save them, we edit them, and we save them again. And that's why Git came into existence. As you understand this picture, then you probably get everything I'm going to talk about today. And you probably don't need to be here, unless you just want to talk about commands themselves. And I more want to leave you with the impression that this is how Git works than individual commands in your fingertips as you leave the room today. And yes, it might sound a little funny. But here is an actual chart for Git. Git is graphical-based. It's node-based. There's these concepts of these balls on a timeline. And once you wrap your head around that notion, and it might not make any sense to you right now, but start using it like, wow, that's how my Git history works. That is this crazy chain and branching and alternate timelines and going back in time. In all reality, these look a lot alike. So very important to all of this. That feels like a weird segue. But got to remember, everything with Git is local. It's a stupid content tracker. It knows other versions of itself can exist, but it thinks it's the only one and thinks it's the most important one in the entire world, wherever it is. A Git instance on your machine and a Git instance on a computer you don't own called GitHub or Bitbucket or on another machine somewhere else in the world. From its point of view, it thinks it's local, and it's the only one that really matters. Kind of important thing to remember, and it took me a while to wrap my head around that one. But again, fundamental concept, it's important. It's also super lightweight. If you change a 10 meg file, change two characters in it and you SFTP that across the wire, how many megs do you have to move when you edit that file? 10 megs, that's correct. If you change two characters and move that same file, changes over Git, how many characters do you have to move? Two characters and a little bit of metadata around it. So not even close to what you'd have to move otherwise. Super lightweight. Git is not a backup tool. It kind of is for your code. It can double as a backup system for your code. It's not intended to be. Well, I put this in here specifically to remind people because a lot of people when they hear about this, like, oh, that's awesome. I got everything backed up. I don't have to worry about backups anymore. We're not talking about your database. We're not talking about your media files. We are talking about your code when we talk about Git in context of WordPress. But Git is a nice backup tool if all you do is text files. We'll come back to that later. But it's not intended to be a backup tool. That's a side effect. And if you can point me to a better documented thing that exists in relation to our space, please tell me because I can't find one. There are more documents, blogs, tutorials, guides, everything written about Git than there are any other project I've ever seen in my life. It's this important. I think we should honestly be teaching it to the grade school kids as a better library system. It just makes sense to knowledge, like start version controlling our knowledge bases. So how do we do this? This is where this tutorial part kicks in. So if you have a machine open, if you're on Linux or a Mac, you probably already have Git there. If you don't, you're on Windows. There's this beautiful thing called Git bash, which is what we'll be going through today. I am going to focus on the command line version of everything because that's how it was written. That's what it was intended to do. It's going to be a bunch of commands that you can telegraph to your computer, and it does a thing. But there are a ton of GUI tools out there. These are just the first four that got named when I was making the slide. There are others. And I used to be kind of against them. You've got to do it the command line way. It makes more sense to do it that way. But I've been thoroughly convinced recently that's not the case. These tools exist for a reason, and they've evolved right along with Git. And you can see visually things a little bit cleaner and clean up some problems that have like logic layers of how it deals with conflicts and whatnot. So if you want to start with a GUI, start with a GUI. If you want to start with a command line, start with the command line. Either way, you've got to get Git on your machine before you can do anything else. So I'm going to walk through a bunch of commands now. And if you have these slides at home pulled up, I've hidden every other slide. But there's an animated GIF that shows what does this actually look like running and how it might look on your machine if you wanted to copy exactly what I did. So first thing we're going to do is a NIT. A NIT says, let's go ahead and create a Git repository in this folder. You can have as many Git repositories on your machine as you want, just one Git file for a folder. And what a Git folder actually is, to demystify the whole thing, Git is basically just a bunch of bash commands that make folders and move files around. With this one special little part that makes these things called hashes. Other than that, you can completely manually recreate Git if you wanted to. You probably don't want to, but you absolutely could. There's nothing that's magic special here. It's a dot folder, so it means it's hidden. Dot Git. If you're brand new to all of this stuff, ls-a will show you all of your hidden folders when you're in a command line situation. Or if you're on a Mac or PC to find the option to show hidden folders, there's a lot of hidden folders in there. But inside of here, I'm not going to dig into all the internals, but there's a thing called head. Head just tells you where we are. Where is this reality? Everything else is kind of storing all the changes over time and the meta around those changes. There's a proper naming system of all this, or tree and nodes and branches. I'm not going to get into that today. It's kind of a little confusing when you first learn it. When you're digging the internals later, it becomes important, but Git init's the first thing. We have to say, hey, exist Git. And it's like, all right, I'll start paying attention now. And then there's this thing called Git status. Git status is the safest thing in the world to run. If you're ever confused and lost, just Git status. And it says, this is how I think the world looks right now. And it will say, hey, you haven't handed me commits made to me, but there's all these files I can see, but I don't know what to do with them. They're there. What do you want me to do? Again, get stupid. It needs you to tell it. So we're going to do this little dance called Git add, Git commit. So far, again, we're only ever working locally. So Git add puts things kind of in a file folder. And Git commit puts those things in a file cabinet. So if I was to, I should have got a file folder. If I was to say, if we could take a digital representation of everything up here, imagine this is like digital and not real. I can say, all right, this is the state of this stuff right now. I want to put this as is, this version of reality, in a file folder. And then I say, OK, we're going to take a snapshot of this stuff, but it's not a snapshot. It's actually this stuff. That's a Git add. We're going to Git add everything. Git add dot. And then I say, all right, I want to remember this stuff. So I put a timestamp. Like at 9.21, I had the cup under the projector and initial commit. Great. Put that in a file cabinet. That is done. That is in there for good. We can get rid of it if we really, really want to, but that's there. And now I come along later and I move that around and move this up here and do one of those. Actually, I'll probably catch fire. So I'll do one of those. Move this a little bit and I put my phone up here. Now I can say, all right, Git add or save all this and then Git add. And now I've stuffed this representation of the world into a new folder. And I write on the outside of it. I move the coffee cup, move the mic stand, move my phone. That's good enough for my notes for the future. Write that on the outside, put that in the file cabinet. Then I do it again. Make some movements, do the thing. Add nauseam. Keep taking those snapshots of the representational state of the world, putting them in a file folder, writing on the outside and that's my commit, putting that in. So as you can guess, I have this file folder full of these files of these commits. I can go back and look at them and eventually go back in time with them, but I'll get to that. So when we add a file, what we do is we're adding it to the staging area of Git. It gets like, all right, I know now that you want me to pay attention to this thing and I can see what version it is right now. Put in that file folder. So you can say individual file names, more complex projects you're working on. This is actually the safest best way to do it. But if you're really, really lazy, or you know, I'm just going to trust everything I did was correct, Git add dot. Dot is a magical thing in bash. It's the self-referential dot. It says here. Git add everything in this folder and everything related to this folder underneath it. It's kind of a magical special character called dot. If you ever see one of command lines like cd dot dot, that just means the directory above me. So like two special magical characters in bash, I love. Anyway, then when we write our commit message, we can throw a dash m flag in the command line and say, all right, here's my message. If you're using a GUI, there'll just be a box and just write your commit messages in there and does the same thing. On the command line, though, if you don't type the dash m flag, then you get dropped into the default editor. And on most systems, that is set to VI or VEM. If you're lucky, it will be set to nano or pico. But most of the time, you're going to be in VI. The number one thing googled on Stack Overflow, googled and found on Stack Overflow, is how to quit VEM. Not kidding. Because it's an archaic, weird system when you first encounter it. You have to type I to insert to type your message, escape to get back to the command, the level of it, then colon WQ to write quit. Which on the surface, wow, that is convoluted as heck. But if you want to go to a world where your fingers never have to leave the keyboard, ever, learn VEM. It's actually really fun. And if you can touch type, it will improve your efficiency dramatically almost immediately. You can make it do anything. This is a technology that's been around for 30 years that's only ever gotten better and only improved. It's convoluted to use it first. But if you want to memorize 100 hotkeys, it's better than Sublime Text or Visual Studio. I'm convinced of this because you are in the code. Anyway, enough preaching about VEM. But once we've got the steps down of add and repeat, we just do this over and over and over and over again. And honestly, this is 90% of Git usage. This is 90% of how I use Git. Git add, Git commit. And another step we'll get to later. What this does is it gives us this ability to look back in time and see Git log. So we can see exactly what we have done in this repository. And that stupid long number there, that commit hash, that's the magic of Git. I don't think we should overlook this. The likelihood that this number will ever be repeated is 1 in 3 billion. Never in the wild has there ever been two commits the same, two commit hashes the same, especially not on a single project. It was forced in a lab one time. They figured out a way to cause a conflict to happen there. But that was an artificial situation. It's kind of this magical algorithm that happens based on the contents of the thing you're doing. It's kind of cool. But Git logs are a lot of information. I'm going to do this thing called Git log 1 line, which just spits out a quick list. So there's a small one, but I'm going to go live code this thing, and I'm going to do a Git log 1 line. And here is the actual history for this project I do called kevinthal.com, the buddy of mine in the Drupal world, that I run this website. And here's the actual things we have done with this site. So at a glance, I can see, oh, OK, we did that. OK, oh, right. I see who did that, OK. Just a very quick glance of the world. You can also see, what have I changed? Like, all right, I'm working, and all right, I made a bunch of changes in this file. I've been working here for 20 minutes, and I keep it and save, but I don't remember where I started. When was the last time I committed? Uh-oh. Well, Git's there again. Git diff. This is the basic use of Git diff. Git diff actually has a bunch of uses. But the basic one is, where am I? What have I done? What has changed? And one of the cool, interesting things on Git is Git doesn't do individual characters. So I kind of lied earlier when I said you changed two characters. It changes lines. It understands lines of things. But if you change a character on a line, it thinks you destroyed the entire line. So that's why you have a negative red. Like, red is this is the second line. And then down below, it's the exact same thing. I just added a space of above, or a character turn above. It's like, all right, there's a whole new line. You can erase that line. So it's keeping track of things very fine grained. And all that stuff at the top is actually important to get itself. And it's things if, on a very, very advanced use, is you can actually use that information in very effective ways to get back in time and modify things. But that's moving forward in time. Again, if you understand that of like, I'm taking a representational state, adding it to get pay attention to this and then get commit to save it long term, that is 90% of get as far as just pure usage. But what makes get exceptionally powerful is this ability that we can go back in time the same way we went forward in time. Literally. There's a thing called revert, where you can just step back through all of your commits and say unravel what you did. If you know anything about knitting or crocheting, it's literally just pulling the thread back out. And you just go back in time a step. Very safe to do, because you're just undoing the thing you last did. So there's not going to be any conflicts with that. It's pretty cool, pretty safe. You can revert to any of these IDs. So when we're reverting, what we revert is the actual ID. And the short ID versus the long ID, get doesn't care. It knows they're both the same thing. So this ID maps to the other longer ID, and it's all fine. So here I have said get revert this one, and there are sure enough. What happened is I got a brand new commit that happened that reverted the last set of changes. But that last set of changes are still sitting there. So there's EDB8895, and there it is. But there's a new commit ahead of it. Because you're still going forward in time, even though from the code functionality perspective, you've taken a step back. Because it gets kind of stupid. It doesn't want to go back in time. It's like, all right, I'm just going to keep adding things. And you can keep tracking and go back to anything. You can even revert reverts, which happens sometimes. Like, well, you know what? That revert didn't actually fix the problem. I guess that bug was somewhere else. Let's just revert that revert. It kind of looks funny in your history, but it's a safe way to do it. Because, again, a revert is just a commit. But there's this other thing called get reset. And you throw the flag hard. And it's like, all right, I'm going to forget everything after you told me that point in time. So I get revert to EBDD. There we go. So I had these other changes ahead where I reverted my revert. But that looks stupid in my get history later. So I don't want to actually explain why I reverted or revert. So let's get reset hard and pretend those didn't ever happen. Now, we're worrying about this. This is super dangerous. If you get revert hard or get reset hard to the wrong point, there's ways to get out of it. But it's convoluted and you've kind of hosed yourself. And if you're working on a project for other people, they're going to hate you if you've done this. Because that's going to mess up their get logs. So revert's very safe. And nobody's going to get mad at you for reverting. Get reset hard should be a discussion with your team. I'm going to do this. And everybody's like, OK, we're good with that. Then you do that. If you're working by yourself, do whatever you want. That's forward and back in time. Get add, get commit, and get revert. Three commands. Not that much. Get status, get log. Those are informational. Good to know. Not that many commands yet. But then we get to the real superpower of get and why this will change your life as a developer. This concept of I'm going to create an entire parallel universe based on what's here now. And anything I do in that parallel universe does not affect my master reality until I want it to. And if I don't ever want it to, it doesn't have to. You can have as many branches as you possibly want. I have one Drupal repo with 6,868 branches because I installed every module. It is another project. There's no limit to it. And you can play in these as much as you like. And then when you're done, you just merge those back together and say, all right, I want this reality to now become this reality's timeline. So the word master here is convenient, but it's arbitrary. Like that's just what your first reality of get just happens to be called. They could have called it like reality one. It'd been the same thing. In fact, you could rename it if you want. So there's no master-slave relationship here. It's just master's default, what they called the original baseline reality. So you can say, get branch. And get branch will just tell you where you are. It's like, all right, here's the branches I see. And there's a bunch of flags for this. And if you're working with online repositories, you can look at remote repository branches without having to pull them down, but we'll get to that later. But to make a new branch, you just say get branch, and then name the new branch. And it's like, all right, there's a new branch now. Get set up to do this out of the box. And then once you move over to that branch, you just get check out. And check out this very powerful feature. And who here has ever worked in the SVN world or any other centrally controlled version control system? So good, I'm not gonna have to unlearn y'all on this one. I learned SVN first, so that's like threw me off when I first encountered it. Get check out says, hey, get, move the head of what we're working on over here. And let's pay attention, or not pay attention. Let's pretend like this is all of reality now, in this branch. This doesn't just affect what it's trying to track. This affects everything. So when you check out, all of your tech stocks will magically transform into whatever's in that branch. So if my branch, like I've deleted a plugin, and I'm working there, and I go back to a master branch, and that plugin's still there, it's almost automagical, that all of that just transforms for you. You don't have to save anything or do anything special, you're just checking out this new reality. You can do this all day. So if you wanna test out a plugin, make a new branch, throw that plugin just in that branch, test the heck out of it, that doesn't work, let's flush it, we don't need to care about this. If it works, let's merge it back in. Yep, the branch you're working in, you do the exact same steps, you get add, get commit, and it has its own gig log. And eventually you merge that back in, so that's the point there. And to merge you just say, hey, merge, look at this. But where are you merging from? First you gotta make sure you're in the branch where you wanna merge into, because again, everything with get is local. From get's point of view, it doesn't wanna push things, it doesn't wanna move things around outside of it, it wants to thing if things move into it or move, like push away from itself. So, go back to check out master, and then merge branch that you want to merge into master from there, and it works good. Yes, that's it. So if you wanna merge things back into master, you check out into master. But merge works both ways. So if I, this is a classic with updates. So, Repress at Org is released a core update. Meanwhile, I'm working on a new theme that I'm like custom theming over in a branch. I apply the main, apply the update to my master branch, get that's production. Then I go back, jump back into my branch that I'm working in for my new, my new theme, let's call it new theme branch, and I get merge master from my new theme branch, and it pulls that change over so I can make sure that those updates aren't gonna break my theme work. Very powerful. You can do this in less than 10 seconds, like this is a very fast operation for Git. It's like, okay, now I'm good. I can do this really quick, really lightweight. So you have infinite number of test machines on your machine now. Congratulations with almost zero setup. If you're working locally, this just works. But you will run into the sad trombones of the Git world eventually, and there's no way I can tell you to prevent it, or you'll hit a merge conflict. An emerge conflict is where the same document, or documents, have changed in both places. You changed it in master, and you changed it in this branch. And again, Git is the stupid content tracker. It doesn't know what you meant. It's like, one of these is probably right, but I'm just gonna fail now. But it's not gonna completely fail. Git merge will actually get to a state where it's like, I'm gonna keep trying to merge this thing, and now I'm in this funky state you need to fix. And all you really need to do to fix it is go and find all of those conflicts, and it will do this to your text. Because again, we're just talking about text files. So here's like, okay, this is what you said in master, and here's what you said in new branch. What is it? And then once we fix it, to be in our liking, what do we do? We save? What? No, we're back and we're trying to fix this in master, and there's a merge conflict that's happened. We fix the text document. Like, okay, this all looks right to me now, Git. We save, Git add, Git commit, and we go back, we just write back to that forward march. When in doubt, you're probably gonna do a Git status, and then probably Git add and Git commit. Like, that solves a whole world of problems for you. There's also a bunch of tools that do, will help you out with this stuff. But here's like a quick example. Like, here's me literally editing that text file. It's like, all right, here's what I really want it to be. Now, Git add, Git commit, fix some merge conflicts, and there, I'm good to go. Git status is clean, we're all happy. Again, you watch that on your screen, it'll look a little better. But there are tons of tools that will help with this. In fact, this is one of the arguments for using a GUI. GUIs can have built-in logic layers that can assist with this out of the box. The source tree is my favorite. It's like, I will crack open source tree if I hit a merge conflict that I can't figure out. Because it will show me visually things that I can't conceptualize in my head that easily, and will actually help me find all of the merge conflicts. But there's all sorts of tools. If you just type Git merge tool, it will say, you don't have any of these installed by default, which one would you like to use? And then once you pick one, it will throw you into that tool, which is, we'll just take you right to the conflicts and fix it in text. Everything up to this point has all been on your machine. 100% local. Now we're gonna talk about Git repos, Git repositories on machines you don't own. But guess what? It's just Git. There's a fancy UI on top of it. Don't get me wrong. All of these people have done amazing things. Git Hub is the classic, the first to bat. But GitLab, their CI CD is pretty darn awesome. There's a reason the Drupal projects went with them as their collaboration hub. Bitbuckets got some advantages as well. Not gonna say one over the other. But they're all implementations of Git online. I'm gonna show Git Hub because it's the most common and I think everyone needs a GitHub account. But this is just the same as doing a Git log locally. Just, it looks a little different. The model's very simple once you start viewing it only from everything's local. And I'm basing my point of view inside of one of these bubbles. Because you're pushing away from yourself and you're pulling into yourself. So if we look at your repository, you get pushed to a remote. But from the remote's perspective, it's pulling the code into it. From my repository origin, I am pushing. And then on my colleagues machine, they're gonna pull that content from, or pull that code or whatever, those files from origin into their machine. You pull into the repo, you push away from the repo. And if you always view it from the point of view of one of these points of view, it makes a lot more sense. Like, all right, I am on GitHub, I need to pull something into here. I'm on my local machine, I want to push it to another machine. But yeah, good question. Thank you very much for that. So when you create a GitHub repository, which is like, well the next thing I'm getting to, but great question. Just the same as your master reality just happens to be called master. Your first remote repository, or your first remote, like the, yeah, let me get to the next slide and then I'll make some. Your first remote is just happens to be called origin. So when you make a remote repository on GitHub, it will give you all these options of things to do. So you're creating a new repository and you're either gonna build from there on GitHub or you're gonna do this probably, push an existing repository from your local machine. Would say, all right, I'm gonna add a remote. Git remote is like, here's a machine that's not this machine where there's a clone of this repository that I need you to be connected with. And tell me if you're in sync. Because Git might be stupid, but it can tell you if it's identical to its twin. And if it's not identical, it's like I'm not identical anymore. And it can tell you like, we're out of sync. I see this many commits ahead that I don't have locally. What should we do? Or not even wanting to ask you, we'll just sit there. But saying, all right, get remote. And the first remote just happens to be called origin. There's no rule to that. You can call your remotes whatever you wanna call them. But the first one just happens to be called origin. So in this model, yeah, that just happens to be the first GitHub repository we made for this. So in the first place we wanna push. Yep, literally. LAN. If I have the address of this machine on a network, Git don't care. There's like no... Computer A, computer B, however we network them together, Git don't care. It just knows I got a remote here and I have an address that realizes this over here. I can conceptually connect these two things now. It depends on the project. Remember, this was invented. GitHub was like long in the future. Like this was invented on local machines that are on LAN networks. So. Or around the world. I know, but it's easier to do. Yeah, yeah, yeah. Yeah, I mean, Git is so lightweight, it would work on an old BBS. Like we're just moving deltas around. Yeah, and then there's these concepts of Git push. So you can push to the origin. And we have to pick what branch we're pushing. Cause we can push any of our branches anywhere. So you can store all of your branches online. Or work with them that way. And then pass like, hey, I'm doing this experimental branch. Why don't you pull down that branch from GitHub? That's actually a pretty common phrase when you're working. I'm testing out a couple of things internally to Pantheon and Terminus. And that's how we're doing it. It's like, okay, go grab this branch and go test that out. This is how it works. You can have as many remotes as you want. You have a thousand remotes if you want. I don't know the use case for that. A lot of people do a remote. Like I have things where we'll push things to Pantheon and they'll also store it in GitHub for long-term storage. No question? No, it adds the branch locally. And then you can check out that branch. You're getting a clone of that branch. Yeah. It's the same repository. It's just a branch on that repository. When you clone down, you automatically clone down master. I actually haven't gotten to clone yet. I'll just jump to clone now. Just to take the time too. So clone. Most people don't just add remote repositories and that's not how they work with remotes. Most people will work with remote by default because that came with where they got the code from. There's a concept of git clone that does all a bunch of stuff for you. Yeah. A bunch of stuff for you. So you can say, all right, initialize this here, copy everything down and set the remote to be where you got it from. By default, you just get master with that. But you can say, hey git, go pull this branch as well. And then it's just like you made that branch locally. Git doesn't know the difference. And then it's just git checkout and you're in that branch the same way it'd be if you created it locally. Jump back here real quick. So I can git push locally. So I'll make some changes, push it up to GitHub. I can also edit on GitHub or someone else kind of edited this file, pushed it back to GitHub, and then I would need to, went the wrong direction. Then I would need to pull that information back down. Technically a fetch an update, but I'm not gonna get into semantics with here. If you say git pull, it will say, hey, go make this true versus what I see over there. Again, you could get a merge conflict from this. It could be like, hey, something's wrong here, depending on how you've been working with that repository. But with enough git statuses and enough quick code reviews should be good to go. And then same thing, we just push pull all day long. Git clone though, I already talked about. This is the most common way people use GitHub. It's like, I'm gonna git clone this down. At some point you will run into a situation in your life like, oh, there's code for that on GitHub, just go pull it down. Eventually someone will say something like that to you. This is what they mean. Go run the git clone command, throw it into your local, and then get to work. You can optionally name the thing, so git clone, the address of that GitHub repository, and then WPCI demo is just what I called that folder. So we'll clone it into that folder. They can change into that folder and see what's going on. There's that demo folder it just made. And that gives us up to the last important section, which is pull requests. Pull requests are concepts you actually already know. We already covered these. It's a branch in a merge, but there's a conversation in the middle of, hey, why do you wanna do this? That's all it is. Branching and merging? Again, we're just using git on a machine you don't own. Unless you do own it, you can run your own git instance out there in the cloud. That's cool. But you have to be the person who runs it. GitHub gives us this ability of a repository owner. First, you can actually say this goes in here. You can have multiple owners, but that's why it's very, very important to have people that are like core committers who can actually make changes officially to a thing. Everybody can make suggestions. We can all go right now on our computers and make a suggestion to WordPress core. Say, here's what we think we should have, but here's a patch that we think should be applied to WordPress core. But there's only a handful of people in the world that can say, yeah, that's a good idea. So that's the person over here, the person in green. They're the repository owner. Everybody can push up to a branch to the repository. I'm gonna, there's more complicated than that just pushing, but you can open a pull request for the new branch and say, hey, check out this branch. Check out this code in this branch. And if it's cool, then you merge it with master on your end. That's called a pull request. GitHub has a very, very, very slick interface for this. So does GitLab, so does Bitbucket. Make it very, very easy. You can do this all with command line as well, but I'm not gonna bother getting into that world. Way easier with the GUIs on this one. And that's it. This is 16 or 12, one, two, three, four, five, six, seven, eight, seven, nine, 10, 12, six, 16 commands. If you're gonna remember this list of commands, this is honestly 95% of what I've ever seen Git used for. There are a bunch of other crazy, awesome tools with it called Git bisect, where it will help you track down where a bug emerged. Git cherry pick, where you can really mess up your repository and then say, nah, I'm just gonna cherry pick off of these other areas like what's reality? And then we're gonna say, all right Git, this is reality now, go forward. But those are only getting to situations where you've done something more advanced. The vast majority of the time, all you're probably gonna do is Git clone, Git add, Git commit, and Git push origin master. Those four commands are literally 99.9% of what I personally ever do with Git. For everything else in the world, just go to DuckDuckGo. I'm not even saying it for the privacy concern reasons, but if you look up anything Git related on Google, you're gonna get Stack Overflow from 2012 from the way the indexing works. Just the truth. Not that there's anything wrong with that, Git hasn't changed. Same Git. I find DuckDuckGo actually gets me to the documentation and actually relevant current information just faster. I don't know why, but it does. Thousands and thousands of resources out in the world for you. How to get started guides, full on tutorials where you can learn the command line of Git from the browser and things like that. That's it, that's what I got. Thank you, I'm Dwayne. We've got a question. The short answer is what makes sense for you. Both are completely valid options. Some people would argue that just doing the custom work you're doing is the best thing to only verging control that, because why would you verging control core? I'm showing you literally, this is my blog, this is my website, mcdway.com, where you can get the slides for this. This is the entire WordPress install because I'm on Pantheon and we verging control your code automatically and as an artifact of that, we do verging control all of WordPress. So there's no harm in this. There's no, I think, great benefit to it either. What you probably actually want to do is go to a world of Composer where you tell Composer, go grab all the Office shelf parts like WordPress core and I'll only worry about these two folders that live over here and I can't even tell Composer to go grab those folders when you're compiling the thing. But that's a completely separate subject. But this is my version control here, it's like a Git log. This is how I have, yeah handwriting plugins is still hard. This is what I've actually done to my site. I can see when things are updated and yeah, this is Git log one line, but I could go just quit and get Git log and here's everything I've ever done, I patched the mark downify to continue to. Yeah, but this is like literally a real world use case. This is how I manage my blog. I just change it and get and push it up when I'm done. All right, a question? No, it's a repo. A Git reposer, Git repo, Git repo, it doesn't matter. There is a way to commit to command line, create GitHub repos, but I don't know what it is. But it's in the docs, you can do it. It's in the GitHub docs specifically. Yeah, you need the GitHub CLI to pull that off, but the far easier path that works reliably is just go create it on GitHub first. Yeah, that's it. Just follow the directions there. It's like two steps and it's just, it's way reliable. But there is a command line way, I just don't know what it is. No, that's a great question. Committing WP config. So I do, so I'm happy to show anybody my WP config, actually, let's cat it, WP config, because, oh, config.php, because I'm on Pantheon and all of our server variables are hidden. So yeah, this is, yeah, DB name, username, they're all picked up from the server. So if you're doing it this way and you're using a token system, yeah, commit it all day because who cares? Unless you don't want people to see your redirects, which they're gonna hit anyway. Yes, yes, thank you, thank you, William. So I'm sorry, so if people didn't hear the question, should you commit, if you're gonna commit everything, what about WP config? And in general, no, don't commit WP config, if you're gonna version control everything, unless you're using a tokenized system, like we have a Pantheon where it doesn't matter, it's just like something, a server variable that's gonna get picked up and then it doesn't really matter. What I didn't talk about, because I think it's something you don't really need when you first, first, first encounter get and that's who this is designed for, is the get ignore file. So if I do an LA, I have a get ignore file and a get ignore file simply says ignore all of this stuff. Get, don't pay attention. If it's a dot DMG, a dot jar, a dot zip, do not track it. If it's an icon, which is a thing, or a DS store, screw DS store, I hate DS store so much. Like, just completely ignore it. Like, we are not gonna track that, don't even ask me, I don't want you to know. So that's get ignore, it will just let you ignore things. This becomes very important if you're doing like complex projects with nested get roots, our next nested get repos, you can say, all right, let's just ignore all of those and just deal with the highest level. Like William said here, the other better approach is anything that you don't want to version control. You can move up a level and WordPress, and most hosts will let you do a thing called nested doc root where you're actually putting the actual install a level below and something called web or doc root or depends on what server environment you're in. Most of that will let you call it whatever you want. On Pantheon, it's just called web. But you can store things in there and then above that is all the meta about your site and you can store anything there you want and those would be separate repos or the same repo or multiple ways to approach that that's a good way to do it. It's like keep that stuff above that you're not pretty controlling. No, some modules are not a great idea in my general opinion. Some people will argue that and that's one of the beautiful parts of computer science is there's not 100% right answer to that, I would discourage that and I would say individual repos for every app that you're running. It's just gonna be cleaner and a much smaller repo. When I say get as lightweight, it is but if the repo's like 68 meg, it's still 68 meg. Yeah, exactly. But there's no like 100% right, I can tell you. William might have an idea though. There you go, agree with what William said, don't use sub modules. Git stash has gotten me into trouble more than it saved me, I'll be honest with you. So Git has this ability called git stash which just says anything we got committed or not committed, anything we got staged or any changes we can see, just ignore them for now and let's me get out of any weird state I'm in temporarily. So the best use case I've ever seen for Git stash is uh-oh, update rolled out and this is a mission critical security flaw update we gotta get to production. Everybody Git stash right now. Make sure your stuff's clean. We're gonna push this production. All right, now we can un-stash and go right back to where you left off and hope nothing broke. I have forgotten to un-stash personally. Enough times that it's burned me that I like other alternative routes to stashing but stashing is a powerful tool. If you're working locally, it's actually super handy but don't forget to un-stash or you'll end up with more problems than you started with. Yeah, that's it, you're literally telling Git, hey, stop working for a second. So we can just get around this one issue. So Git stash is powerful but use it at your discretion. Yeah, manage, yeah. Absolutely, that is a proper way to use it and I'm not gonna argue against that. It's just I've burned myself enough trying that that I don't do this but that's personal. Everybody's gonna have a different opinion. I think that's it, I think it's time for me one more but no. All right, one more and then we'll clap. Git is just a hidden folder so there is no danger in doing it that way but why you wouldn't just use like GitLab or GitHub or Bitbucket is like, that would be more of the question. I mean, if you're just like locally getting into that machine and getting into the actual file, I don't see a problem with that. Like I don't, I've never seen that actually in practice but like, this is the end, this is the last one. You got with GitLab? Cool, GitLab's awesome because of the CI CD runner system but that's a whole other just conversation. All right, that is it folks. Thanks very much for coming. Again, I was Duane. You can get the slides over at mcduane.com and have a great word cam.