Git & GitHub 101: For absolute beginners!

1. Welcome to Git & GitHub 101: For absolute beginners: Welcome to Git and GitHub, one-to-one, Git and GitHub for absolute beginners. Git is a version control system that lets you make incremental changes to your files and then travel back in time to see your work from previous days, months, years, or even a previous minute. And GitHub.com is the user interface and website that we use that is coupled with get on our computer as a program. In Git and GitHub one-to-one, I'm going to assume you have never used Git or GitHub at all ever before, or that you might have used it a little bit, but you don't have enough experience to be comfortable with Git or GitHub. Now the idea is to get you familiar with how Git and GitHub work together so that you can start collaborating on projects with other programmers. There are absolutely no requirements that take this course. You can start at the very beginning with absolutely no experience whatsoever. I'm Caleb Pauline, and I've been using Git and GitHub since about 2013. And today I'm going to be teaching you the basics of Git and GitHub. Support for Windows, Mac and Linux is included as well. Welcome to my class on Git and GitHub, and I hope to see you inside. 2. What is Git?: Alright, welcome to Git and GitHub 101. Let's first take a look at what is good, what is good, and let's see what the Internet things get is. Of course, get his mature actively maintained open-source project, originally developed in 2005 by Linus Torvalds, who Fun fact could also created Linux. Yeah, the famous creator of Linux operating system kernel. That is not helpful whatsoever. So essentially, get is a way for you to write a bunch of code and then for me to take a look at that code and maybe add a little bit more to it so that it's a collaboration tool. It's also a version control tool, which means at any point in time, if you wanted to, you could write some code today, write some code tomorrow, the day after, and then you can come back in time and you can see exactly what code you wrote today. And so you don't have to make Control Z or Command Z and undo a bunch of stuff. You can literally just hop around from the current code to the old code. And so it allows you to see what kind of mistakes you made or to fix mistakes. Or if you produce the mistake, you could go back in time to before that mistake or that bug was introduced. That is what good does that is what Git is. It is a version control system and a programming collaboration tool. 3. What is GitHub?: What is GitHub? So github is a way for you to use Git on your computer. And then it is a user interface in the form of a website where you can actually go and take a look at all the different code. And so for example, if we take a look at wag towel, waived away. And this is basically what GitHub looks like. So it's, it's not glorious by any means. It's not the fanciest looking thing out there, but it does allow you to see everything, all the code. And so this is an open source project called wag towel. And if I wanted to, I could look at any of the code from the wall, really ANY contributor. Or I can take a look at the 10,741 commits as of today. That's how many pieces of not pieces, but how many updates there have been in the web till project. And I can go back and I can take a look at any one of these updates from anybody who made those updates. So we can see the latest one hears from January 13th, 2021, fix the formatting in development and documentation. And that's from and that's from David and TiVo. Tivo is on the core team. There. We can go back and we could see, let's see, let's see what happened here. We can actually see that a line was deleted and align was added. And this is what was deleted and this is what was added. And so this is called version control. And this allows you to see the different changes that other people have introduced. And it allows you to wrap permissions around who can add what into your codebase or view can add certain things into other people's code bases. And GitHub.com is the way we, well, the way we basically use gets now you don't have to use GitHub.com. You can actually do it all through your command line if you want to. But most people prefer to use GitHub.com just because it comes with a nice user interface. Now this might look a little bit daunting at first, but we're going to go through a lot of what all of this is in this course. 4. Creating a free GitHub account: Alright, for this course you are going to need to have a free GitHub account on GitHub is completely free. There is a way that you can pay them and you can get some extra features. But honestly, for the most part, it's just free and all we need is free. I've never paid for GitHub. And I have really used a lot in the last about 89 years or so, somewhere around there. So to sign up, all you have to do is go to GitHub.com. Click on, sign up, create a new username, enter your email address and your password. It will then verify your account. Pick the dice pair adding up to seven. Oh, this is pretty cool. Okay, so you just fill that out and then you create a new accounts. Now, I already have an account, so I'm not going to do that and you might need to verify your email address as well. So make sure you put the right email address in there. We're also going to need need to know what that email address is down the road when we set up Git on our computers. So make sure you are familiar with your username and your email address. Once you're logged in, you should see a page something like this. Your page might be considerably more empty than mine. I have a bunch of feed activity in here. You can think of GitHub as a coating social network. To some degree. You might not have repositories or teams on the left, and that's totally okay if you have a brand new github account that is totally okay. Over time, you will start building these up. So once you're in here, we're going to need to find a demo repository to look at. And because we're going to need to know what a repository is, we use this word all the time. And so in the next lesson, let's take a look at what the repository is. 5. What is a repository?: Okay, what is a repository? So if I jump here and I just type in wag tail, and we're going to see that I can go to github.com slash white doll. That's the organization or the account, and that is the project name as well. And so all this code that you see in here, this is part of what's called a repository or a repo for short. And so this repository tells you all the code that's in here. You can see literally all the code. You can even see code from years and years ago. We can see that there are 747 issues. There are 161 pull requests pending. We'll talk about those down the road. You don't have to worry about what those are right now. And that there were over 10 thousand little updates to this repo in the form of a commit. It's called a commit and it's just tiny, tiny little update. And so every repo is going to have a bunch of code. And it might have different code depending on which repo you're looking at. So this one is a Python based repository. And we can see that even in languages here, Python takes up 81.9%. Html is 9%, JavaScript is less than 5%, SAS is less than 4%. Type script is less than 1%, shell is less than 0.1% or 0.1%. And a bunch of other things that take up 0.1%. And so you can see this is primarily a Python repository. And if we scroll on down, we're going to see this thing called a Read Me file. And these are the instructions that you're going to see in a repo. Now let's go ahead and take a look at another repository. Let's go to coding for every buddy. Oh, that's looking inside this repo. We want to look all of GitHub and just go down to users and then click coding for everybody. And you can see all the repositories in this organization. This is an organization, this is a profile account called coding for everybody. There are seven different repositories in here that you can see. And let's go to seven days of wait till this is the newest one in here. And you can see all the coding here. You can see that there's only two commits. There's only been two updates. The final source code and a read me. And we can even go in here and we can see what was actually changed. And so green means something was added, red means something was deleted. And there is no red, so nothing was deleted just as Read Me file was added. And we'll talk more about commits and issues and pull requests and all that stuff down the road. But for now you just need to be familiar with what a repository is. A repository or repo is basically a bunch of code for your project that lives on GitHub in some sort of decentralized area. So github, git lab, Bitbucket, something like that. 6. What are README files?: What is a readme file? So a readme file is a specifically named file called README and all caps or readme dot amd, that stands for markdown. And the idea here is, it's usually an introduction into what the project is. And maybe some installation instructions as well, maybe some notes on how to contribute as well. There can be pretty much anything in here, but the idea is that a Read Me is simply a Markdown file that allows you to give instructions for your repository. And so most repositories have a read me file. And the idea again is just to let people know what your project is about without a Read Me file, people are not going to look at your project whatsoever. And there's gonna say how there's no Read Me file. I'm not going to even take a look. And if there's no Read Me file this section down here is simply not going to exist. So if we go ahead and click edit, just because I control the coding for everybody organization I'm able to edit this. This is what a readme file looks like, or at least a markdown file. And so we've got a title, we have a quote, We have an H3, another h3. So a smaller title, not the smallest, but a smaller title. What else do we have in here? We've got another quote, We have some bold in here and a link, even an emoji. And if we wanted to, we could always preview the changes as well. And this will just show us this is what we wrote and this is how it turns out. And so that is a readme file. Now I don't actually want to do anything with this README file because I'm happy with the way the hit is right now. The nice thing about a Read Me file is that it comes in the form of Markdown and that's what we saw with those number signs or with quotes and things like that. Is it is a very simple way to write. Basically, it's almost like writing code, like your writing HTML. But the idea is that you can write very, very simple headers and you don't have to worry about knowing HTML. You can just write number sign, and then whatever your text is going to be for your title. And it's automatically going to make it linkable for you. It's automatically going to make this large for you. That is the nice thing about a Markdown file. Let's go ahead and take a look at that one more time. So we have seven days of awake till three course is a title. Let's go ahead and copy this whole thing. But let's do two number signs. This is the difference. So the green means that it just, it's new. It just showed up. So we don't have to worry about that actually showing up in there. That's just telling us that that's new. This was the original and this is a smaller one, and this is an even smaller heading. And so again, the nice thing here is we don't need to know HTML or any other programming language. We can literally just type number, sign number sign, and create a small title. Or we can create a large title with just one number sign or a small ish title with three, or a really small one with four or five number signs in front of it. Anyways, this is not a lesson on markdown itself, but this is a lesson on what a Read Me file is. And so when you have a read me file, it's going to automatically show up in here. If you don't have a readme files doc willing to show up in there. So just keep that in mind because we're going to be using that in the future, just like that in your back pocket for now, you don't need to know how to create a README or a Markdown file at this moment. But you will need to know how to do that in the future. And it might take a little bit of research, which is totally fine. But for now, you don't need to worry about what all this is. I just wanted to show you that, hey, if there is in fact a readme dot AMD file, it will show up, it will automatically render in your repository by default. 7. What are commits?: What are commits? So when you have a repository like this, you can have, and by the way, I'm looking at web scale such wag tell. When you have a repository like this, you have a lot of different contributors and a lot of different people trying to write code and trying to make your code better. It's essentially what Open Source is all about, is trying to make everybody's code as good as it possibly can be, especially if you have an interest in someone else's code. Now every time someone writes a little bit of code on their computer, packages, packages it up and puts it on GitHub. That is called a commit. And a commit is basically a small little update to a larger repository. And there can be an unlimited number of commits. And so we can see the wait till repo here. There are over 10 thousand commits already. That means there's over a 10 thousand small little updates now they might not all be smoke, there might be some really, really big ones in there. Who knows, we could go through all of them and take a look if we wanted to. And in fact, yeah, let's actually do that. So on GitHub what you can do is you can just click that commits and you can go through all of the commits through all of time. So let's just click older. The way down. We can go older and older, and older and older, and we can just keep on going. So let's take a look at this. So Carl and Tebow, who were both on the wait till core team, did a bunch of work on October 21st, 20-20. Let's take a look at what the update web pack work was. And so now I'm looking at a specific commit. This is specifically what they wrote on their computers and they pushed it up to GitHub. And so we can see here that in this command we have exposed loader is version 0.7.4, and that was actually bumped up to 0.7. 0.5. web pack was bumped up to 4.43 from 3.10. And we added web pack CLI. What else did we do in here? Web pack dev watch command is now going to do dash, dash, motor development, dash, dash progress, dash, dash watch. That's brand new and something similar for web pack prod build command. Now, on every commit, I could always leave a comment. I can say, hey, this is really great, love what you're doing, thank you for doing this. Or I could leave a little comment on here and I can say, hey, by the way, I think you should add another flag in here, another dash, dash, something rather, if you're familiar with web pack or whatever the commit is about, you could add some feedback in there as well. There's another way to look at commits as well. You can do the unified way. I personally like to split way, but some people prefer the unified way. So split is things deleted on the left, things added on the right, unified is thinking deleted above, and things added below. So we deleted this line, added, this line, deleted this line, added these two lines. And so again, the idea here is that this little piece of code was added to the main wag tail project, the whole repository. And it wasn't actually a lot of code, it was just a few lines being changed. And that's a really good example of what a commit can be. It can, it can be literally one letter and just needs to be one character changed. That's it. Or it can be a massive, massive commit. It can be something huge, hundreds and hundreds of lines. And it's usually better if they're smaller so that someone else can review your code, will talk about that in pull requests way down the road. But for now, what you need to know is commits are a way for you to travel through a project's history, to see code at a different point in time. Who so for instance, we could go to January fifth and we could browsers repository at this point in history. This is the code from January fifth. All of it, This has nothing. January fifth. Oh, and one more thing is, every commit has this thing called a hash. So let's take a random commit here from Gassmann and Matt Westcott here. And let's just copy that and let's throw this up in the URL and paste that. This is the commit hash. Every commit has a unique hash. And you use this to basically look at code from a different point in time. And we can do that through our command line using Git on our computers, which we don't have installed yet and that's totally okay. We will get there. Or you can look through the repository at a certain point in time using this hash. And you can see this hash shows up the first one is that seven characters, because that's most likely going to be the most unique identifier we have. I don't know what that is. 32 guessing characters versus just the first seven. The first seven is usually unique enough for us to identify a commit by. But if I click this, you can see that that hash is in my URL up here. And we can actually see all the things that have changed. So that is what a commit is. A commit is a way to travel through time to see little code updates. And how it works is basically you write a little bit of code on your computer and you package it up and you mail it over to github.com electronically. Of course, we mail it electronically through a program called Git. 8. What are stars?: Okay, let's take a look at what stars are in Git and GitHub. So I'm on github.com slash wait till such wag Dell and wait till being the organization and wag tell being the repository name, it just happened to be there named the same thing. And that's very common thing. You'll see that a lot in GitHub, on GitHub rather. And in the top right we have a few different options here. So we've got 4k OnStar or yours might say star and watch or unwatched. And it's going to be a little bit different for you. So I'm already watching this repository and I have some custom settings in here. And I'm already starting this repository. Let's go ahead and find a repository that I might not have been watching. And it might not have started already, right? Tail factories. No priority watching. That go to condense inline panel. Here we go. This is one that I haven't actually really worked with too much. And so it's saying that I can watch and you can click here and you can see who's watching it. And watching is just like when something happens, that person will get a notification and it can be completely ignored and they'll never get notifications. It can be custom. But this lesson, we're talking about stars. And so the idea here is a star is like when you're on Instagram and you'd like a photo, you get that little heart that pops up. That's a star. When you're on Facebook and you like someone's post. That's a star on GitHub. When you're on Twitter and you like someone's tweet and a little heart shows up. That's the equivalent of a star on GitHub. And I think you get the point now. And so the idea here is that we have these things called Stars and stargazers. And so every repository gets stars and you can see who has started a repository. And just like any social network out there. And if you wanted to, you can simply click Start to show your support. Now if you ever working with a repository in your late, hey, yes, I really, really liked this repository. This has been really helpful. Please, please star it. A lot of people will put in a lot of effort into open source projects. And a lot of other people will look at that open-source project and see, oh, it only has five-stars. I'm not going to use it. I'm gonna use something a little more popular. But he could, for all we know, beat extremely popular amongst stargazers. They just haven't clicked that star button. And so a stargazer is anyone who has started a repository. 9. What are reviews?: When we're dealing with Git and GitHub, or Git and GitHub or Bitbucket or really any other sort of user interface for version control such as GitHub. We have these things called reviews. And so the idea is that someone can write some code and someone else can then review it before it gets merged in. Now we're not going to talk about merging or pull requests, not yet anyways. But the idea is that for instance, we can go to pull requests. I can go take a look at any given pull request. I can see the files changed in here. And this is basically code that's being asked to go into the main repository. It's not in there yet. And I can review some of this code so I can say something like, this is a blank line. It's not needed. And then I could start a review if I wanted to or can add a single comment or I can cancel. And yes, I went to discard my changes because they don't actually want to leave that comment. And so the idea here is that someone can review. So gas man has asked carl here to review his code. And so Carl's going to then go through here and say, oh, yep, okay, everything looks okay, things look good. He's literally just going to read through this code, is gonna go DOM dot find, find a bunch of stuff, double-click JavaScript fat arrow, or JavaScript arrow function in PHP is a fat arrow. In JavaScript is just called an arrow function. So click arrow function. If yada, yada, yada, a bunch of stuff in there. And if everything is good, he's going to approve it or he is going to just leave a comment or request changes. And so the idea here is that you have peer review. So programmers, we like to think we're smart, but honestly we're not, we're not so smart that we write perfect code. And so we get another human to look at our imperfect code to try to make it as good as possible or at least good enough. And that's what a review is. Now we're going to look at those a little bit more in the future. I just wanted to show you that that's what a review is. 10. What code should you open source?: What code should you open source? And that is a great question. So when we create a new repository and we will create a new repository, I'm just gonna show you here just as a glimpse into the future. We can have a public repository so everyone can see your code or a private repository. We're only weaken C or code and there's a use case for both of these. So if I go over to my account, github.com slash Caleb telling and just go into my repositories. I 54 depositors. That's quite a bit. You can see that I actually have a repository already with the first one that shows up. It's private. It's just called School. And then I have some other ones that are completely public. So like get Essentials, which is what your project is. I'm going to be in Git and GitHub 2.1.1. I believe there's Django to a one. So the source code for Django to a one. We could go and see all of the commits in here. This is all the step-by-step instructions for the Django 200 one module. And so the idea that I want to talk about in this lesson is, what code should you Open Source? And so in my opinion, open source as much as possible, the world has thrived off of open-source and you wouldn't believe it, but almost everything comes from open-source. Almost every website you, you hit, every website that you use is using Linux behind the scenes, completely open source, 100% free. If you write Django, like I do, completely open-source, 100% free. And so the idea is to perpetuate or to move that momentum forward by creating more open source stuff. And so pretty much any project that you have, I would say make Open Source if you can. The other question I guess we should tackle is what should you make it private? And so I'm working on a project codename School. And I don't want it to be public. I don't want everyone to see the source code. I want it to be a little more proprietary. And the idea is I'm going to be building a company around this. And I don't want other people being able to steal that code. I want to be able to create a for-profit business using this code in here. But for example, get essentials is completely open source, is 26 commits in here and it's completely available. You can see all the commits, you can see everyone who's contributed. You could see all the different pull requests. You can see all the different issues, you can see all different things in here. And so when you're going to work on a project, I would highly, highly, highly recommend that you make it open source. I just because primarily, when you go and look for a job, someone who is interviewing you is surely going to Google your name. And if they can find you on GitHub and see that you can use get, be, can use GitHub, see know-how to open source code. That is a strong indicator to them that you are a decent developer and that they should in fact take you seriously. So I would say open source as much as possible, as much as humanly possible. There are cases where you don't want to open-source, but for the most part, pretty much all of my code is open source. I have very few things in here that are private. I've got a client, presidential auto private. They paid for that. The repository for learn wag tilde.com, it's a security thing. It's private, but everything else is public. And so you can see most of my stuff is public. It's all open-source. 11. Downloading and installing Git on Windows: Downloading and installing Git on your computer using Windows. So let's type into the Google machine how to download Git for Windows. And I'm on a Mac. So I can't actually go too far with this, but I can show you what I will recommend. So there's a lot of stuff in here, but there's actually one particular tool that I really like, and it's called Git for Windows.org. And the idea here is you can run all of your regular git commands on Windows because Windows does things a little bit differently from Mac and Linux. You can run all of your Windows commands, just like you normally would with Mac or Linux. And so you go to Git for Windows.org, click on Download. And chances are if you have a new version of Windows, you're going to want to downloading get to 0.30 64-bit dot EXE. And so let's just scroll on down and find which one are we looking for here. Get to No.2, 64-bit not tire. If you're on Windows, you probably just want the dot EXE file and that will automatically allow you to install it with a click of a button. So if you're on Windows, go ahead and download this, install it. And whenever we write commands using Git, we're going to be using this program called Git for Windows, not PowerShell, not command. We're going to be using this particular program. And that's just going to keep things nice insisting, assessing for all of the students taking this course. So whether you're on Windows or Mac or Linux, if you use this program, all your commands are going to be the exact same and they will magically, just. So as a recap, for Windows, users go to Git for Windows.org, click on Download. It will bring you to this page. Look at that. It actually brings you to a GitHub.com page. That's pretty amazing. This is open-source. And then download the version that's most applicable to you, either 64-bit, if you have, let's say Windows ten chances are you have 64-bit. If you're running on Windows seven, you might need the 32-bit one, but chances are you're going to use the 64-bit one. Scroll on down. Download the dot EXE file, whichever one is the appropriate one for you. Install it and when you're ready, let's head on over to that next lesson. 12. Downloading and installing Git on MacOS: Downloading and installing Git on your computer for Mac OS. So let's do this, how to download and install Git for Mac OS. And I'm going to type that into Google. And at last season, at least, not really sure how to say that name, to be honest, huge company out of Australia though, has some good helpful articles here. And so this one, it says installing Git on Mac OS X. And so if you already have Git on your computer, what you can do is you can open up this program called Terminal. And I'm gonna make this way bigger. And you can type git dash, dash version. And you can see that I have get version 2.23. You might not have that already. You might have nothing. And if you don't have get in there, if that command does not work for you, what you can do is you can download the latest get for Mac installer. And so I just click this link. And this is going to bring me to sourceforge.net. And all you have to do is download the latest version. Make sure you download and install that. It's a.dmg file. So make sure you actually install that properly on Mac. Once you have that installed, what you can do is you can open up your terminal. Would I like to do is I like to close my terminal entirely and then I just reopen it. And that just sort of refreshes things for me. And what I can do again is if I just zoom in here, you should be able to do git dash dash version. Once again, you're going to need to install that installer or you're, you're going to need to execute that installer. And so that comes from sourceforge.net. 13. Downloading and installing Git on Linux: Alright, let's talk about how we can download and install Git on your computer, on Linux. And so this is really, really different for a lot of different Linux flavors. It really depends on the version of Linux that you're using. Chances are you probably using arch or arc. I've heard people say it both ways or Ubunto. Now that may not be entirely true for everybody, but for most people they're going to be using art or you've been to. And so what we can type into Google is how to download and install Git for Linux. And let's just go straight to get SCM.com. And this is going to tell us exactly how to install Git on Linux and selling it linux. Sudo apt-get install and get dash. If you're in Debian based distribution such as Ubunto, try using APT, APT. And so that's really all you have to do, is just follow these instructions in here. And that will install it for you. And then you can do git dash, dash version. And that should show you the version of Git that you're using. 14. Configuring Git on your computer: Okay, let's talk about how we can configure your get user name and email. And so once you have Git installed and it's running on your computer. And the idea here again is that you can do if I just make this significantly bigger here. If I do git dash, dash version, I can see that I'm using Git. It shows me a proper version. I should be able to type git config and remember if you're on Windows, you're going to want to open up Git for Windows, not your regular terminal, but just Git for Windows. And it should show you all sorts of stuff in there. Now we're not going to read through all of that because that's going to take like an hour probably. But what we are going to do is we're going to configure our global username and our global email address. Now if I just flip on back here to this malathion article, but pop-up them, configure your username and email using the following commands. Replace Emma's name with your own. These details will be associated with any commits that you create. And so the idea here is that when you package up a little bit of code on your computer and you ship it off to github.com. Who is it going to say it's from? And so what we want to do here is type git config dash, dash, global, user.name. And then in what looks like a string or in quotations, I would say Caleb, tall, lean, and this is going to be my name, just my regular name. Now that's already set up on my computer, so I'm gonna skip that. But you would hit enter. And then we need to configure one more thing. So git, config dash, dash global, user.email. And this email address should match the email address that you used to sign up with on github.com. For me, that's Caleb, dot-dot-dot pauline at gmail.com. And then you just hit Enter and away, you go. Now the way you can confirm that is you can type. Now if you know what you're doing on the command line, you can open up a file. So I'm going to use cat just to print out the file. And I can do home git config, dot git config. And it's going to show me in here user name and email address. I have a bunch of other stuff which we'll talk about in the future, in a future course. But for now, this is what you need to see in your git config. If you have a git config. 15. Your first repository: All right, let's go ahead and create our first Git repository. And so what we want to do here is go to GitHub.com. Make sure you're logged in. And click this little plus over here and click New Repository and was going to call this test repository. And this may or may not exist at the end of this course, I might actually just delete this, but I just want you to sort of follow along with me. So create a repository in your account called test repository. This is a test description. I'm going to make this public so that it's open source so anyone can see it. I wanted to add a Read Me file. I want to add a gitignore file and the gitignore template. Let's say, let's say I'm gonna be working with Python. I'm going to select Python in there. So it's going to ignore pie cache files, be YC files, all sorts of things that I don't want to commit to a project. And let's choose a license. And let's choose the MIT license. It doesn't really matter. I'm just doing this for demonstration purposes. Now let's go ahead and click this repository and create repository. And this is gonna go ahead and create a new repository with files in here. Now, that's really all there is to creating a brand new repository on GitHub.com. But this does not exist on our computer, so we needed to make it exist on our computer. So we click this button here code and we can see the HTTPS SSH or GitHub CLI. Let's click on the HTTP S1. And this is just going to give us this link, HTTPS github.com slash Caleb Italian slash test, dash repository dot. Get to go ahead and copy that. And let's go ahead in our terminal or command line or, or whatever program you want to use. Powershell bash terminal, i term to. It doesn't really matter as long as you have a command line program. You can even open this up and VS Code if you wanted to. Just open up the terminal and VS code, we want to MK dire, test, dire cd testdir. And you should already be familiar with how to move around on the command line. This is really, really important when using Git. Now there's two ways to learn yet. There's the user-interface way where everything is graphical and right in front of your eyes. And there's the command line way, in command line way. Command line interface, or CLI is harder. And the way I'm teaching you, i'm purposely teaching you the hard way because when you're on a server and you want to get the latest code from your repository. There's no visual interface. It's all command line. And so I'm setting you up for success by teaching you the hardware right now. So I'm inside of my test directory. And what I can do here is I just copied this over. I can type this command git clone and then just paste that. And if I do ls dash l a or if you're on Windows, you can type DIR. It has a new repository in here called test repository, the CDI test repository, ls dash LA. And you can see we've got a folder called dot get, a dye gitignore file, a license file, and a read main.xml file. Let's go ahead and open this up and VS Code. And you can see here, if I just make this touch bigger, that we have our gitignore, our license, and our read me. And that is all coming from and came from a repository here. Now again, that command that we typed was git clone. And we just pasted that URL in there, the one that GitHub told us to copy. In the next lesson, let's go ahead and edit one of these files so that we can start to package it up and put it on GitHub. Because right now all we did was on GitHub. Over here. In the right browser. We have gitignore license and read me dot amd. We didn't actually edit these files, but we did download them from GitHub and put them on our computer. Now we need to do the reverse. We need to edit a file on our computer and push it back up to GitHub.com. It's actually called a push, but we'll talk about that in a little bit. 16. Editing files on your computer: Alright, let's go ahead and edit a file on our computer. And so what I did was code dot in my folder and it just opened up VS Code for me. Now you may or may not have that installed. You might have to go into File Open and then open up your whole project using VS Code that way. Either way, that's fine. So let's go ahead and open up this Read Me file and let's just make this a touch bigger. And this Read Me file just says test repository. This is a test description underneath, let's say this is a new edit from my local computer. And so a local is always your computer. Your computer is always local. And when we're editing websites, when we're working with websites on our computer and we always use local host. And so this is from our local computer. And GitHub.com is called a remote. So let's go ahead and save that. And if we go back to our terminal here, we can do a git status. And this is gonna show me a file in red. And this file in read, it says that it was modified. So what I can do here is because it was modified Eigen say git diff, tape in, read me, remember it's case sensitive, so it's all uppercase. Read me dot lowercase MD. And this shows me that there is a new empty line here. It's green. And this is a new edit from my local computer. This is what I wrote in here. Now I have Git installed on VS code. So you can see that these are two new lines as well. But on the command line, it simply looks like this. So what we can do again is git status. And that shows us the status, shows us unchanged files, new files, things like that. And we can simply do git add, readme dot m, d. And this is going to change the way it looks when we type git status again. And so what we did here is we said we staged this four. Basically think of it like your mailing a letter. What we did here was we put our letter inside of an envelope. We haven't nailed it yet. We haven't gone and dropped it off in the mailbox. We haven't sent it to the post office yet. We have simply put it in an envelope. We need to say who this is two and what the message is about like what is this letter actually a bouton. And in the next lesson, what we're going to do is we are going to give this a little bit of a message. So we're going to sign our letter. We're gonna say who it's to and then we're going to possibly send it off to GitHub so that they can update our code for us. 17. Your first commit: Okay, in the last lesson, what we did was we edited our Read Me file and in my command line, if I do git status, I can see that I have a file is modified. It was read me WMD that was modified. So I can do git diff, read me dot MD, and I can see that these are the changes in your modified readme dot AMD. Green is the things that we added. Let's go ahead and actually delete a line in here as well. So I can do git status. Git diff, read me WMD, and you can see red means I deleted it, green means I added something. And so what we wanna do is if we do git status again and it's okay to type git status and million times git add. Read me. And this is going to turn it green and this is ready for now. It's ready for us to mail it to GitHub.com. And so this is called staging. And what we did here was we staged. This file, said, hey, this is ready to be packaged up in a thing called a commit and is ready to be sent to github. So if I just clear this off, do git status again. And we can see that this is staged. And I can do git commit m for message. Let's say updated the Read Me file. And I put that in quotations. And now if I do git status, again, you should see nothing in there. Absolutely nothing. But if I do git log dash, dash one line, this is our initial commit. This is when we downloaded code from GitHub. And this is the updated Read Me file, that's our latest commit. Now, head is where our Git is pointing at. Origin main is github. It's where Origen thinks it's at origin head thinks it is add here. And so what we're seeing here is that our computer, our head is on this commit. Get hubs head origin, head on initial commit. So if I go back to github.com and just refresh, we're going to see that my code and didn't do anything it, it didn't make it to GitHub yet. Well, we have to do is we have to push this code to GitHub. And that's what we're going to do in the next lesson. But right now, all we did was that git commit m, some message after we staged to file. And if we do get logged dash, dash line, we can see that we are ahead of the code on GitHub.com and we need to basically tell GitHub to come and download our code from here or the other way around. We're going to push our code to GitHub and we're gonna do that in the next lesson. 18. Pushing files to GitHub: Okay, let's take a look at how we can push our files to our GitHub.com repository. So in the last couple of lessons and what we did, and just to recap, was we edited a file. Then we said git status, it was red. We did git add whatever that red filename was. So read me dot m, d. And that was stage. Then we committed that file. And that message is basically like signing your envelope, saying, what is the purpose of this letter, what is the purpose of this code? And so we said do a thing or something like that. And that's basically where we're at right now. So if we do get log dash, dash one line, we're going to see this is where our code is add-in, our GitHub program, our head is at main, and it's on this commit. It is one commit ahead of this one. Get hubs had good Hubs program called Get. The one that they run behind the scenes. That's called Origins slash head is at initial commit and we need to basically say, hey GitHub, we want you to have this new code. And so the way we do that is we do git push origin main. Now when older repositories is called master on newer repositories, it's called main. And to figure out which one is which. If you go back to your repo, if you see up here, it'll just say main or mass, or if it says Master, you type git push origin master. If it says main, you do git push origin Maine. So I'm gonna do git push origin main. It's going to ask me for my username. Ok, loved Colleen. And when you run this, you should hopefully see invalid username or password. I have extra security setup on my account, so I simply can't do this the same way you do, but you should simply be able to put your username and password in there and that will authenticate you. What you should see is this enumerating objects, a bunch of stuff, counting objects, delta compression, compression objects and compressing objects, a bunch of stuff that we don't really understand. And it's going to github.com, My Account test repository dot get. And so if I go back here to my repository and hit refresh, what you're going to see is now there are two commits. There's one called initial commit and there's one called updated, the Read Me file. And that's the one we added just a couple of lessons ago, updated that Read Me file. And so that's what the commit message is. That commit message is exactly what we wrote. And this is exactly what we saw when we wrote Git diff readme dot amd, we deleted align and we added two new lines, one blank line and a new line that says this is a new edit for my local computer. And that's how we push files to a GitHub repository. Let's do one more example here. Let's go ahead and delete this and say this is a second example. And we're just going to edit that readme file. And again, the reason we're doing that Read Me file is because if we go back to that code, it shows up automatically right in here. And so I save this file, open up my terminal, I can do clear git status. I see that it's been modified. Git diff readme dot MD. I can see that I deleted a line and I deleted this red line and I added this green line. So git status once more, I can get add that, Read Me file. And remember this simply stages at when it's green, it's staged. And you can tell that it's stage. It says changes to be committed. And if I want onstage weekend, say get restored, dashed F stage. And then the file name. We don't want to do that. We want to send this to github. So this is stage, it's ready to be committed. This is like being in an envelope. We just need to sign this envelope now. Second update. That's what we're going to put on here. Now that's great. But if we do get log dash, dash one line, we're gonna see that we are now ahead of where GitHub thinks we are. Github no longer thinks we're at an initial commit. We did a push a little bit earlier. And so GitHub thinks we're at updated the readme file or hash seven, BB, d nine, cf. But our local code, our code on our computer is one step ahead. And so to basically push this code up to GitHub. So github is also up on main. We can do git, push, origin, main. And for you it's probably going to ask you for your username and password. That's okay. It's safe to put your username and password in there. That's your GitHub username and password. And last but not least, if we did get logged dash, dash, one line. We can see in here, origin head is at second update, main or origins slash Maine is that second update. And our local computer is at second update. So we're all up to date now. And what we can do is we can go back to Firefox or whatever browser you're using. Hit refresh. And we have three commits now, second update shows up. And it's exactly what we wrote, this matches our computer. And I'm gonna go to the split view here. And so we deleted these red lines and we added this green line. And that's exactly what we have here. This is a second example. This is a second example. And if you're ever wondering, Oh, is that actually where it's supposed to be? You can always just click on code and go to the main code base. And it's gonna say this is a second example. 19. Pulling files from GitHub: Okay, let's take a look at how you can download the latest files from your repository. So you can actually edit files directly on GitHub. And so let's go ahead and click this little edit icon. And we can change this directly on GitHub. And so let's go ahead and change it from test repository to my very first repo. And let's say Caleb is an awesome teacher. I will leave him a nice review. Question mark. Hopefully, hopefully that's true. I'm going to, I'm gonna gonna go with it. I'm gonna say, I hope it's true. Click on Preview Changes and it shows you the stuff on top. Deleted. It's red on the side so we know it's deleted. It's green on the side down here, so we know that was added and we need to commit our changes. And so this is just like using the command line only. We're doing it through the website this time. Updated the readme for a third time. And that's all I'm going to do. You can add an extended description if you want to. This doesn't really require a long description, just requires a standard commit message. So let's go ahead and commit directly to the main branch. And commit changes. And so let's go back to our main code base here. And we can see that that updated we have for commits in here. And the very last commit said updated the Raimi for a third time. So we did that right on GitHub. Now, the problem with that is if we open up a terminal or Git for Windows and we do get logged dash, dash one line. Our computer thinks that Git is exactly where we are at, which is not true. We need to pull in these latest changes. And so there's changes on github.com that are not on our computer and we need to go and get those. And it's really easy to get those. What we can do is we can do git pull. So before we were doing a push, this time we're doing a poll. We git pull origin. And the origin is going to be github.com. Or if you're using git lab is going to be gitlab.com. Or if you using bitbucket is going to be bitbucket.com, but we all just say origin. So git pull origin and then our branch name, and that branch name comes from here. So we're using main. If you're using an old repository, it might be called master. So we're going to git pull origin, Maine. And this might ask you for your username and password. If it does, you can put your username and password in there. And otherwise, we have downloaded the latest source code. So what we can do now is we can get log dash, dash one line and that second update, and we're no longer on that second update. We are on updated the readme for a third time. And so now our local computer says, oh yeah, we know that GitHub is. At this particular commit message. And so are we. And so if we go back to our code, in my README, it says, my very first repo, Caleb isn't awesome teacher. I will leave him a nice review and that matches what we have in here. Now, you might see something and I'm going to set up an example here. You might see a strange thing happened when files on github change. And so do your local files. And so what I mean here is that change for a fourth time. That's all I'm going to say there. And so what I'm saying really is let's say I don't have the latest changes. I don't have changed for a fourth time on my computer. Let's demonstrate this git log dash, dash one line, not online, but one line. I don't have that latest one on my computer. It doesn't even know about it. So let's say that happens and I go and edit my file locally. Let's say this is a new line here. And let's say I want to push it up to GitHub. So git status, git add, read me git commit from local computer. That's my commit message, commit, git commit dash M, git push, origin, main. And this tells me a bunch of stuff and this looks really alerting, but it actually isn't. If you ever see something like that, just read through this. It says hint updates were rejected because the remote contains work that you do not have locally. What that is saying is github.com is remote. You are local. Github.com is remote. So it saying github.com has changed that you don't have on your computer yet. This is usually caused by another repository pushing to the same ref. That's a fancy way of saying there are changes on here that you don't have. And that could be from another repository, could be from another person. It could just be because we edited a file manually on here. Instead of doing it on our computer. You may want to first integrate the remote changes. Example, git pull. Before pushing again. See the notes about fast-forward and get pushed, dash, dash help. So now it's giving us things that we can work with. Let's go ahead and do exactly as, as git pull. Origin main is, is get pulled dot, dot, dot, dot, dot, dot, dot is going to be our origin man. We always say git pull from a GitHub, that's going to be our origin and our branch name, that's going to be Maine. So git pull origin main. Now this says that there is a conflict in here. And for Git and GitHub, one-to-one conflicts are beyond what we are going to be learning. That's a little bit trickier to deal with and I don't want to overwhelm you. So what we can do is we can say get status. And it tells us what we can and can't do. So it's trying to do a rebase here. So let's do it. Let's go ahead and do git rebase dash, dash, abort, git status, git log. And git status was just to show us that there's nothing in there. Get log. We are on from local computer. So what we can do is we can say git pull origin, main dash, dash rebased. And what this is going to do is it's going to pull in that work and it's going to put our work on top of it. So basically it's going to say, instead of conflicting, we're going to say, hey, grab the stuff from GitHub. And then whatever happened after that, put our changes on top of it. And this actually didn't work for me the way I was expecting it to work. Usually this does work. And so there is a conflict in here. Let's go ahead and, and you know what, let's resolve this conflict in the next video. 20. Resolving code conflicts: Okay, let's go ahead and resolve this conflict. So we are trying to pull in changes from GitHub and we have changes on the same, in the same file on our computer. And so when we do that is first of all clear this off get status. It says there's a rebase in-progress and you are currently erasing branch Maine on a commit hash, fixed conflicts and run git rebase dash dash continue using git rebase dash, dash skipped to skip this patch or dash, dash o board to skip. So if you ever like, ooh, I really messed up and I don't know what I'm doing and I am scared. You can always just type git, rebase, dash, dash, abort. And that will stop all of this for you and revert back to normal. And then you can ask someone for a little bit of help. So let's go ahead and say git diff, read me. Nope, read me. Wmd. And it says a bunch of stuff in here. And it's all green. So let's go ahead and open up VS Code. And VS code. I'm using the get extension in VS code, so it automatically shows me what is coming in and what is the current change. And so up here, this is what GitHub has. Github has killed is an awesome teacher. I will leave them a nice review files on GitHub changed so and so do your local files. I don't remember what I was trying to say when I wrote that, but let's say, for instance, I wanted to merge this together. Well, what GitHub is gonna do is it's going to add all these little arrows, head, bunch of equal signs and then more arrows. And that's going to tell you that the top is GitHub, the bottom is from your computer. And so what I can do is simply just delete these lines, delete these lines. And so this is the code. This is what it looks like. This it looks a little more well, it looks less overwhelming. And this is Caleb isn't awesome teacher, yada, yada, yada. Let's say I want to keep that line and I want to, and I want to delete that middle line and keep this bottom line. Ok, so I'm going to do that. I just save that file I just edited to be exactly what I want it to be. And I save that file. Let's go ahead and do a git status. We can do git diff, read me dot m d again. And this looks a little more recognizable. It doesn't have all those weird arrows and equal signs in there. If we do get status is going to tell us what to do. So we need to use git add file and to mark the resolution so we have resolved that conflict. So we do git add and then that file. And then to continue with a rebase, we do git rebase dash, dash continue. So git rebase dash, dash continue. Lets you get log dash, dash one line. And now we can see that we are from local computer. We're one step ahead of where GitHub is. And so if we look at our file on our computer, it says, Caleb is an awesome teacher, yada, yada, yada. This is a new line here. And if we go over to github.com and README.md, it doesn't have that line yet. It doesn't have, this is a new line here. We haven't added that. We need to add that still. So what we can do is push this code. So git push origin main, Doo-doo-doo-doo. And that was successful. So if we do get logged, dash, dash one line, we're going to be able to see that origin head is exactly where our head is at. And it's saying from local computer. So if I refresh this, this line here should say from local computer, this line should say six commits. And there should be a new line down at the bottom of the read me, let's refresh. There's that new line. There's that from local computer and there is the sixth commit. We have now just resolve a conflict. That is actually a pretty advanced thing for us to do. I was hoping we could get away without doing that in Git and GitHub one-to-one, but that's okay. We would've had to eventually tackle that regardless. So it's good that it came up. 21. Your project: Let's talk about your project. Your project. This is very, very important. First of all, if you don't have a GitHub account, create a free GitHub.com account. If you don't have good on your computer, install Git, that's very, very important. Then I want you to create a new repository on GitHub.com. Pull your repo from GitHub.com to your computer. Edit a file on your computer. Push that file to github.com. Remember you're going to need to use Commit and you're going to want to use Git status a lot. And lastly, take a screenshot of your GitHub repo and share it with the class. And so that's really all I want you to do now this sounds like it's going to be a lot. You should already have a free GitHub account if you don't, that's gonna take you a minute. If you don't have good, that should take you about five minutes to install. You can create a brand new repository on GitHub.com. That's only going to take you about a minute. Pull your repo from GitHub.com to your computer. There's a little bit of intricacy in here, so you're going to need to open up a terminal or command, or PowerShell or whatever program you want to use. You just need some sort of command line program. And then you want to run git clone. And then whatever that link was, HTTPS, github.com slash Caleb Darlene slash test repository dot get. I think that was the link. So you're gonna wanna run something like that, but it's going to be your account. And then you'll repository named dot git. So you don't want to make sure you run that on yours, not on mine. You wanna do it on your repository in your account. Then edit a file on your computer stage and push that file stage, commit and push that file to github.com. And take a screenshot of your GitHub repo with the new commit in there, the new file that you added and share it with the class. That's it. So all in all, this should only take you about 25-30 minutes. And don't forget if you have questions, you can ask them down below, or you can ask questions in the learning to code Facebook group. I am always there to help people with questions.