Transcription
Every resource about Git or GitHub. If you look up a Git tutorial, they overcomplicate it. And I've always said this, you might not like this if you're super analytical and you want me to talk like a scientist, but the best way for you to understand me is if I talk to you like you're an idiot. And when I was in college, that's exactly what I wanted for my professors: teach me like I'm a five-year-old, because that's how I think. So I'm gonna break down Git. Instead of you going and watching the six-part tutorial or paying or whatever, it's really very simple if I teach you it in, hey, I'm gonna teach you like you are a child, and you are my children. And if you're my new child, meaning you're just born, then hit subscribe and like the video.
Alright, so this is unscripted. But first thing I'm gonna say, get this out there: Git and GitHub are two different things. I'm gonna talk about both of them in this video, but I'm gonna start with Git. So let's begin.
What is Git? Well, Git is a software that comes with your computer and installed on your computer. If you have Mac or Linux, so if you have a MacBook or an Apple computer, you have Git already. Or Linux computer, you have, you already have Git. If you have Windows, you have to download it. So you're gonna have to download something called Git Bash. You go to the website, you download it, and then it's like a little terminal window. Use that.
Is Git something you need to know? Yes, Git is something you need to know. You are not going to be successful at programming without knowing Git. Everyone needs to know it. It's like one of the most basic things. It's like terminal, you need to know terminal, you need to know a command line, you need to know Git, and then you need to know how to code.
So what is Git do? Why do I need to know it? Here we go. This is as simple as it gets. Simple as it gets. Git is a memory card for code. If you have a project with a bunch of files, HTML, CSS, JavaScript, whatever programming language you want, you want just like how you have a video game, you want to save your progress as you go. That way, if you die, you don't lose all of your progress. So with Git, every so often, you're going to enter a command to save your progress. Now, this is locally on your computer. Nobody else can access this. You have this on your computer.
So I'm going to go through an example now. I'm going to create a folder, Git video. I'm going to go into my Git video and then I'm going to make an index.html file and an app.css file. So I made a folder and I made an HTML file and a CSS file. Now, if one of these files gets deleted, I didn't save my progress, it's gone forever. I don't know what was in the file. If I wrote a bunch of HTML or CSS, one of the files gets deleted, poof, oh well, I can't do anything about that, it's gone forever. But if I use Git and I save that I made these files, I could save them with the contents of the files, and when one gets deleted, I can go back to my saved progress.
Now, to use Git, you have to know a few commands. There's only a few, and it's not that hard to understand. The first one is initializing your folder or project with Git. To do that, you have to have Git downloaded, and then you type `git init`. Initialized empty Git repository. Great. So that's the same thing as you're putting a memory card into your game system, because you obviously can't save the game without memory.
So here we go. Now we can use Git. We want to save our progress. How do we do that? Well, `git add` is what you want to save. We can save all of our progress, meaning all of our changes since the last time we saved, or we could just save a very specific thing. So after `git add`, you want to put either maybe a file that you want to save. So I could just save `index.html`, but if `app.css` gets deleted, it's gone forever. But I could just save any changes I've made to `index.html`, or I can save everything. So `git add .` would save everything that I've done since the last time I saved. I almost never commit a specific file. I usually push changes on everything. So in 95% of cases, you are going to use `git add .` and commit all of the changes that you've made.
Okay, so now I've said what changes I'm saving, which I chose to save everything. Now, if we were to get technical, I have added all files to the staging area, but that might just confuse you. So don't even think about that. I've added the files I want to commit. I've added everything. I am going to save everything. Now `git commit` actually commits those changes to memory. So you type `git commit` and then you need to do `-m` for a message. `-m` and describe the changes, describe the save. This way, when we look back, if we want to go back to this save progress, we know what we're going back to. So you make the message about what you're saving. Makes sense? So I'm going to say, "Add HTML and CSS file." Two files changed. You see that? I created two files. It got saved. That progress got saved.
Now, if I delete my HTML file and I add a JavaScript file, well, now I've made some more changes and I could save my game again. So now we only have `app.js` and `app.css`. So let's do it again. Save all my changes. `git commit -m "delete html and add js"`. So I've saved my progress twice now.
What we've gone over so far is how to add the files you want to save and then commit with the message to, you know, save the progress with the message, and `git init` to, you know, start it up. Now, if we type `git log`, we can look at our saved, the times we saved. Look at this. So this is the first time we saved it. It's a log. `git log`. It's a log of all of your saved changes. "Add HTML and CSS." Just gives you the time, gives you the date, fantastic. And then it gives you this little hash code used to go back to it. And then look at this, there's our second one. Time and date with the hash code.
Now, if I want to go back to my previous progress with the HTML and the CSS where we saved, I can copy this like hash code thingy-majig and then look at this: `git checkout` to check out that commit. Let's see where we're at. Oh, we're back to our first saved progress. Now, here's the tricky part: is that when we go back in time, we're in a different branch. So so now timelines are getting messed up, and we're in a time machine. Oh god, dude, maybe, maybe I shouldn't go with the time machine analogy. I want to keep this, I want to keep this organized, and I don't want to give too much to you to confuse you.
Now, what is GitHub? Now, what is GitHub? Well, GitHub is a website, and it's the same thing as Bitbucket, and it's the same thing as GitLab. They are websites where I just put the stuff that's on my computer. All my saved progress is on my computer, and I put it all on the internet so that other people can download my code and then go through all my saved progress. They could go back and forth, they could jump through time loops and go back to my save progress and look through all my code and do whatever the hell they want to do.
So how do you get your code onto GitHub? Well, you make a GitHub profile, and then you make a repository. Repository means folder, folder means repository, same thing. So you're on your thing, you go to repositories on your profile, you hit new, you hit new repository, you type the name of it, mine was Git video, description, you could have a public or private, whatever. So now, once you do that, it gives you instructions to hook this up to your folder on your computer. My folder is on my computer, I want it on the website. It tells me how to do that. It gives you specific instructions. It says `git remote add origin`. This is a command to just hook it up to the website. So let's just do that. Alright, ready? Boom. Okay, I added the origin.
And now this is called a push. So you have your saved commits, you save progress, and then you push it. You push to the website. Okay. And now we go to the website, and there is our code, people, ladies and gentlemen, there is our code. The CSS, the JS, and then the two commits that we can look through. Here's the first one with the HTML, CSS. Here's the second one. Now, someone else can go to my profile and see this, and they can download it onto theirs. And that's why GitHub is something you have to know so you can work with others on projects from different areas in the world. Because whenever I save my progress, I push it up to GitHub, and whenever they want to see what I'm doing, they go to my GitHub, and they can just pull my code down, or they can just look at it on my profile.
Now, do I want to go into branches right now? No, I don't. This video's already been long enough. But I will. Now, there's these things called branches. So by default, all the code is on a master branch. Don't overthink this. I know you're overthinking that. That just means that's regular, that's just regular, that's just you coding. You're saving your changes, they get saved to the master memory. But someone can go off, like in a video game, they could trail off your game, and then, you know, when you play a video game and then you do something, and it's on your friend's account, but you don't want to save onto their account because they still might want to play what you just did. So you save it into a new file. So that's a different branch. Someone could download my code, make changes, and they do it on a different branch.
So if we go back to our folder, and I type `git checkout -b`, that's going to make a new branch, and I'm going to call it `new-branch`. You put the name of the branch you want to make. So now I have a new branch open, and there's a master one still, but now I have `new-branch`, and I can make changes, and it won't affect the main game saving, the main code getting saved. It will just be my own branch trailing off of that code. So I'm going to add a Python file, `app.py`, and I'm going to commit. I'm going to do `git add .` everything, add all my changes. `git commit -m "add python file"`. And now, if I do a `git log`, you can see I got my three commits, and this, but this is for my new branch. I'm on `new-branch` here, but this stuff is from master.
Now, the cool part about branches is that I can merge my changes on `new-branch` into master if I want to, or I cannot do that if I don't want to. So if I want to merge all of, if I changed like 50 things on my new branch, I can push them all into the main one if I feel like it. And if I don't want to, then fine, I don't. I could delete the branch, I could do whatever I want. It's irrelevant until it goes into master. So the point of branches is so that other people can download your project, they can go and make changes on a separate branch, and then they could come to you and be like, "Dude, I made all these changes. I didn't want to mess up what you were doing, but hey, look at these. If you like them, merge them into what you are doing." And then I can. So what they would do on GitHub is they would say, "Hey, let's push origin `new-branch`." You could push the new branch up to GitHub. Oh, look at that. There's two branches on GitHub now. One of them is `new-branch`, one of them is master.
So if someone wanted to say, "Hey, dude, check out my progress," they could do what's called a pull request. And whoever owns the repository is gonna get that and look it over and say, "Hey, these are good or not." So you could say, "Hey, dude, I changed some stuff, check it out." And then you create it. And then whoever owns the project might be like, "Oh, this guy wanted to change some stuff. Let's see what he changed." Oh, they looked, he added a Python file. Maybe I want that. So that looks pretty good. Good job, dude. You made some good changes. And then you merge it into the master, and then you confirm the merge. And look at that, dude. Now it's merged into the master, and you know, dude, it's got the, the commits from the new branch. They got pulled into the freaking master branch. So now everything is in the main area because the guy liked the new branch.
Now, one thing that's important is you always want your local computer synced up to GitHub. You want these connected because it could get out of whack. You need these to be at the same spot. So when there's changes on GitHub that you don't have on your computer, you want to pull those changes down to your computer. You push when you have changes that GitHub doesn't have. You push them up to GitHub. When GitHub has changes that you don't have, you pull them down from GitHub.
So I will do `git pull origin master`. And now I pulled down those changes, that Python merging that went on up there. I got them now on my computer. And we could check that out. We got the merge, we got the Python file, and everything is now on our local computer.
Now, for rebasing, I do need to get a little more technical with this, and I think I might make a future video specifically about Git rebase. But these are the basics, and you can probably get by on just these. And maybe pick up rebasing on your own. I don't want to overcomplicate or make you overthink. These are the basics. This is all you need to get started using Git and GitHub. You don't even need to get into branches, really, because you might not even be working with those right now. Just pushing your code up, pulling your code down, making the changes, the save changes. When there's stuff on the GitHub that you don't have, pull it. When there's stuff on your computer, GitHub doesn't have, push it. You do not need GitHub to use Git, and you, you probably do need Git to use GitHub, but you don't need a GitHub if you just want to save your changes. But you need a GitHub probably when you want to collaborate with other people in different places, and you'll probably need it for like every project ever.
Now, some parting words about GitHub that you might be interested in. People will judge me because I don't have all these green squares. So if you want to set up some kind of auto-commit thing, you get a green square if you push code to GitHub every day. So people like to code every day and have all these squares look green. And sometimes they don't push anything useful. They might specifically change or add a comment just so that they have a green square on GitHub. These are people called clout chasers, specifically GitHub clout chasers. And, uh, they don't make impactful contributions to projects, and they specifically want green squares to flex on other developers. You can be one of them, or you can let it go and just move through and actually, you know, do real things with your life.
So that is it for this video. I hope I made this very easy for you to understand. And I'm going to put a black screen at the end with all the commands we went over, and there's only a few, and it's pretty straightforward. So that is why this video is the best Git tutorial out there. Please like and subscribe to show me support. Thanks for watching, and I'll see you in the next video. Video, bye.