Never lose code again

When you first jump into development, there's almost nothing more confusing than Git. What exactly is it? Why is it helpful? So many people are jumping into development right now because of AI. But this fundamental concept can really help save you to make sure that you're not throwing away code or that you don't get overwritten by some AI and you can't recover what you've done before. So I'm going to talk about what it is, how to use it, and some of the benefits for you in this kind of conceptual walkthrough of a very basic introduction to the concept of Git. You ready? Let's go. Hey, what's up? My name is Chris and welcome to coding in public. All right, git get what in the world is this thing? Well, this is going to be more of a conceptual overview to help you understand why it's important and why it might be beneficial to you. Have you ever been writing some code here and you go to make some changes? So, let's say you've got some little blocks of code in here and you decide, you know what, I'm going to add a couple extra blocks and then you decide, well, you know what, let's remove one of these. So you remove this one and then you add another block over here and then you say, you know what, I kind of wanted that previous block, but you're like, "Oh no, I just deleted it. I don't know how to get that back." Well, sometimes your AI agent will actually do this for you. You'll like some part of code. You'll say, "Hey, change that." And then you're like, "You know what? I kind of liked that." You try to get it to do it again, but it's not quite the right way. Wouldn't it be nice if you could have little checkpoints in your save history? That's what Git is. It says basically, hey, let's create little save points. And I almost like to think about them as books in a library. So let's say you've got a little library shelf over here. The very first rendition of your code is just like this. We're going to call it number one. Then you go to number two. Then you go to number three. And any of these save points, Git basically continually saves them all. So you can go back in history as much as you want to. Now this is not GitHub yet. I'll talk about that in just a second. But you can be in version three or maybe you create a version 4. Whatever you end up doing, you can always go back and say, "You know what? I liked version four, but there was this little part that was in here in version one that I kind of want to grab and I want to bring it all the way forward to the latest edition." Well, Git tracks all of these no matter how many extra steps you have. So, it's like save points in a video game or different volumes in a series, right? Um, the idea here is that they're mostly the same, but you might add some stuff or remove some stuff in this one. Same thing here. And they're all based on each other. So, it's just step points in history. Now, that is essentially what Git does, but it's a lot more powerful than this. This might be something like Google Sheets or Google Docs or something like that right now where you can go back and look in the version history and say, "Okay, what who made changes in the past?" The problem is in code, you typically have lots of people working on this at the same time. But even just here, you can see how useful this would be. In fact, if you're using AI agents and coding, I would strongly recommend that every time it makes a change, you have a commit. Um, and that's what these are called. These are individual commits. It's a way of save saving. It's a save point. So we say, "Hey, commit this." And that way if it changes something you don't like, you can say, "Hey, we did this before. Go check in the commit history and find where we did that and bring it back forward to the front." So this alone will save a lot of people just by having these little save points. But like I said, code itself is usually shared by lots of people. So typically what you want to do is not just have this locally on your machine, but you also want to push it up to some kind of cloud. You ready for my cloud? Here it is. All right. So there's my cloud. So what you're going to say is, hey, I want to have somewhere I can store this, not only on my own machine, but I also want it to be somewhere else where other people can pull it down or I can kind of have this distant save point where I can go grab stuff if I need to. So this is called GitHub. Now there are other things like GitLab and other things like that, but most time people just use GitHub. That's a very popular one. It's been around for a long time. It's owned by Microsoft now. And so people will often store their entire Git repository, which is all these save points inside of GitHub. Now, you actually have kind of a two-way sync between you have whatever your local file system is, and it can only be opening. It can only open one of these at a time essentially. There's some complexity where you can get it to do more, but essentially, you only get really one at a time. However, when it comes to like looking back in history, you may not only want stuff locally, you probably also want to have stuff up somewhere remote. Now, there's a lot of advantages to this. For instance, you can tell your AI agent, "Hey, go into my GitHub, pull down the code, and do some stuff, and then push it back up." Now, you can also have a teammate do the same thing where you have a teammate who says, "Hey, I'll do some work, you do some work, and we can kind of work together." Now, this whole process of pushing up to GitHub or pulling down from GitHub, you're taking your Git repository and pushing it up to GitHub, but those are two different things. Hopefully, that makes sense. So, you'll make some changes and you'll say, "Okay, I'm ready." You save to a save point here and then you say, "Okay, package up the new save point and I want you to take this and push it up to GitHub." Now, GitHub has this and your local version, your local machine has this. Now, let's say that you've got an AI agent that's doing the exact same thing. So, I'm going to grab all this. We're going to come over here and we're going to do the exact same thing. So, let me grab this, move it like this, and let's say your AI agent is doing some work, and they come over here, and they say, "Okay, I'm going to pull down the most recent changes." So they put pull down number four and then they add to it and they add a number five to it. Oops, pulled the wrong thing. All right. So I'm going to grab this right here. Pull this down and we'll put it over here. So they started here and now they built on top of it. Or maybe let's do the same order. So they say, "Okay, I've got some new changes that this remote h doesn't have the actual cloud and you don't have on your own machine." So it says, "Okay, I'm ready." I save it and I commit it all the way back up to GitHub. So I push it back up after I commit it. Now, the trouble is it still has, if I can put it back there, it still has it on its kind of local version. The cloud up here has it, but you don't have it. So, anytime you're working with another person or another agent, you typically want some kind of cloud where you can kind of decide that's where we're going to sync all this stuff between. So, once it pushes it up here, before you ever do more work, you want to pull it down. If I can grab the right thing, you want to pull this thing down, uh, and put it down here. So now you're working off the latest branch, the latest commit that is. Um, all right. So hopefully that makes sense. You've got individual code. You've got your own save points. You've got somewhere then that you can kind of sync between. And this is ends up being kind of the place that you first say, "Hey, do you have anything new?" Uh, yep. Okay, I'll pull that down. Then I'll make changes. And then maybe you make another change. That's number six over here. And you say, "Okay, I'm ready to commit this." So you create another save point. And then you're ready to push it up. So again, you're going to take this and you're going to push it all the way up to the cloud. Now, your agent or another teammate before they start to make changes, they'll first pull down and say, "Hey, do you have anything new?" They say, "Oh, yeah, I do. I've got this number six." And you say, "Perfect. Uh, I wish this thing was easier to drag." There you go. You pull it down and now they can start and they add on top of that. So, this allows you to stay in sync with other teammates. So, that's the basics of Git and GitHub and why it's helpful and important. Now, the reason that it's especially helpful once you start working with lots of people is a lot of times you have multiple people doing stuff. Now maybe these are agents that you have uh ser serendipitously named or maybe they're just other people on your team. There's this concept of branches and that's what I want to talk about next. Typically you have something called main or master and most of the time this is called main these days and main is kind of the final source of truth. This is the latest code that's published, right? So you might have other code you're working on but it's not quite ready to publish. And this main branch, this is why it's called branch. you'll see that there's kind of these alternate realities. Now, this main branch carries all the different versions inside of it, right? So, like this, it carries all those right inside of it. If I can make this smaller, I don't know. Okay, so it carries all these inside of it, but it's the last one that kind of matters, but inside of main or in fact any of these branches, they have the same kind of sequence. They'll have their own save points, right? But this one is the one you're kind of is the latest source of truth on the main branch. Hopefully, that makes sense kind of how we're getting there. Now, what happens is you'll be working along and let's say you're right here before all these other things exist up here and Nicole says, "Okay, I'm ready to kind of create my own side project." So, maybe Nicole says, "I'm going to create like a navigation bar." So, Nicole goes to do that and the codebase continues to develop. More people add and remove files. These are individual save points now kind of each section here. And Sarah says, "Oo, I'm going to add a footer." And so Sarah does that and then there's some more changes. And then James says, "Oo, I'm going to do something else." And you'll see that now you don't just have one source of truth. You kind of have these branches that are alternate realities. They started with whatever the code was right here. Then they branched off, did some stuff, but they've kind of missed everything until they decide to push back in to merge back in. So I'm going to take this and let's say Nicole is finishing her work and she says, "Okay, I'm going to merge back in up here." So she can package all this up, all her commits up, and she says, "Okay, I'm ready to ask Maine, can I take my code and put it inside kind of the the final source of truth." So what always happens whenever this happens, this is called a merge. So we've got, uh, pull, we've got push, uh, and we've got commits. These are the individual save points. We've got branches, and now we've got merging. So when we're ready to merge here, Nicole's going to ask Maine, "Hey, does my code fit with your code? Am I overwriting your code in a way that breaks um like where you're not sure which is the newest? And sometimes that happens, but a lot of times if you're just working on a single feature, it says, "Nope, everything's fine." So, it merges that back in. And that's just fine. But notice all this stuff right here, this whole section, Sarah or Nicole never had any of this section. All this additional code that's been added along the way, she's not had. So, it has to check against all of that and against all of her code and double check that it all works. And so, that's what it's done. Now, let's say Sarah does the same thing, and Sarah's ready to move back in. And so, Sarah does that. So, Sarah brings it in over here, and now she's ready to merge in her own code, but she merges it in over here. So, she started here, but she merges it in before Nicole. So, when she goes to merge hers in, her branch in, she says, "Hey, does my code work here?" And it may or may not. There may be some conflicts we've got to figure out. So, this is what's happening all the time in a codebase. And this main gets to decide kind of what gets published to the to the website or to your application or whatever. So those are a few concepts that are really important. You've got your individual save points, your commits, your pull, your push, some kind of remote, and that way you can synchronize with other people, and then branches where you can kind of go do your own individual things. U which we kind of demonstrated up here as well. These are technically kind of branches as well. Now, finally, the way this actually works in practice is that you will often have conflicts between things. So again, we've got these kind of individual save points. Now we're going top to bottom like we did just up above. And we hit this point where let's say this is Nicole says, "Hey, I'm ready to actually build a hello.html page." Maybe she starts to do this not knowing that somebody else has both created one and merged it into Maine. Now, hers is going to conflict with this one in a way that maybe they're not, you know, GitHub or wherever you're syncing your code isn't really sure what the latest source of truth is. So, when Nicole goes to merge this back in, maybe even just right here, it says, "Whoa, you got to decide who wins. Does Nicole's code win or does the code that already exists now inside of main win? So when that happen, it's called a merge conflict and basically GitHub or whatever your or git itself your tracking system um or sometimes this will happen on GitHub. It'll show you there's a git conflict. You get to decide what parts of it when does the whole file win? Do the new changes win? Do the old changes win? And so this is when uh you're kind of merging stuff in. And that makes a lot of sense, right? You've got to get it to a point where you can kind of decide what gets to be the source of truth. Now, let's say that Sarah then brings out over here. Was it Sarah? Sure thing. All right. Sarah says, "I'm going to create a world.html." This is her own little world over here. Nobody else has a world. HTML and it's just fine. And so, when she goes to merge it in, you wouldn't expect there to be much conflict. And in fact, there's not. Now, in between when she got her code, so this is where it started with whatever code was here and then she added to it one document. There was another document added on the main. All right, somebody else had done done this. So when she goes to merge it back in now, this new file was there that wasn't there before, but it doesn't conflict with her. That's totally fine. Now, at this point, you'll notice that James has pulled out both hello and new, and he's not creating these new. He's just changing them. And when he goes to merge them back in, as long as nobody else has touched these two files, he should be able to merge that in just fine. So this whole tracking system allows not only you to work by yourself, but also multiple people or agents to work on the same codebase in a way that allows you to never overwrite somebody's code. And in fact, you can still go back in their version history. Now, just like we saw with this system right here, again, all of these branches kind of have their own individual save points. When you go to merge this in, there's a few different ways to do this. Not to get into the weeds too much, but um sometimes you can say, "Hey, give me all six of these or however many safe points you had." in Nicole's branch over here and just stack them one on top of the other so that I can kind of see them all in the history of Git. There's another thing you can do which is called to squash them. You don't have to remember this part, but just to say that you could say, "Hey, I don't care how many save points it took Nicole to get here. I just want the latest one and we're just going to call it one or whatever you call it at that point. That's the only one I want to kind of merge in uh into Maine as we kind of stack these up." And so you don't know how many it took Nicole to get here. You just know that by the time she merges it in, there's just a single one. And you can kind of go back in the version history here. So hopefully kind of switching from going left to right to now going bottom to top as far as the save points make sense. So if we were to continue it, this is kind of the idea is vertically as we move, we're saving one after the other. And as things are merged back in, we get to kind of pull on that code. So I hope that makes sense kind of conceptually how Git and Git tracking works and why it's so important. Again, if you're working with agents in particular or with other people, it's really important to have these save points or even if you're just working on your own codebase so that way you can always go back in the history if you need to and pick stuff up. Let me know if you like these kinds of videos. I don't typically do these like super introductory videos, but I think it's so important and I've explained this to a few developers recently or those just starting to touch code that I figured it was worth doing some kind of video uh for everyone else. All right. Well, I'll catch you in the next one. Thanks for watching. Happy coding.