Getting Started with Git for Game Dev | Quest to Compile

Key Takeaways

Version control. >> [laughter] >> You're not supposed to don't laugh at the intro. >> No, it's fine. >> [laughter] >> Okay. No, version control, Stacy. You know, you've used it, right? >> No. >> You've heard about it. >> not. >> No? It's highly marketed. It's a very important thing. >> Here, doesn't it say, "Don't you work on the GitHub team?" >> [laughter] >> Yeah. I mean, um but you know what? Version control is different for game devs and for, you know, non-game devs, let's just say boring programming versus fun programming, right? [gasps] You know, cuz you have to deal with large files, assets, you know, binary stuff versus just code fragments and, you know, and things like that, right? So, and then you have the other decisions, centralized, distributed. What do you do? >> I don't know. I don't think anybody knows. >> We're going to look at that and [laughter] best practices here on this episode of All right, welcome to this episode. We're going to talking version control. >> Ooh. >> So, it's important, Stacy, right? >> Actually, yes. It is genuinely, all jokes aside, incredibly important to use version control for your projects. >> Yeah. And you have some slides you're going to show us. >> Yes. So, >> terminal usage, right? >> I know. There's uh there's lots of ways that you can interact with in version control. So, so just to set the stage, we're going to be focusing this episode on Git. But before we jump into how you can set up Git for game development, we did want to take a moment to acknowledge that Git isn't the only option and talk about kind of the pros and the cons between the options. >> Yeah. Looking at what they do, what they offer. >> Mhm. >> Yeah. >> Yeah. So, let's start with that. >> Okay. Yeah, let's switch over. >> All right. So, um really in the version control land, especially when it comes to Well, actually not even game, film, too. Uh there's two options. There's what's known as centralized version control, which is uh SVN and Perforce, and there's also distributed, which is what we talk about when we talk about things like Git. So, the way that centralized word works, excuse me, is that there is a server that acts as the single source of truth. What What I mean by that, Andy? >> Single source of truth, that means that one copy of the data is the source of truth. So, everybody has to clone that they have to work with that centralized system, checking files in and out. When one person has that checked out, no one else can have it checked out. So, it's centralized. >> Yeah. Now, this is really good for binaries. So, in game development, you're usually working with images and sprites and audio files. And these things can't be merged together. So, you do want to reserve or check out those files to prevent a merge conflict from happening. >> Yeah. >> And centralized is fantastic for that. That's why artists have a tendency to prefer centralized over distributed. But, this also has a downside for programmers. >> Yeah. You want to know what that is? >> I would love to know what that is. >> I don't know what it is. What's the downside? >> [laughter] >> No, the downside is that, you know, as programmers, especially those on a team, you know, we may be working in the same files or in the same areas, right? >> Yeah. >> We may be coding the same aspect of an app or working on some sort of integration API or >> An app? >> In a game. In a game. I know, I don't get to call myself a game developer professional. No. >> [laughter] >> You make games. >> game, you know, you might be working on you know, logic for how the monsters react, you know, to the player or how >> up items, but somebody else may be doing the same thing. And that's not good because if somebody has it locked out and locked down, you can't do your work. You'll have to move on to something else. >> And the reason why, you know, that this is Yes, not good because the locking part, but also like text files are inherently mergeable. So, it's pointless to have to block somebody out from editing the same text file or code file that somebody else is doing because you can merge those super easily. So >> that's where distributed comes into play. So in the Git land, we have this concept of a repository. And Andy, fill us in. What's a repository? >> Yeah. So repository, I mean if you see the nice little dotted lines that are on there. Um with a repository, it's the source source of truth in that say in that sense that it's a sinking point. Everybody is actually their own source of truth, but they're going to base that truth on a central area which would be the Git repository that everybody is syncing with. But everybody has their full copy of the repo. They're not checking individual files in and out from the source of truth. They are a source a source of truth. >> Not the source of truth. >> of truth to the project. And so therefore Stacy and Andy can work on the same aspect of the game. We could actually work on the same code file and when it gets to the point where things are going to have to be merged back up to the source of truth or the the remote repository >> Central article. >> then we have what possible thing can happen? >> Well, we could have a merge conflict. >> conflict. So yeah, and but there's since we're working with text files and things like that, um you know, it's easy to fix those little merge conflicts through like a diff editor or something like that. >> Yeah. So what's really nice about distributed is you can because you have that full repo locally on your machine, you can diff between different versions of that file super fast or even change to a different uh commit or you know, part of your branch. We'll talk about branching later, but you can change on these super fast because it's all locally on your machine. Now within centralized, you have to have a connection to that server to that source of truth. So for some reason the server's down, your internet goes down, I don't know, you're one of those people who want to work on an airplane. I don't really understand that. I like to play games, but like hey, you know, that's you and that's your thing, cool. can't unless you have the internet and a connection to that server. >> So, >> So, it's a barrier. The internet would be a barrier to doing some coding or something like that when you're working with a centralized repository. >> Yes, exactly. Now, distributed, we've talked about kind of a lot of the perks behind it, but you still do run into the the binary asset problem. >> Yeah, because you can't really you can't really merge two different binaries to to a to a single source of truth, right? Cuz it it would corrupt it. >> Yeah. And by default, uh Git does not have this notion of checking out uh or locking, I should say, a file. >> Yeah. So, if you had a binary file and then Git you were you were to edit it, and then someone else edited their copy of it, you can't really fix that merge conflict, and so the solution would have been, well, like the centralized does, you wanted to reserve a lock on that file just to let others know, "Hey, I have this file and I'm working on it. Don't touch it." >> Yep. Yeah, so um you know, I said earlier that I didn't know anything about version control, obviously that wasn't true. But, I actually worked at Unity for many years, and I worked in DevOps for game development, uh building services. And so, I talked with a lot of game studios about what their practices were. Did they prefer centralized? Did they prefer Git? How did they work? And what we saw was a lot of developers, so the artists wanted a centralized solution for the reasons that we just talked about, and the developers hated it. >> So, they were running into these problems, but nobody was actually like trying to solve it. >> They would do a bridge. So, the developers would get their Git worlds, >> Uh-huh. >> and then the artists would get their centralized world, and then they'd have this really finicky bridge that kind of connected the two. Uh which I always thought was pretty fascinating. Other teams would do, literally, and this is pre-COVID, but literally a pass the tokens. So, they would have a tray out, and they would have tokens that were like labeled with something. >> Like the feature or the area. >> the assets. And so, cuz this is really big with um like Unity, cuz Unity is very hard to merge together. And so, yeah, if somebody would take the little token, and if they had that token, that was the sign >> didn't go work on it unless you could grab a token for >> grab that token. >> so Yeah, I mean, it's cool in a way. >> It was It was. Um and then some people did like crazy spreadsheet management. So, you know, there's there's a lot of kind of chaos in those >> trying to solve this solution for a long time. So, >> Um so, there is now All of that said, there actually is a feature that you can install within your Git called Git LFS, which we'll get into kind of towards the end of this, but that does add locking capabilities to assets that you define within Git that you want to lock. >> You know, well, let's we should actually show people like, "Hey, how do I even get started with Git? How do I How do I get that? How do I create a repo and and stuff like that?" >> let's let's back up a little bit here and start at the beginning. Which is how to create a new repository. So, >> So, you're on GitHub right now. >> I am. Okay. Um and so, creating a new repo, we could You just go um you know, there's a new repo button. It's big, green, beautiful. Uh and it's going to take you to this form. >> Okay. >> And I'm just going to add uh we'll call this, I don't know, uh Git repo demo. It's not the best name. We'll call it that. Uh you will learn very quickly I am terrible at naming things. >> Well, I'm I you could always use the example name right there, Symmetrical Octo Carnival. But no, I think you just stick with yours. Just stick with yours. >> Well, let's go with it. Um so, within here you have settings that you can do. So, you can make this a public repo, which anybody could go and view, or you could make this private so that you control the access to it. Um you can also set a template. So, if you're finding that you're creating kind of the same repos over and over, >> the the template, see what you got. >> I don't >> You got there? >> Oh, here we go. Let's zoom up. >> There you go. So, these are different probably templates you have access to somehow. >> Yes. >> You know, either through your account or public or something like that. Yeah, it looks a little bit more code spaces and stuff. So. >> Yeah. Um and then you can add a readme into it. So what's a readme? Why would you want to do this? >> Well, anytime somebody visits your repo, you know, public or private, whether you shared it to a friend or a teammate or something like that, you know, the readme kind of gives you an idea of, "Hey, this is what this repo is about. This is the type of things you're going to find here. Is there any little bit of guidance that somebody needs to know with getting started with your stuff? Like prep steps or even running an app, you know, or something pre before you start coding, you know, that kind of stuff?" >> Yep. So it's great just to kind of get started. I think talking about the different tech that something might have to usually goes in here. >> ever create a repo without a readme. >> Yeah. >> It's so annoying. >> Yes, it is. It is. I'm going to create this repo without a readme though. >> Good. [laughter] Good. >> Cuz we're going to show >> that you can >> We're going to show our workflow. >> all convention and sensibility, but it's fine. >> I swear there's a purpose. And then the gitignore is really, really important for your projects. Now, what this is going to do, there's a lot of templates here we can actually look up. There's a Godot, uh there's a Unity, even if you're just doing Visual Studio, um there's a lot of kind of preset starter, I like to think of it as kind of starter uh ignore files that you can put in. And what this does is this adds a convention of different types of files that don't get checked into git when you go to to sync up between your local and the remote. >> Yeah, cuz git's going to git's going to be based on the repository is going to be based on a single folder. And your version of the single for your copy of the single folder may have uh artifacts, configuration files for your IDEs and your editors and and whatever that you just don't want checked in. You don't want to send those to other people who are using the repo. So, that's what the gitignore. It just ignores those files. It doesn't even prompt you, like, "Hey, you got a loose file that you haven't checked in yet." Or, you know, it's not going to be tracking these files. >> Yeah. And there's in game development, so I'll I'll Unity as my example, there's a lot of stuff that Unity will just handle for you. So, a a really kind of common or classic one within Unity that you never want to check into get is the library. And that's because when you go to open up the Unity project for the first time, Unity is going to recompile everything and it's going to it's just going to rebuild the library folder. >> Got you. >> I think I said file earlier, but folder. It's going to rebuild that that folder for you. So, you never want to check that into get cuz A, it's just going to blow up that footprint. And then you're going to have every single version of of the files on it. >> Yeah. >> And and Unity will just handle that for you. >> in .NET apps or programs or games that there's the the bin and obj >> Ah, yep. >> obj [clears throat] folders. So, those are all the compile time assets that are transient files that it's creating to compile your game and then actually to run it in the debugger and you don't want those checked in either. So. >> No. Yeah. Yep. So, it is. So, I am not going to add an ignore to this project. It's so important, but I'm not going to add it. Um, and that's because I want to show there's there's actually two paths that you can take when you have your repo created. So, I'm going to go ahead I'm going to create repository. Oh, I'm going to select myself and then I'm going to create repository. It's just a >> You're the owner of your own Git domain. >> am. So, you'll see one of two views. This view we see because there's a repo that's been created, but there's literally no files in it. I didn't add an ignore, I didn't add a read me. This is just an empty space, if you will. >> Attached to your account, ready to ready to go. >> Yeah. And that's because the workflow that I want to show is um, associating an existing local project with a Git repo for the first time. And that is done through the initialize command. But there's another one. >> Yeah, and you know, when you have a repo that's there already, you know, you're not you're not going to be creating a new repo every time. Like you know, you've created some stuff, you put some up stuff up there and then you invite me. Like say, "Andy, let's work on this together." I'm not going to initialize a brand new repo. I'm going to be using yours, right? So then I'm going to clone your repo to my local machine. So, but we have to start somewhere. >> Right. So cloning is for when you're pulling an existing repo down from the remote repository onto a local machine. >> Yep. >> And then in it is the flow that we're going to walk through right now, which is there's nothing in this repository. >> Yeah, and you don't even have to do You don't You don't even need a GitHub repo to do this. You can do this on your own >> Ah, yep. >> just to track just to track changes for your own stuff. Even if you're not going to be sending it to anybody. And that's handy. So we'll probably show a little bit of that, but >> We will Well, yeah, we'll show the we'll call out that workflow of when you were It was funny though is I actually never thought to do this until you mentioned to me one day that you did that and I just I don't know for some reason my brain had always associated get >> have a >> I must have Yeah, exactly. And and we were talking and you're like, "Oh, no, I do it I do it all the time for any project." And I was like >> First of all, I don't sound like that. I don't go, "I do it all the time." >> [laughter] >> Okay. It was more like, "I do that all the time, but why don't you?" >> But this is actually a very accurate >> [laughter] >> recap of the conversation. Uh okay, all right. So let's jump back in. So within that page that was created there is a um a URL. >> Yeah, and you know what? This this page gives you a lot It GitHub does a great job of getting you started regardless of which path you're going to go. >> Yeah. So Yes. And so what I'm going to do we're going to we're going to pop over to the terminal, but the first thing I want to do before I move over to that is copy this URL, which you can just click this copy button. And then if we switch to the terminal, I'm actually already in um in a directory that has a game. This is the the series that I did pretty recently the the Godot getting started C# Essentials series. >> Okay. >> I think I merged some words in a really weird order there, but >> So you have this code, but it's not in a Git repo. It's not on a GitHub repository remote repo either. >> It is not. Um what I will say that I did is I do have You can see uh right here, I already have a git ignore in here. >> Okay, yeah. >> And that's I just put it in. You can go after you've initialized a repo, you can go and pull that. It's a like a long URL, so I didn't want to type it in, but you can go and kind of pull in and ignore at any point time. You know, you can just create this and manually >> Well, even if you're working in dot the dot net just a dot net command line, you know, you can add you dot net add and or dot net new >> Yes. >> and you do a project, you can type dot net new git ignore and it gives you kind of a Visual Studio style ignore already go that's going to ignore all the binary files and obj folders for you automatically. >> I had no idea that was a thing. >> Yep. >> Wow. >> Super handy. >> That sounds like it. Okay, let's let's take a quick look at the ignore. >> Okay. Pop it up. >> All right, so here is the standard Godot ignore file. I don't think I changed anything in this, I want to say. >> Okay. >> Uh but you can just see it's it's just ignoring the import. Um >> Ignore that folder and these are glob patterns too. So you can use star star slash to ignore all sub folders from a certain folder and and and and stuff. So it's not just wild simple wild card. It's it's full glob wild cards, which is great. >> Yeah. So that is the ignore file. Now let's go back. Um into this and we're going to do we're going to do a git init. No URLs just now this if we go uh directory What did that do? >> Yeah, so it created that it well, you don't see anything right now, do you? No. No. Cuz it creates a folder that's hidden. >> It is. Is there a way to unhide a folder? >> Yeah, do DIR and then I think dash all A for for all will get you there. >> You lied. >> Oh, uh dash hidden. That'll show you the hidden ones. >> There we go. There we go. Dash hidden. Now we can see it created a Git folder. >> Yep. So you have a Git folder now. >> All right. So we can now add the remote. So if I do Git remote add origin, what is this doing? >> It's you've already typed this in before and it's auto-completing it for you. I thought you never tested [laughter] this. >> I have never done this before. >> Except your repo is Is it this Is that the right named repo? >> No. >> Well, so let's see let's rewind. We're going to need to do >> No, no, no, no. I pasted the right one in. >> Okay. You just said it [laughter] isn't. I asked you, is that the right repo? You said no. You physically said no to me. Okay. All right. That's fine. >> [laughter] >> Continue. All right. So Okay, you got the remote. You added it. So that's this is going to link your your local repository with a remote repository. >> So now there's a connection between the two. >> Yes. >> Yeah. Okay. So we've already talked about the Git ignore. Now if we do something like Git status, this is going to show us that we have literally everything in this this folder untracked. What is an untracked? >> Yeah, so So well, Git ignore prevents a file from being looked at by Git automatically. An untracked file means it's something that's here that I think you want to add. So it's not being tracked, but you have the option to track it, which would be adding it to the actual repository through a commit and then basically tracking the change path through, you know, of the file. >> Yeah. So you used a a special word there, add. >> Add. Git add. >> Git add. So I'm going to type this. The period slash is going to say do everything. And again, it is not going to do the things that are in the Git ignore. >> Correct. >> Yeah. >> Yeah. Yeah, it doesn't even show them as being in the tracks that the stack Git status never lists things in get ignore. >> Exactly. So now if I do get status we can see every one of these is listed as a new file. >> And cuz you have the cool terminal stuff right there it tells you that there's a 140 new files that are currently going to be added. >> This is true. Andy is all super happy about this cuz he helped me. >> I did. >> With my terminal look cool cuz his looks super cool. Yeah. >> Okay, so I'm going to do I'm doing um a a word here get commit. I think we've even used the word commit several times haven't we? Cuz it's really hard to talk about get without talking about commit. >> I know I've tried and I'm like >> I don't know >> Can you commit before it gets? I don't know. >> [laughter] >> How can you talk about get without branch and merge and commit? You can't. >> I know. There's a lot look viewers there's a lot to get a lot. So don't get overwhelmed. Just start basic and eventually you learn you learn how everything's working. >> Yeah. Uh I will say like it's super easy to get overwhelmed with all of this. >> Yeah. Yeah. >> Um so what is commit? >> So commit is going to take everything in that change set 140 files and it's going to create a uh a commit. >> A snapshot is the way I like to think about it. >> good. Yeah, it's going to it's going to lock all of those files in the way they were at that time and put them into your history. >> Yeah, I love to think about get I love time travel. Like I I just am absolutely fascinated by the concept of oh and many worlds. You know all those about me. >> I I kind of did. But >> going to say I like I feel like you should be well aware of that. >> You always talk like you're from the future. >> I am from the future. Uh I would >> [laughter] >> um don't get me going on many worlds. Anyway, uh but the point is like I like to think about get as as a um as a a timeline. Right? [clears throat] Like that's ultimately what you're you're dealing with right now is a timeline that you're creating when you do a commit. You're creating a a snapshot or a place that you can go back to in time. >> Why don't you do get status real fast. >> Yeah. This is going to be fun. Oh. Oh, dear. >> Nothing to commit. Working tree is clean. So, as soon as she if she changed a file, if you changed a file, Stacy, it would suddenly list, "Oh, there's one file that's been changed." because it's looking at the previous history, the last commit, and to see what's different of your working directory versus what was in the history tree. >> Yeah. >> So. >> Yeah. So, actually, what we're going to do right now is we're going to do a get push, and push is another one of those commands, and I'm also setting so so push is basically saying, "I'm going to take this thing from this commit." and I could have many commits before I do this. >> So, I'm going to take my my whole tree. >> My whole >> My work my working history tree. >> Yeah. >> And I'm going to what? >> Send that to the remote. >> To the repository. And that's what you're doing. Well, you'd already added the remote earlier. >> Yep. >> And so, this set upstream, this means like this is my default. You're you're kind of setting the default for this branch of main when you want to push to a remote. You're pushing it to origin, which was your the name of your remote, and to the main branch. So, you're you're now linking your local to that remote. >> Yep. And so, now we can see it's pushing everything up. So, if we were now to move back to the repo and do a refresh of that page, we're going to see all of the files here. So, whole different view, and that's cuz everything that I just had in that commit is now here on the uh remote repository. >> Nice. >> Still no read me. >> No read me. >> How's that make you feel? >> It's dirty. >> [laughter] >> Um you should click that green button, but I I have a feeling that you're going to show us something about creating a read me eventually. >> absolutely not going to do that, but I love that you think [laughter] I will. Be strong, Jen. No, we're actually going to go into talking about branching now. >> Okay. Yeah. Well, you know what? Go back to the web page real fast. >> Uh >> Let's go back to GitHub. Cuz there's something at the very top of GitHub where it says right here. >> Oh, you're talking about this? >> Yep, there's a commit hash and and 2 minutes ago. It says 2 minutes ago that that was pushed. So, that was that's what the current state of the branch is is that commit. >> Yeah. >> That history. >> Well, now we're talking about the word branch and I want to have a conversation about what what a branch is. >> You want to talk about that now? >> Yeah, I do. We've talked about >> launched my paperclip somewhere. Anyways, it's fine. Ignore it. [laughter] Um Yeah, go to branch. So, go yeah, go back to let's let's check your slides out. >> All right, so I do have a I have a diagram. >> Ooh. >> I know, isn't it so pretty? >> So, what are all the dots? >> The dots are commit points. >> Okay. So, if you made another commit earlier and cuz you made one commit, but if you made a second one, that would get a whole new hash and that would be another dot. >> Yes. >> Got you. >> Yep. >> Okay. >> And so, you know, I was talking to Andy a little bit. I was like, man, how do you describe main? >> Mhm. >> And I think I came up with the word stable. It's like your stable branch. I don't know. Like, I still don't know how to describe main. >> like your analogy. I'll just tell you. >> Then what? >> Because you just used two horse analogies, [laughter] main and stable, and that's just just too confusing. >> Okay, all right. I'm all ears. What do you have? How do you explain main? >> You can't. It's unexplainable. >> [laughter] >> Well, so you needed to you needed to you needed to designate a primary branch, right? So, you have a source of truth of the repository, the remote, but then you need a source of truth that's which branch is the source of truth, right? It's a very convoluted way to say it. >> Hopefully that makes sense. >> about? >> I think it'll make more sense when we talk about the concept of actually branching. >> Yeah. >> Okay. >> Yeah, yeah, let's let's just go back to that. >> So, you I I still think stable is the right way to think about it. Your main branch is considered >> I say primary. >> primary. I both, right? It's your primary stable branch. And the reason >> You see I mean non-working branch. >> No. >> Okay, I go go ahead. Just [laughter] go ahead. No, you know, finish your presentation. >> I'm going to finish my thought. >> I'm wrong. That's the classic line from our childhood. >> Let's uh let's mark that on the calendar. Uh the day Andy said I was right. >> I said it any time. >> the moment. Okay, now I have to remember my train of thought. >> But you're saying so main branch is like stable is what you said. A stable. >> So the reason is >> I just think horses now when >> [laughter] >> You mean something that doesn't fluctuate. >> Well, I mean something that you can trust. >> Yeah. >> Right? Like when you have a game and you go to build your game, when you're going to go and build and release that game to your public, you're going to build it off of your main branch because that's stable. That's the thing that's been battle tested to make sure that it's not going to crash and not going to have bugs. >> So when somebody comes in fresh, they know main is going to be the stable version of >> your project. >> Yes. >> Got you. >> Exactly. That's how I think about main. And you know, the the reason is because at any point during those like little circle um you know, hash commits that we have on this timeline, you can go and you can branch off of those. So for example, if I want to make a new feature, let's call it I don't know, player shield, I can at some point in that commit history, usually at the latest that it is, but that doesn't visually show. >> started with your work, probably. >> You would branch off and you could go do stuff and you can mess around with that branch and trust that you are never going to impact the main stable branch in a negative way. >> Got you. >> Um and so you can make whatever changes that you want and you know, you yes, you're going to want to test this and make sure that it's legit before you push it back into main cuz you know, that's annoying. But uh but at some point when you're done, when you've made it through all of your changes, you're going to you know, go oh okay, this is great and you're going to you're going to merge that back into main. That's where we're talking about earlier, the merge conflicts and the things that you can run into. This is the moment where one of the moments I should say where you could potentially run into those merge conflicts that you have to deal with. >> you bring it back into main. >> Yep. The other point is when you're working in a branch, you can actually bring changes of main into your branch to keep it up-to-date with main so that when the time comes to merge back into main, you're not dealing with quite so much stuff. >> Okay, yeah. That makes sense. >> See, that's why I said stable. Not crazy. This time. Okay. >> [laughter] >> I know you're full screen, but you should have seen his face. Um okay, so let's go back into the terminal and what I want to do is show how you can actually make a branch on your local repository. >> Okay, yeah. So, we're going to kind of simulate what you showed in that diagram. >> Yeah, pretty much. So, we're going to do get checkout. That's the keyword and B. And then you want to name it. Um I guess I have adjust player. So, it's somewhat simulated. It should should say shield. But now I am on a new branch and and again, I have kind of fancy terminal stuff, but we can see that I'm on a new branch. >> now the name of your branch now. But if you don't have a fancy terminal stuff, how do you see the name? You don't know? You [laughter] don't know this? Just get status. It'll tell you where you're at. Does >> I always do get list. I think it's like get >> On feature on branch feature I've never even seen >> No, I think I I think I merged it in. >> made it up. I think [laughter] you made the command up. That command does not exist. >> That's the one I'm thinking >> I thought you were about to show me. It's get branch. >> branch? Oh, and list. See, there is list. >> It it's a parameter, correct? >> well, I merged it together, but >> I'll show you it real fast since we're here right now. You know, maybe some people have been like watching and like I know it is this is so boring. But you know what? Showing some new commands maybe they don't know. I like get branch dash VV. >> VV? >> Yep. And that tells you that shows you where your branch is mapped with your remotes. So, you can see main is mapped to origin main. And that's where that's at. And then your current feature branch is not mapped to a remote yet. It's just local. And you can see the two commits that are the same. >> Yep, and that's because there's no version of that. >> There's no changes yet. >> Well, there's no changes, but also we've never pushed this branch up to >> Exactly, yeah. It's never been sent anywhere. >> Um >> anyways, yeah. Cool. Cool bit. I like that one. >> So, there's new no changes. So, let's actually make a change. >> Okay. >> So, I have the player script open right here. And I'm I don't know. I'm just going to make some random We're going to make him jump barely off the ground, but you know, walk really fast. So, I've just changed a couple of properties. >> No idea what you changed. >> [laughter] >> I changed base movement speed and jump velocity. All right. So, if we come back into >> so you changed Okay, so these are the properties of the player that you're changing. So, okay, okay. >> matter for the the point of this. The point is I edited the file. >> Got you. >> Uh I don't want to go down the path of trying to explain how the game works. >> No, no, it's fine. >> [laughter] >> It probably won't work anyway. Anyways, >> Whoa. >> Uh so, okay, I modified the script. >> my stuff. Thank you. >> You don't have to defend everything. >> [laughter] >> Okay. So, Okay, you now you got a changed file. >> Yes, now it says Remember earlier we saw new? Now we're seeing modified. >> Not Yeah, we saw new file untracked. We saw untracked. >> Untracked and then we saw new new file. >> and then now we have modified. >> have not modified. But again, we'd have to add this and then commit it. So, we can do get add and then again, I just I'm like a period slash kind of person. Uh and then again, if we check status, we're going to see now it's green. Why is it Oh, cuz you're saying untracked. Yeah, so it was >> Yeah, so you have a changed you have a a modified file that's not has not been added to the like the the I don't know what the word is. I can't think of it, but it's the workspace or the the tracked You you're now >> Staged. >> You staged. That's the word, staged. You've now staged the working copy of that file as it was at the state at the time you staged it. >> Yeah. >> So that you can then commit that into a new commit. >> Yeah. >> Cuz if you go back and edit that file again, you will have No, don't do it. This is going to get derailed too much. Um but if you went and did that If you went and changed that file again and you did get status you'd see both. You'd see the pink one and the green one because now you have modified the file after you staged it. >> Yeah. >> Right? So that gets even more confusing. So we should keep talking about that. But anyways, let's move on. [laughter] So yeah. >> Okay. Um so now I still need to commit it, right? So get commit and then when you're doing a commit you need to provide a a message. What's some best practices for messages? >> Well, don't just say stuff or Don't don't say that. No, don't do that. Say adjusted player >> Is I just did the movement >> something descriptive. Something descriptive. >> And jump >> Yeah. >> uh parameters. >> Yeah. There you go. Good thing you spelled everything correctly. >> Parameters. I was trying to figure out if I did. I think I did. Uh get push origin. So I don't need to set the upstream cuz I actually have a setting turned on that is automatically going to do that for me. >> That's the default. >> No, it's not. >> I'm sure it is. >> Yeah, I know. I I went through it. It is not the default. >> No. >> Yeah. Or maybe it's a default and it got shut down or shut off on some point, but I had to I had to redo it. >> Oh yeah, you know what? I think it is not the default. You're correct. Yeah. >> Um so you could run into you know you could >> I'm wrong. >> My god, twice. >> [laughter] >> Merry Christmas. >> Anyways. So you get some status back. >> Yeah. Oh, yeah. >> Which tells you what? Okay, new branch was created up on the remote. Uh it looks like GitHub is also responding with a hey, if you want to create a pull request click this button. >> Yeah, let's actually go >> Is that in your script? Are we talking about that next or what? What did it I just jumped ahead. Oh, wait. I guess ruined. >> Yeah. >> Oh, good. >> Yeah, you did ruin it. Um all right, let's go actually >> Oh, you're going to go to the pull request. >> Yeah, we're going to go to the pull request. >> knows too. >> Well, before we go to the pull request I want to go to the main one. >> Oh, and just look at the branch. >> Yeah, so like you can see here branches. >> branches. >> And now we can see hey this one belongs to me. >> Yep. >> And then if we go into this branch um you can see it's one commit ahead of main. >> Yep. So main being your stable, it's compare automatically compares other branches to main. >> Yep. Yeah. And so we can see uh >> Or your primary, folks, if you're watching and remembering what I said earlier, your primary branch it's comparing it to. I'm giving very snarky faces right now so the editor can put this in. >> [laughter] >> All right. >> Okay. >> So pull request, what is a pull request and why would you want to do this? >> So pull requests is a way to have sort of an approval saying hey I've made some changes to a branch. And then might you know we just did one change, but it may be many changes across many files. And the pull request is letting you have a process of getting that back into the primary or stable branch. Saying I want to merge this in. >> Yep. >> in there. >> I love that you're using primary and stable. I feel like that's a good compromise. >> It's a good compromise. >> so what's also really good about the pull request view is that you can see the list of commits. So if we had done multiple, they would be shown here and you'd be able to dive into them. But also you can see the files that are changed and then go through and do a review. So Andy earlier you said you had no idea what I changed. >> Yeah. This is what I changed. >> Seven base movement. >> I told you it was a >> a comment in there from Andy that says >> terrible >> terrible terrible change. >> know how I'm doing my math. It could be a great change. >> [laughter] >> I'm more concerned about jump velocity. This thing's not going to get off the ground at all. Uh anyway So from here though, you can come back and then do a merge request or a merge pull request. And then it would give you the chance to we'll actually do this. We'll just do confirm merge. I'm not going to change anything here. Uh and then you can delete the branch and now what we would see, I'm not going to do that, but if we come back into the the main one >> Yep. >> we can see >> Look at this. Yep, that's the latest commit. You see the commit that changed and you have three commits. >> Yep. Then then we saw now cuz we've just pulled everything in. All right. So, now I I lied. I do have one more diagram. >> Ooh, I know you do. That's why I did >> I forgot. We're going to talk about Git LFS real fast. >> Yeah, because here's a problem. If you had done that with if you had two people working on this or you're showing your diagram to >> Two people working >> second branch, all that kind of stuff. I thought you had that >> going to do that. Would you like me to show that diagram? >> I think it's really cool. Yeah, you should show it. >> Okay. Calm down. Stop yelling. All right, we're all friends here. >> [laughter] >> This is the diagram that Andy's talking about right here, which is this idea of It's funny cuz you talk about this as if two people are working on the same project. I do this to myself all the time. >> Yeah, yeah, you may flip-flop between two different two different features you're working on, right? So, you worked on the player shield and the inventory, which is all kind of related to each other a bit. It's inventory-ish, what the player shield is, what the inventory is, like >> Well, sometimes what happens, you know, I do a lot of game development and I'll go down the path of maybe it's like a large refactor or something and as I'm working on that, I realize that like some mechanic was broken and so I'll pop into another branch and work just on that and then bring it into cuz you can you don't have to just bring main in. >> Yeah, and so when what happens? What's the problem with this then? >> I don't know what you're asking me. >> Move on. >> I Oh, you're talking about the merge conflict. >> Yeah, the merge conflict. >> [laughter] >> We've already talked merge conflict. >> didn't have the diagrams to show. Come on. These are really great diagrams. >> them very nice. We'll just look at Let's just look at the text one. >> Okay. >> Okay. >> Yeah, yeah, so so yeah, so here if you had if you edited two code files, right? The inventory So, you're editing the player class. You're adding inventory or you're changing the shield or you're changing the velocity or whatever. The merge conflict there's no conflict because if you look at the text here, you can see you can change one line and it didn't affect the other line. >> Those are two separate lines. >> So, it can figure out, automatically, where to merge them. >> Automatically. No conflict. >> when would you hit a conflict in a text file? >> edited the same lines. >> So, if I changed int shields value in the player shield feature, and you changed the shield value, which would be weird, in the inventory, >> Mhm. >> then we would hit a conflict cuz it wouldn't know which one to take. But again, it's human-readable text, so it's pretty easy to kind of stare at and reason about what you're changing. >> yeah, when you when you're resolving a a merge conflict, you're kind of scanning through, seeing the different the changes from either or from both, and then you're you're deciding what what's the actual end result. You're doing the merge, or, you know, to oh, take this one, don't take this one, cut this, move it here. So, you're kind of editing the file as a final pass. >> Yeah, exactly. >> Okay. >> So, okay, so that's I'm going to go to my other diagram. >> diagram. >> So, we talked earlier about that centralized and distributed, right? >> Yes. >> And and I and I made the commitment that there was something you could do to your repo to add the ability to do locks. >> the centralized, the Perforce, that kind of centralized, this problem doesn't exist because somebody checked it out. One or the other is going to win, not both. And that's that's sort of the downside. You want both. You want both those changes to be able to merge together. >> Yeah. >> I I wouldn't say one or the other is going to win because the other one doesn't have the ability to make the changes. >> Well, if you're working offline, it could. >> Oh, yeah. >> I mean, I'm just saying there is a chance, but you're not going to be there's no like I don't know, maybe the centralized sort it does have merge. Let's just backtrack on that. Let's just move [laughter] on. But yeah, but basically, that's kind of the thing. The centralized one is well, one can only be working on that player at once. >> Yeah, I think >> That's the the general design. >> Well, and I think the bigger problem with that, to your point of one can be working on it at once, is you're you're running into Well, now I can't do what I need to do. >> Yeah. Yeah, you couldn't pivot like you said, you couldn't pivot to go fix a bug you just found real fast, and then go back to working on that. And so, but this is the problem with the binary. Even in that we showed it we showed a diagram of the text merge. But, when you go to binary files, that doesn't exist. You can't you can't merge two binary files like that. So, >> Although, I've always fundamentally believed that for 3D assets, you can. I want to >> Well, some of them can. Yeah, that's true. But, >> Okay. Let's Let's talk about Git LFS. >> Yes. So, this is the solution. >> The solution. >> You said that. Yes. Okay. So, we've already talked about the problem. And Git LFS is something that you can install locally actually technically. It's locally on each person's machine local repo, I should say, in order to enable Git LFS. And what this actually does is this replaces your repository. So, let's say you're checking in a 3D model. Instead of that model getting checked into your remote repository, it is actually a pointer file that is getting checked in. And that asset itself is actually getting sent to an LFS server. >> Okay. So, like a separate server that's tracking it. >> a separate server that has it. And so, that's got the versions and stuff. And so, what happens is with Git LFS installed on your machine, it's going to you're going to basically make a request that says, "Hey, I need I don't know, the shield the 3D model of the shield." >> Got you. >> And it's going to grab that pointer and then go and and pull it from it and bring it down onto your machine. So, you will only have that one copy in your current active branch on your machine. And so, this does a couple of things. Yes, it's going to enable locking, which you know, again, is great for the reasons we've just described. >> Yeah. But, it also actually reduces the footprint of what is on your machine. Because again, your local >> Got you. >> repository has every single version. Yeah, it's so your by default your repository has every single file and every single version of a file. >> Yeah. Because of the commit history. >> Exactly. >> Yeah. So, if you have an asset that's 500 megabytes in size >> And that's >> and it's been changed 10 [laughter] times. >> Yeah. >> Then you're having every single version of that on your in your history of your repo, which makes it very large. >> Exactly. And so, Git LFS is a way to not do that. >> Okay. >> Uh within it. So, it's you can think of it as kind of getting both the best of both worlds, right? You got your locking, you have your footprint that's lowered, but now you're getting that that thing that developers love, the ability to I I think that's like moving fast, right? >> Yeah. >> Being able to change stuff. So, uh setting it up is like I said, you're you're going to actually set it up locally on your machine and I'll walk through how to do that. And then you have to push uh what's known as a Git attribute file to the repo. And this is a file that defines um what files apply. >> Got you. >> And also uh a rule. You can kind of set a rule that says, you must uh you must check this file out to be able to edit it. >> kind of like the Git ignore, but Git ignore file that affects what files are affected in the repo or ignored by >> Yes. >> This is a Git attribute. It says, "Hey, treat these other files as different." >> Yes, exactly. As as part of the LFS workflow, if you will. So, let's jump into the terminal. >> All right. >> All right. >> I dare you. I dare you to jump into the terminal. >> Oh, I did it. I'm in. >> So, you're going to install LFS. >> Yeah. So, actually what I'm going to do first, I'm actually going to go back to main. >> Okay. >> I should probably I don't know other branch yet, but we'll just we'll just be in main. All right. So, I'm going to start install it. So, Git LFS install. >> Okay. Installed. I feel like whenever Git responds, you have to use like the announcer's voice. >> [laughter] >> Updated Git hooks. Git LFS is installed. >> no. You need to go with like the auctioneer voice. >> [laughter] >> Updated Git hooks. Okay. >> All right. >> All right. >> We can see it's now it's now installed. So, now if we do Git >> And this is a one-time machine setup. You just do one-time. This is >> machine. >> Okay. >> repo. >> repo >> Yes, it actually is a repo. >> Got you. >> setup. >> Okay. >> Yeah, but yes, one-time. But the important thing is everybody has to do this. >> Got you. So, people this is where your readme would come in handy. Telling people, "Hey, you need to set up get LFS." >> Yes, yes. This is This is a good point. >> solved all the problems with the readme [laughter] right now? >> track. Okay. All right, so what I'm doing right now is get LFS and then I'm setting the word track and this is saying, "Hey, I'm going to set which files I want LFS to apply to." And what I'm adding right now is this is optional, but it's an attribute that says lockable. So, basically by by default if I didn't use the lockable attribute, what's going to happen is any file that is listed here you could just still change. >> You could still change It's still going to make it a remote stored >> file. >> file that is only a pointer locally. >> Yes. But it doesn't prevent >> prevent it. >> the merge conflicts from happening. >> So, if you have big data files like maybe a huge Excel spreadsheet, something really big that's kind of like a just a big file that you're storing in the repo, you may not want to have it in the repo and so you kind of want to shove it off to the LFS server. But it's not necessarily doesn't need to be locked. >> Yeah. >> Like why would somebody use lock Never use lock then? >> I don't know why you The Excel spreadsheet's an interesting example, but >> don't know if I can come up with something to >> Yeah, that's a >> It's a terrible example of a >> Uh I don't know about that. Uh I didn't have an example, so there >> Exactly. [laughter] The lack of an example is a terrible example. >> You will notice in the file, so again this is a Godot project. I have a dot tscn, that's the scene file. >> Okay, yeah, yeah. >> Um and so this is technically a text file. >> Yeah. >> And like Unity's asset files are technically text files, but they're notoriously hard to merge. >> Got you. Because they kind of like have multiple references to things and counters and stuff and like the structure is not >> Yeah, it's just it's just super hard. And there's I mean there's some tools to do it and again if it's smaller I think >> So it's not just necessarily binary files you might want to do this with. It's really stuff that's doesn't merge well. >> Which I guess is you know I'm going to say yes, Excel would probably fall into that category of things that merge well. Anyway, uh so what I just to kind of come back, lockable is basically foreseen the fact that you now have to anything that's listed as lockable now has to be checked out before you can modify it. >> Okay. >> So without it you could modify the file, I could still modify the file. Yes, it's got LFS and it's a pointer. >> you. >> But like it's optional. >> Sorry. >> Yeah, well it's optional if you want to if you want to lock it. >> Yeah yeah yeah, the optional version. Yeah. >> So I'm going to hit these as lockable. And now they're read-only. >> Oh, okay. >> So >> Interesting. >> Yeah. You cannot make changes to these. >> And this makes changes to that get attributes file? >> Yes. >> Okay. >> So now the get attributes file will have these listed. It was still going it's taking a moment, but yes it'll now have these listed and noting that they are track or um sorry lockable. >> Got you. >> Okay. >> Cool. >> So locking and unlocking is super easy. You can just go get LFS lock uh and then I think I have a levels, yeah. So now this file is going to come back as locked and I'll show you. >> You don't have to push this up first or anything like that? >> No, not yet. >> I do want to push this up. Your attributes does need to be pushed up. So yes, I should probably push that up. That was my bad. Um okay, so you can check you can see um LFS locks and now you can see the locks. >> Okay. And so do a get status, huh? I'm just curious what does it say about >> You want to give me a second? Locks taking >> get status. >> Second's taking its time. So now you can see though that that it's locked. Who locked it? >> Okay, cool. >> You want to see get status? Well, now we're going to see. >> We're going to see all those files that were altered. >> Yeah. >> Now, when you lock a file, it doesn't change it though, right? >> No. >> Yeah. So, you could do your Let's put your attributes real fast. >> Push it? >> Yeah. Do get, you know, your get add. >> Yep. >> And then uh commit it. We're going to commit it with a with the >> I can type. Get commit message adding LFS support. >> Yep. There you go. Perfect. Because you know, even if you didn't push it, making big value might sit there and go, "Oh, shoot. I shouldn't have added all those other files. I shouldn't have locked those things." You'd kind of be able to undo that, right? >> Yeah. Actually, but what you're what you're kind of pointing out is something that's really important. This doesn't modify your commit history. >> Yeah. >> So, when you add it into a project like what we just did where we had three commits, well, those three commits still have these files. Yeah, there is no pointer. It doesn't go back and rewrite anything. So, you want to kind of be thoughtful about doing this early in your project. >> Well, yeah. And because too, it has to upload that those files to the server, right? >> Oh, oops. Oh, why did I get this error? >> Oh. >> Yeah. >> Yeah, because you're on main and you never pulled down the changes we made in main. So, it's sitting there saying, "Well, I can't put these commits up there because there's already commits there that you don't have." >> Yeah, so I'm going to do a pull. That's going to bring stuff from remote into mine. >> Yep. >> Okay. >> Okay, so now it's all it's all merged in. >> Yep. So, >> locally. >> Yes. >> And now you want to push those back up. >> we'll do get push origin again. >> Yep. Get those. Send those up there. And now the remote is the same as >> Yeah, now everything's even. So, I add Andy to the project. We're good to go. >> Yep. >> Now, going back to the get uh LFS demo though. So, we had get LFS again. I'm going to bring this up. We had uh oops, I >> locks. >> I meant >> Check locks. See what's in in >> Yeah, we need to do locks. Okay, so you can see that I did it. Now, I can unlock this, of course, cuz that would be silly if you couldn't. Um and so let's just unlock. >> Got you. So then it takes your reservation off of it. Cool. >> Yeah. So I I think >> So that prevents somebody else from That's I mean that's the biggest thing. I'm going to work on this. This is a token. This was taking those little tokens >> Yes. >> out of the tray to say no one else can work on this except me. >> Yep, exactly. Which is important with game development since we have so many different >> different assets and then things like that. >> Um yeah, but I think that's that's kind of it. Uh what I did want to talk about before we completely wrap up are just some game development best practices. >> Okay. >> Um within it. And I think for the most part we kind of hit these as we were going. As you are um doing commits, make sure that your messages are descriptive so that you cuz again, think about timeline, right? If you're looking at a huge timeline with a lot of commits, you want to be able to kind of know when you broke something. >> Yeah. Yeah, >> [laughter] >> that's true. I mean someone's going to break something, so. >> It's going to happen. Um you know, the other thing with game development, uh especially if you're in Unity, I think the Godot by nature is kind of like this with the the how they do nodes and setup, but within Unity, um you want to make sure that you're kind of breaking your assets, your Unity assets down into kind of the smallest part necessary. So Unity has things in it called, you know, prefabs, and you can do nested prefabs, um things like that. So like you you don't want some huge giant scene that's full of stuff that uh is, you know, the original I don't know how to describe this, the original instance of it. Instead, that scene should be composed of multiple scenes that you can kind of add together additively or prefabs that are kind of brought in, and then that's going to also help you a uh avoid merge conflicts if, you know, depending on how you're doing Git LFS, or B, you know, keep it from the lock preventing somebody else from doing work. So like your UI of your main game could be its own scene. >> Yeah. >> And then your main scene, you know, or it can be one scene of like the level and then you can additively pull that in. >> you put the UI in the level, then that makes it hard to edit the level and the UI at the same time. >> Yeah, and and what I said like Godot is great because it the way that Godot works is it's kind of like a one node serves a purpose and and you know, or I should say everything's a scene in Godot. Uh you just just like coming from Unity for so long, sometimes my brain just has a hard time with that. >> Yeah, yeah. >> but like everything in Godot is a scene and you you know, each um node has a purpose within it. So like it it already lends itself really well to like the >> breaking it >> Yeah, the composable structure. Um but I think that's kind of a really important thing to you. Is there any other advice? >> I get ignores >> Oh, yeah. >> from day one and readmes from day one. >> Oh, goodness. Don't don't forget that readme. Never And he'll be calling you up. >> [laughter] >> Hey. >> Readme police is here. Uh also too, you know, committing often. You want to make those commits often um and put them in there because it makes it easier to roll back or to um cancel something out completely and and start over. >> Yeah. >> So. >> Yeah, I think that's that's a really really good one. Um and then again, I think the the biggest thing is make sure that your main stable primary branch I used all the words there. Uh you know, that's the one that you should be able to trust in. >> Yeah. Yeah, so when you if you're going to work on something, you want to branch off into a new branch to >> Yes. >> to package up all those commits into one one unit. >> Yes. >> And then that makes it easy to swap over and not kind of get your history mixed together and and push those things up. >> Yeah. I think that's it. I can't think of anything else. >> I don't think so. >> One of the biggest So, all right. Uh well, thanks for watching. >> Yeah, thanks for coming and uh hope to see you next time. >> Yep. Bye. >> Bye. >> Mhm.