Hi, everyone, welcome. In this video we are going to learn about Git and GitHub, why they are important and also how to use them. So we're going to start off going over the terms and concepts that you will use in git, and the ecosystem and then get into practical applications. This tutorial will include everything from basic Git repositories, to what is GitHub, to some more intermediate concepts like branching and merging and forking and that kind of stuff. I want to quickly introduce myself, my name is Gwen. And I run a YouTube channel called Faraday Academy, where I upload coding tutorial videos. And I also do a couple of live streams a week, mostly on Python and JavaScript topics, as well as some more general purpose coding videos. You can also find me on Twitter, and Instagram and pretty much everywhere by typing in Gwen Faraday. And let's get started with the tutorial. I want to start off here by defining what Git is. Git is what we call a version control system that is free and open source. And it's the most widely used version control system in development. Today, most programmers interact with Git on a daily basis. So what is version control? version control is basically a way that we as programmers track our code changes, we basically save an initial version of our code into Git. And then when we update code, we can save it into Git again, and again and again and again. And throughout time as our code continues to change, we can look back at all of the changes we have made over time. This helps us to see and understand what we did when, as well as track down bugs, or go back to a previous version of the code if we need to. So let's look at some of the terms that you're going to see in this video. First of all, I use the term directory, which is also known as a folder on your computer. When I reference the terminal or command line, I basically mean an application that runs on your computer, which is just an interface where you can type in text commands, you can navigate around files and folders, create files, change update things, install and run programs, and much more. You might also hear me use the term COI, which is just the command line interface. Many programs that you install, as a programmer will require you to interact with them via text commands in the command line. So you will be typing out some text and hitting Enter instead of say double clicking on a folder icon on your desktop. Just think of it as another way to run a program. Now you might be wondering, why are we going to use the terminal or command line instead of using one of these beautiful applications that handle interacting with get for us? Well, as programmers, it's always good to use the terminal. So you learn the Git commands in workflow of Git as well as become accustomed to it. As a developer, you are going to be using the terminal a lot to install, see allies run programs, search for things, etc. Throughout your development career. And learning Git is a great way to get started with the command line. CD stands for change directory, it's basically the same thing as when you double click on a folder using the icons on your desktop. While in the command line, if you want to move into a folder, or even up to a parent folder, you'll use CD, followed by the directions to get to whatever folder on your system you want to get to. A code editor, of course is a place to write code. You'll probably see this in a lot of different programming videos. But just in case you are unfamiliar with it, you can write code anywhere in a text document, word processor anything. But there are special ones that are designed with lots of tools and features for programmers. And these are called code editors. Now some people get confused by the word repository because it has multiple meanings. But in the world of programming, it usually refers to a git repository, which is basically just your project or the folder place where your project is kept. You can call it a repository. People also sometimes confuse Git and GitHub. Now Git is the tool that tracks the changes in your code over time. GitHub is a website where you host all of your Git repositories. Being online, it makes it easy to work in groups with other people, and organize your projects into a portfolio for you to show potential employers. So here are some of the Git commands, we're going to cover in this video, which you will be typing into your terminal or command line on your computer. They are clone, for example, if there's a repository that is not on your local machine, but it's on GitHub, and you want to bring it down on your local machine, so you can use it locally, you use the clone command. By the way, all of these commands are lowercase, not uppercase, as we're going to see, as we go through the examples in this video, when you have updated files, or created or deleted files and folders, you're going to want to tell get that you made changes and that you would like Git to track those changes. So you use the Add command for that. As I said earlier, Git is there for you to save the changes you make in your code. So you do that through a commit, and we call it committing your changes. Once you have made changes locally on your computer, and you're ready to put them in git, you tell Git to track them through the Add command, you save your files to get through the commit command. And then you upload your files to a place like GitHub, or another what we call remote repository, or GitHub alternative, like Bitbucket, get lab, and there's many of them, you do this through the push command. When there are changes to your code on GitHub, and you want to bring those to your local machine, then you use the pull command, you pull down changes from the remote repository. Those are all the commands that I want to cover. To get started. Again, we're going to go over examples of each of these. The first thing you will need to do is of course, sign up for an account on GitHub. This is pretty straightforward. You enter minimal information, and then you sign up for an account, you will get an email that will ask you to verify and then you can log into your account. When you log in, you will either be on this page, which is your profile page that you can access from this drop down menu, or you might be on the dashboard page here. Either way, you will have access to this green button here, or this plus sign and the drop down here where you can create a new repository. Now a repository is basically a project. It's all of your coding files and folders for whatever kind of application that you're building. For example, this is a repository that I have, it's for a curriculum app that I've been building, you can see the mockups pretty straightforward application. And in this repository, this is my complete project with the folders and all of my coding files are inside of these folders. For this one application, each application or project is in a separate repository. So I'm going to go ahead and create a new repository here, give it a name demo repo. By the way repo is just short for repository. I'm going to leave these settings as they are and click Create repository. Now you can create your files and folders for this repository locally on your machine. Or you can create them straight in the online editor on the GitHub website. So I'm going to go ahead and create a basic markdown file called a readme. And this is the most basic file that you will find in almost every project that contains text to describe what the project is about what it does, and any other relevant information. So I'm going to click here, create a new file, I'm going to name it readme.md for markdown. markdown is basically an easy way to format your text in these sort of files. So I'm going to come down here and type some text. Now markdown has all the shortcuts like one hash tag for a main header. So I'm just going to put demo here and then some plain text, so I'll put some description. And then I'll scroll to the bottom to commit the file. In other words, save this file. I just want to point out really quickly that this create readme.md is placeholder text. But if you don't write anything else here, and when I commit this, it will use this text as the default. So let me commit. And you can see here that this is the commit message from when I saved this README file. And now you can see the readme file, which because it's named README, dot MD is the default file that GitHub always shows down here. I can also go into the file here, which is the same thing, except with a few different options here. And in either screen, I have this edit this file option. So I'm going to go ahead and do that. I'm going to simply change this to an exclamation point. Now the default text instead of create readme.md is now update readme.md, which isn't that descriptive, but it's okay for right now. So I'm going to commit, and by committing, I saved my changes here. And if I go to the demo repo, it shows my last commit message here as update readme.md. Now, if I want to see my entire history of changes, in other words, every commit that I've made, I can come here to commits. And each commit has a unique identifier. And I can also see the message or the title that I wrote on these commits, I can come back to this one and see what was added this green with the plus signs means these lines were added to this file. And then I'll go back, and in the updated commit, it shows me this red with a minus sign, that means this line was deleted, and then the green with the plus means this line was added, anything that's white means it stayed the same. So this is a very basic view of seeing changes. Now what about using this on your local machine, if you are using a Mac or Linux operating system, you should already have Git installed. You can check this by opening your terminal or command line application and typing in get space dash dash version. If Git is not already installed, I highly recommend checking out this tutorial by Atlassian, which I will link in the description below. It walks you through how to install Git on any operating system. Now I do want to note for the Windows installation, when you download the get Windows Installer, I recommend you choose the Git Bash option from the install menu. You can of course use Command Prompt and it will set up get in command prompt for you. But in the past, I've had an easier time with Git Bash on Windows. for Mac, it gives you a few different options for install. But I highly recommend you use the homebrew package manager if you can. And it takes you through all of the steps here. But again, you probably already have Git installed if you're using a Mac or Linux and don't need to worry about this. There's just one more piece of setup before we continue with the rest of the Git tutorial. And that is getting a code editor. Of course, you can write code in whatever you want. Any type of word processing software we'll do from Notepad, Microsoft Word, but there are specific ones may for coding, and many of them are really good and free. Visual Studio code is a free code editor made by Microsoft is widely used with people learning to code and professionals alike. So you can install it for free from code dot visual studio.com. It's available on every major operating system, Mac, Windows and Linux. Now I have Visual Studio Code open with no files or folders inside. If you haven't used this before, then all of these icons on the side are how you're going to navigate around your project and use your tools. So I'm going to come to this top one. And this bar comes out where I'm going to see all my files and folders, I'm just going to open a folder real quick. In this test folder, when you go to my git, then this is an empty folder that I have, I'm going to click Open. And now I have a folder that's open in Visual Studio code that I can actually add files and folders to but I'm not going to right now because I'm actually going to pull the repo that we created at the beginning of this tutorial here on GitHub, I'm going to pull that to my local system using Git. So in Visual Studio code, I have access to a terminal from here that I'm going to use. If I come up to the top, in the View menu, I'm going to come to terminal and select it. And now it opens this terminal here. By the way, the only reason why this is good is because my folder is named Git. And because I've opened the folder here, it automatically uses that as the directory for my terminal. So now I want to clone down my repo to my local machine. I want to pull all that code down here so I can work with it locally. I'm going to use a command called git clone. And then in clone or download here, clone with SSH Exactly what we just set up. So I'm going to copy this, go back to my terminal and paste. And I'll hit Enter. And now we can see a folder here, which is my repo from GitHub that's pulled down into the directory that I'm in. So I'm going to move inside this folder real quick from the command line, which I can just do by CD, and then the name of the folder to change directory into the folder. So now I am inside of the folder demo repo, which was the name of the repository we created on GitHub. So when it pulled it down, it gave the folder this name, so my whole repositories inside of that folder, and now it says Git master. Now, this may look different on your machine, this part looks different on every machine. I have a specific setup to make it look like this. But either way, you will probably see some kind of indication that you are in a git repository now. Now, how do you know this looks like a regular folder and a regular README file? Well, there's actually a hidden folder that you can't see here. And that you won't see on most operating systems unless you have selected to show hidden folders. And that is called the dot get directory. So there's just a special command in my terminal that I will use to show you that folder. Now the LA command that I use here is actually a Mac shorthand for ls space, dash l A, which means list everything in the directory, including hidden files and folders. So if you're not on a Mac, I don't think la will work for you. But you can use ls space dash LA to do the same thing. So you can see, here's the readme file, and then there's something dot Git. And because it's blue here, that means it's actually a folder. And this hidden Git folder, actually stores all of the files that save your commits, or your code changes over time. It has all of the changes recorded in the history of this repository, which includes the ones we made on github.com. So now let's make some more locally, we're going to go into the readme file, and come here and add a sub header. Not too creative, I'm just going to call it sub header, and then some more text. Now that I have changed this file, I need to save the changes in Git. So I do that through a commit still. So first, I'm going to use the git status command. Now the git status command shows me all of the files that were updated or created or deleted, but haven't been saved in a commit yet. So for example, if I come here, and I create a new file, I'm going to call this index dot HTML. And I'm just going to put a quick div inside with nothing else. And now let me rerun the git status command. And now you can see I have one file that's been modified. And one file that it says is untracked, meaning Git doesn't know about this file yet. So you have to tell Git to track the file before you can save it to get to do that, you need to use the git add command, and then tell it which files to track. Now most of the time, or a lot of the time you see people use a period, which means you're telling Git to track all of the files that are listed here, in both the untracked and the modified section. So both the changes we made to read me and the new file index dot HTML would be staged with Git if we did git add period, because includes all of the files, you could also optionally tell it just the names of each individual file or folder that you want Git to track. In this case, I'm just going to use the dot. Now I'm going to use git status again. And now you can see that all of the changes have been tracked. That's why they show up differently now, and they are ready to be committed. So I'm going to come here and do git commit dash m. now dash M is for message. And you need to have a message in order to commit your files. The message could be one character in meaningless if you want, but there needs to be a message. And ideally, that message should have something to do with the what and why behind the commit you're making. So I'm going to add a message here. Added index dot HTML. And this is just the title of the message. If you remember from the web interface, there were two boxes, a title and a description. This first dash M and what's inside of the quotes is a message You can add a second one for the description box. So I can say some description. And I'll click Enter. And now it gives me some information, two files change five insertions. But we've still only saved our code locally. The commit isn't live on GitHub yet. We make it live by using another Git command called git push, which means I want to push this live to a remote repository where my project is hosted. In order to push them to GitHub under your account, you're going to have to prove to GitHub that you are the owner of your account. So you have to connect your local machine to your GitHub account somehow. The way this is done is by using SSH keys, you need to start by generating a key locally using the SSH key Gen command, then you specify the type of encryption, and then the strength of encryption. And at the end, you need to include your GitHub email address, this is just a test for me, because I already have key set up. So I'm just going to put a fake email address. But make sure that the email address you enter here is the same one you use to log into your GitHub account, click Enter. Now, the default file for the SSH key is inside your user directory in the dot SSH directory, and it will be called ID underscore RSA. I'm going to give it a different name here, because I already have a key under that name. You can optionally enter a passphrase for your key here, or leave it blank. So I'm just going to click Enter to leave it blank. And my key has been generated. Now I am going to search for the key that I just generated. And now I find that there are two. So there's test key and test key dot pub. So test key dot pub is the key that you're going to upload to your GitHub interface. pub stands for public, it's called your public key, which means that it's okay for other people to see this key. The key that was generated without the dot pub extension is called your private key, and is the one that you have to keep secure on your local machine, you don't share this key with anybody. How it works is that the public key you put on GitHub, and then every time you want to connect to GitHub or push your code on GitHub or use your account via your local machine, you use your private key to show GitHub, that you are the one that generated this public key. It's a mathematical proof that only this private key could have generated this public key. I'm going to print out this public key. And your key should look something like this SSH dash, RSA starts with this, it has a bunch of characters in the middle and it ends with your email. Now you need to copy this whole key, which you can do by highlighting it in your terminal or command line, which automatically copies it, you don't need to do Ctrl or Command C, because Ctrl C actually means something completely different in the terminal, not copy. There's also a terminal command that allows you to copy it's called PB copy. And then you do the less than symbol and then the path to your file. So it's in our user home directory. And I didn't actually push it, put it in the dot SSH directory, but this is the directory you would have your key in. And then it's just test key dot pub. And now it's copied to my clipboard on GitHub. I'm going to go to Settings. And in the list of all settings, I'm going to go to SSH and GPG keys, and you can see any SSH keys associated with your account. Then you just click on new SSH key, you can give it whatever title you want. This is just for your reference. And then you paste your key in here. And I'm going to remove the extra enter at the end. And now add SSH key to confirm my password. And now you can see my key was successfully added. The only thing left to do is to make sure that your local Git command line interface knows about the key you just generated. And I'm going to link all of these steps in the description below. You need to start the SSH agent. Then if you're using version 10 point 12.2 or later, you will need to modify this file your SSH config and add this text to it. I'm going to just show you how to get into that file. Now. Paste the location of the file in your SSH directory and then anywhere in this file, perhaps at the end, you can paste in that information. I'm not going to do that because I already have my file set up So I'm going to delete it. After you do that, you'll run this SSH add command from your terminal. And then your key will be set up to work with Git. Again, all of the information that I covered with keys here is going to be linked in the description below. But this is the general way that you will do it with any operating system, although there might be some slight variations. Now there are two more arguments we have to put here. The first one is origin. And the second one is master. Now origin is an option set for us here, and is basically a word that stands for the location of our Git repository. Master is the branch that we want to push to. And we'll get into what that means in a minute. When I click Enter, and now I'll refresh this page. And you can see my code changes are all live on GitHub. Now, you can also see that there are three commits to that we made online on github.com, and one that we made locally and pushed up to github.com. Of course, this was our commit message that we made locally. And this was the description that we wrote, after that second dash m, we can see all of our file changes that we made locally here as well. So this was to demonstrate how to create a new Git repository using GitHub. But what about if you start a repo locally, so let me exit out of these. And I will create a new folder here called demo repo to drag it outside. So now it's in a completely separate folder from the other Git repository that we have. But this one's not a git repository yet, and nothing's in there. So I'm going to move into that folder in the terminal. Demo two. So now I'm in demo two, you can see it's not a git repository. Even if I look for that hidden Git folder, it's not there. So let me first add a file in here. And I'm again, going to add a readme file that MD and I'm going to add a header demo to and some text. Now, if I want to turn this into a git repository, I can use the command line and say Git init. And it says initialize Git repository in yada yada, this folder, and now you can see I have the get keyword there. And if I do get status, I can see there's this untracked README file, I will go ahead and add that file, either with the period or the name of the file. git status again, okay, so the file is ready to be committed. And now I will do git commit dash m, created README. And now I'll put a description here, and Enter. Now what if I want to push this live? Let's try git push origin master. And now you can see it's giving me this error fatal origin does not appear to be a git repository. Because we didn't clone this down from a git repository. We didn't already create this repo on GitHub, we created it locally. So Git is saying I have no idea where to push this to because it's not connected to anything. So we have to create that connection. And first, the easiest way to do this is by creating an empty Git repository up on GitHub. So I'm going to come here, create new repository, I'm going to call this demo repo to don't need a description, going to leave all this here. Now I have another empty repository. So to start pushing here, I'm going to copy this and say Git remote, now remote mean somewhere else, but not on this computer. We're going to use this to add a reference to the remote repository on GitHub. And then I'm going to say add origin and paste that link that I copied. And I can check that by saying Git remote dash V, and it shows any remote repositories that I've connected to this repo. Now that these are set up. I can now use git push origin, Master just as I did before. Now, there's a shortcut here, because if I don't want to type out this whole thing, every time in the future, I can just use git push, but I have to set something called an upstream, meaning this is where I want to push it to by default. So I'm going to do dash u for set upstream and then enter In the future, I can just use git push without typing out origin Master, it says to GitHub looks like everything was pushed just fine, I will refresh this page, and I can see the readme that I just added. So that's how you initialize a repository locally and push it to a remote location like GitHub. So let's review the workflows that we've gone over so far, and compare the flow of adding code in the GitHub interface versus writing it locally. So when we first started working in the GitHub interface, we wrote some code in the readme, and then we committed our changes we saved them to get now notice, there wasn't an added step here. And we never did a git add to stage changes. Well, that's because GitHub handles that for us. So really, by committing in GitHub, we are adding and committing at the same time. And then that was it really, because it was our repository, we had full access to change whatever we wanted, we could just update the code just by committing it in the GitHub interface. Of course, we didn't have to push the code because it was already live on GitHub. There's no other remote repository, because it's already in the remote repository. Now, if we didn't own the repository, or we didn't have access rights, or we needed other people to review our code, before we merged it in with all the rest of the code, then we would also have to take the extra step of making a pull request, which is something we're going to cover later in this video. So let's compare this workflow if we're just writing code on GitHub, versus doing it locally, and then pushing it up to GitHub. So luckily, in our text editor, we wrote the code. And then we had to do git add to let get know about the changes. And then we saved them to get using the git commit command. And then we push them to the remote repository on GitHub, using the git push command, and that updated GitHub source code or the code in the GitHub repository with our changes that were made locally. And then just like before, if we didn't have access rights, or we needed a code review, before we merge changes in, we'll need to make a pull request. So these two methods cover the most basic ways to use Git, by using the GitHub web interface and then doing it locally. If you have any questions about this, then please leave them in the comments below. Otherwise, let's move on to Git branching. Let's first go over some of the concepts of branching, and then we'll dive into a practical example. Now, what is Git branching? You seen in our examples that we're on something called the master branch. Now master is a naming convention for the main or the default branch in a repository. So if you're just working off of one branch, that's where your code will live, and all your code, all your commits, everything will be in that one branch. Now, this is called branching, because it starts to look more like a tree when you have multiple branches. So we saw earlier that we had a master branch, we were committing to that master branch. But we could also make another branch. We'll call it feature branch. So let's talk about what happens when we create a new branch. At first, the code on master and this new feature branch will be exactly the same. But as you make updates to the feature branch, those changes are only seen in the feature branch. So if you make changes on the feature branch, you make a commit to save those changes on to that branch. And then you switch back to the master branch, you won't be able to see any of the changes that you made on that feature branch. Each individual branch has no way of knowing what commits or what changes have been made to any other branch. Each branch is only keeping track of what changes are made on its own branch. Now you can continue to change the code on master branch and save it through a commit to the master branch. And then if you switch back to the feature branch, likewise, you will not be able to see the changes that you just saved to master. Why is this useful? It's extremely useful because you will be building out new features to applications that may break your code or they are not finished yet. And you don't want to save them to the main master branch. You want to work on them in kind of a sandbox area. So you can write all the code unit And get it correct and in the state that you want, before you merge it back into the main branch of the code base. And this is really helpful when you have many different people working in the same repository, or a lot of different branches going on at once. One very common thing that you'll see in development is that you'll be working on let's say, this feature branch for a week or more, and you have all of these changes that you've made. And then you find out there's this major bug that you have to fix real quick. So for that, we make this other branch called a hotfix branch here, represented by yellow. And you can see that I made the change in one commit to fix whatever bug was wrong with the code on its own branch, I made sure it was working correctly. And then I merged it back into the master branch. Now that we've gone over the concepts of branching, let's dive into the command line and try it out. And now I'm using a full screen terminal just so I have more space as I'm running different Git commands that are going to take up more screen space to show you, but it works the exact same way as the terminal inside of VS code. So I'm back in my terminal inside of my demo repo again. And you can see here I have information about my git branch. Again, you might see this presented in different ways it shows you're on the master branch. If I type in git branch, you can see that I currently only have one branch and its master. And you can also see there's a star beside it. And that means that I am currently on that branch. So I'm going to hit the letter Q here to get out of that. And now I'm going to create a new branch. So I do that with git checkout. And git checkout is what you will use to switch between branches. But to tell it to create a new branch, use dash B, and then you give it the name of your branch. So in this case, I'm going to call it feature. Now if you're working in real application with people, you want to make this name as descriptive as possible. Some people like to use feature slash the ticket number or description, or you can use hyphen. And then you could give it the issue number, like if it's a GitHub issue number 11, or whatever convention you want to use. And then you can make this longer if you want and put some more details. I'm going to call this feature dash README instructions, because I'm just going to be updating a section of the readme. Click enter. And now it says I switched to a new branch, meaning I created this new branch called feature README instructions. And now you see that my branch changed. So now if I do git branch, again, I have two branches listed here, and the top one is starred and highlighted. So it shows me which branch I'm currently on, I'm going to hit Q. And like I mentioned, git checkout, will switch between branches. So now that I am on this feature reading instructions, I can check out master. And now you see I switch to master. I'll do git branch shows them on master now. And I will do another git checkout feature, README instructions, you see that I hit the tab button, and it autofill the rest of the branch. So I didn't have to type out the whole long name, you can also hit tab. Even if you don't start at the beginning, like in this case, I started typing feature and then hit tab. But I could actually start typing instructions and hit tab and it's still autocompletes. Now this is very useful. Because eventually, when you work in a repo, you're going to start a lot of stuff with feature or with bug or hotfix or whatever. So only your last few words will be unique. So that's just something useful to know. So now I'm back on the feature README instructions branch, and I'm going to make some changes on this branch. So I'm in my code here, I'm going to come into my README and make a new section. I'm going to say just local development or something and then give it one step other than say open index dot HTML in your browser, just as a demo. Alright, I save that. And you can see in VS code, it gives me this m here meaning it's been modified. since I've last checked this into get. That's kind of a nice feature to have to see which files you've added and which files you've modified right in your text editor. Alright, now that I've modified some files, Here, I'm going to do the git status command again. And it says I modified README. So first, I'm going to save things that have changed on this branch. So I'm going to do the git add command. And I'm just going to stage the readme changes. And now I will do a git commit, dash m, and say, A, oops, I have to put that in quotes. So updated. README. Okay, so you can see I have one file changed for insertions. So now it's saved to get, but it's only saved on this feature, README instructions branch. So if I do a git checkout Master, come back to my code. And you can see the changes aren't here, because they're only on that other branch. Now, if I want to here, I can go ahead and merge these two branches locally, using the Git merge command. But before I do that, I just want to double check and see the code that emerging in which I can do through the git diff command. Now, diff, or diffing, shows me what changes have been made, it compares two versions of the code and shows me all of the lines that have been changed. And you kind of saw this in the Git interface, because you saw a nice visual representation of the diff, where it showed in green with a plus sign the lines that had been added, and then in red with the minus sign the lines that had been removed. And let me say git diff, and the name of the branch, hit Enter. And now you can see, it shows which file it's talking about this readme.md file. And in white, it shows text that was already been there, that hasn't been changed. And then it shows that my master branch doesn't have some of the changes that are in my other branch. So I'm going to hit q here to get out of this. Alright, now I could go ahead and like I said, use the Git merge command, passed in the branch, and it'll merge in those changes. But the more common pattern that you are going to see is pushing these changes on that branch up to GitHub, and then making a PR, so I'm going to change back to the feature branch, and now do git status. And it says I have no changes to commit, because they've already been committed. But I do need to push them up to GitHub. So let me run git push. And now you can see, since I'm on a new branch, it says that I need to tell it which branch on GitHub I want to push to. Now the answer is almost always that the branch will be named the same thing on GitHub, and on your local machine. So I could copy this line. And now you'll notice this set upstream flag here is the same thing that we were doing before with the dash U. It's just shorthand for set upstream. So I'm going to hit enter here. And now it's pushed up to GitHub. And it's even giving me a hint for how to create a pull request on GitHub, by giving me these instructions here. So what is a pull request or a PR, it's basically a request to have your code pulled into another branch. In the example we're using today, we have a feature branch, and we want to have our code pulled into the master branch. So we make a PR from the feature branch to the master branch. Now once we have made a PR, anyone can review our code, comment on it, ask us to make changes or updates. Now, after you make a PR, you can also update the code just by making additional commits and pushing them up to GitHub, as long as it's on the same branch that you're making the PR with. Once the PR is merged, you'll generally delete your feature or source branch. And to switch back to the master branch. Then when you want to make additional coding changes, you will create another new branch and start the process over make your commits, make a PR and then merge again. And I could go straight to this URL, but I'm going to show you how to do it manually on GitHub first. So I look at my GitHub interface. And you can see already GitHub picked up on the fact that I just pushed a new branch. So now it's asking me right here if I want to compare this new branch to another branch and create a pull request, and it takes me to this screen here. Now sometimes this is confusing for people which branch is being merged into which branch This GitHub interface does a pretty good job because of the arrow. So you can see that the branch you're comparing this feature, README instructions will be merged into the base. So there's always a base branch where all the code is going to get merged into. And then there's the branch you're comparing. So now I have this message, I have a title, it says updated README. And I can put some more description here. So usually, I'm going to put a list of the changes that I've made and maybe some description as to why I made certain decisions. So here, I'm just going to say added section about local development to the readme, and I will create a pull request. Now that I've created a pull request, I can actually come here in the interface, I can see any comments that people have made on the pull request, or I can write more comments of my own, I can look through all the commits I've made that I'm trying to merge into master right now. And I can also look at all the files that have been changed, and see the diff of what's been added, removed or updated. Another thing I can do right here is if I want to make a comment about a particular line of code that I've written, I can press the plus button, this blue plus button. And now I can make a comment there, I'm just going to say, add a new sub header and add it as a single comment. And you can see that the comment appears at the line of code where you hit the plus button. This is a really nice way if there are multiple people working on a repository to make comments about specific lines of code. And then usually the person who created this PR will reply to them with an explanation or make another commit, if changes need to be made to the code or something. Alright, so I'm going to go ahead and merge this PR. And you'll notice that I added the single comment, it says resolve. Now because I'm the owner, here I have full permissions, I don't have to resolve I can still merge the PR, if you don't have permissions or your repo set up in a certain way, then you might have to resolve comments before you can merge. Anyway, I'm just going to merge here, confirm and merge successful. Now that the PR is merged, I'm going to go over to the code. And if I scroll down, you can see that I am on the master branch. And my changes are also here. So the branch was successfully merged. So locally, now I'm going to switch to the master branch. And if you look at the code, the changes aren't there yet. And that's because they are only on GitHub, and I need to pull them down to my local environment. So to get the changes on my local master branch from origin, I'm going to do Git pull. Now, if I didn't already set the upstream, I would have to do Git pull origin master. But I already have an upstream set here. So I'm just going to do Git pull, and then enter. And you can see one file changed for insertions. And now if I look at my code, I can see my local master has also been updated with the changes from the branch. And now that I am done with that feature branch, I'm going to do git branch. And it's still there, even though I'm not going to be using it again, because you don't really reuse branches that you've already merged into your master branch. So I'm going to go ahead and delete this branch. So I'm going to do git branch, dash D, and then the name of the branch. And again, I can tab over. So I'll hit Enter. And now it says I deleted that branch. So now if I do git branch, and I only have master again, alright, well, that's all fine and great and works well. But in real life, you're not always going to have such an easy time merging. There's something called merge conflicts in git, where basically, you're building your own code writing a bunch of code on your own branch. Maybe other people are writing code on their branches. And master is getting updated from multiple different places. So it's possible for multiple people to change the same files. And so sometimes Git doesn't know which code you want to keep, or which code is redundant, or which code you want to get rid of. So you'll have to manually do that. Let's try that out. Let me create another branch. I'm going to do git checkout dash B. And then I'm just going to call this quick test. Alright, I'm on the quick test branch. Now I'm going to come into index dot HTML. And I'm going to add a p tag here, and say world. And P. Alright, so I modified this file, let me go ahead and do git status, it's always a good idea to do git status before you commit anything looks good. What I can also do from here is do a git diff, enter, and it shows me all of the changes that I've made since my last commit. So I'm going to hit Q, and now I will commit these. Now generally, the workflow has been git add, and then file name or period dad, everything in this directory. This time, there's a shortcut, because we've just modified one file. And the file has already been committed to get in the past, which is why it says modified and not created. So what I'm going to do is git commit. And then instead of dash m, I'm going to do dash A, which stands for ad and M at the same time for message, then I'm going to put my commit message. So this basically adds and commits at the same time. But it only works for modified files, not for newly created files. Because if it's newly created, you have to stage that with Git and let get know about it first. For my message, I'll just say added world. Okay, and now I have one file changed to insertions. Now let me go to my master branch git checkout Master, you can see I don't have the changes from my other branch there. But what if I updated the same line, so on Master, now I'm updating line two. And here I'm going to put there so hello there. So now master has aligned to but the new branch I created also has aligned to now everything is fine. Now because both branches are separate. But what if I try to merge these two together, whose line two is going to be put there. So let's try that. I'm going to go to my quick test branch. So I'm going to do git checkout. quick test. And now it's actually giving me an error and not letting me change branches. Because I have local changes that line to that I added in Master, it says it's going to be overwritten if I change branches. So it's asking me to commit before I change, so that way that line two will be saved to get in the master branch, and won't be lost when I change branches. Now stashing is a little bit beyond the scope of this tutorial. But it's basically a way for you to stash your changes somewhere. And then you can retrieve them later. But it's not making a commit to get. It's like a temporary holding place. So we're not going to do that, I'm just going to go ahead and commit. So let me do git status first. All right, and I'm going to use the shorthand because I only have the modified file there. So I'm going to do git commit dash AM, and then a commit message, I'm going to say added there. And now I should be able to check out and press the up arrow key, I should be able to check out this quick test branch. And before I merge master into this branch, I'm going to diff against master real quick. And it shows me the changes here. So now I'm going to do merge, Master. So remember how I said before that merging locally wasn't the regular pattern. While it isn't for merging branches into master. But Master gets updated as you go along as you're working on your project, because maybe other people are merging into master and you don't have those changes in your branch. But you don't want to get too far behind the master as you're working because then it's going to be really difficult to merge later. So as changes are made to master in the GitHub repo, you're going to want to pull those down to your local master branch. And then whatever feature branch you're working off of like quick test here, you'll want to use Git merge master to keep your branch up to date with what's going on in master. So that's what we're doing here. Git merge Master, hit Enter. And now it says we have a conflict. So we have a merge conflict in index dot HTML. So there are a couple of ways to fix merge conflicts. interfaces like GitHub, give you an interface to fix them. You can also fix it in the terminal. But the easiest way to fix merge conflicts is directly in your code. A nice code editor like vi code will let you click buttons like accept the current change or accept incoming or take both of these. But you can also come in here, make the changes that you want and delete these lines that get added this, let's get know that there's a conflict. And first between this head and these equal signs, it shows the code that we have on the current branch that we are on. And then it shows the code coming from the other branch that we're trying to merge in. So in this case, I am just going to delete these lines and save both of the changes. But in this case, one, two, line two and one, two, line three. And this is just letting get know what we want to do, because it didn't know how to handle the conflict. Now we have handled it and deleted the conflict markers, we can now look here and see that we need to make another commit, even though it seems like we are adding and subtracting the same things, we basically need to make a commit because we have fixed the merge conflicts. So I'm going to say here, git commit dash a m, and I can say merged in Master, or updated with Master or something like that. And now I've officially updated my branch with the changes that have been happening on master branch, and I can continue coding whatever feature bug fix or whatever I'm doing on this quick test branch. So what if we make a mistake? What if we accidentally add something or commit something to get, and we didn't mean to do it, we can actually undo our stages or our commits. So let me come to read me, I'm going to add another line here. And say, have fun. Okay, so I've made a change here on line 12. And back in my demo rebill, I'm going to do git status. So now let's say I want to git add this README. And let me do git status again, and you can see before is that change is not staged, and now changes to be committed, meaning they've been staged already. But what if I want to undo staging, what if I didn't mean to stage this file, I can actually easily undo it by using the Git reset command. So I can either do Git reset with no arguments, or I can say Git reset, and just the name of the file that I want to onstage. So here, I'm just gonna do the plain Git reset, and it gives me a list of the files. So unstaged changes after reset README. Now, if I do another git status, it shows me that this file is no longer staged. So what if I want to undo a commit, so let me go ahead and add the readme file. And then I'm going to come and commit, read me, and I'm going to say added install step. Now, if I do git status, you'll see there's nothing to commit, because all changes have now been committed. Well, if I made a mistake on that commit, I can use that same Git reset command. And this time, I'm going to say Git reset head in all caps. And what head means to get is a pointer to the last commit. So I'm telling it to do something with the last commit. And then I'm going to save till the one, which is telling Git instead of pointing to this last commit that I just made, right here, I want you to go back one commit further, and head will now point back one commit further meaning it will completely undo the commit that I just made. Let me click Enter. And now you can see it says I unstaged, the changes. So I'm going to say git status. And what happened was that it unstaged and uncommitted, those last changes. So if I do git diff, you'll see that Git picks this up as a new change now. Now, if you have many different commits, you might want to go back to a specific commit or undo multiple commits. And for that there's no quick pointer in Git like the uppercase head pointer, where you can just look at the last commit or use that to undo the last commit. But you can see a log of all your commits. And you'll see that these are arranged in reverse chronological order. So this is the latest commit that we made. And you can see with the commit message, that's also why it's important to write a good commit message because it's easier for humans to scroll through and see which commit is which to get these commits are differentiated with this unique hash here. So if you want to go back to a certain commit, you can copy one of these hashes. Let's say I want to go back to added world before I added the there line. So I want to basically undo when I merged this there, from Master into this branch. So let me copy this commit hash. And by the way, when you see all of these commits, you can scroll down with spacebar, and now it shows this as the end. So I'll say quit. So I'm going to do Git reset, and then the hash of that commit. And it's unstaged, any changes made to these files after this commit. So you can see the changes are still there. I added have fun and this line three in the index dot HTML, but they are just not saved in Git or stage with Git any longer. So what if I was just testing something out, and I want to get rid of all of the changes after a certain point? Well, I can do that by using the Git reset command as well. Let me just grab a commit hash. So I'm going to go back just a couple of random commits to this commit right here, where I said updated README, can I hit Q. And now I'm going to do Git reset dash dash hard, meaning I want all of the changes to not just be unstaged, but to be completely removed. So head is now pointing to a different commit, because I've undone several commits now. And if I look at my files, we've just completely gone back in time and erased the latest updates. So those are the basics of branching, merging, fixing merge conflicts, and undoing staging and commits that you've made. One more thing that I want to quickly mention is forking, you may have seen this already in the Git interface, you can hit fork here, and then it's going to make a complete copy of the repository. Now, why would you want to fork? Well, you probably don't want to fork your own repo because you already have full access to all of the code here, but you don't for other people's repos. So let me find just a random repo on GitHub. Okay, so here's view, j, s. So let me click on this. And I actually don't have access to change anything in this repo. So if I want to make a PR against this repo, and request for my changes to be added, or if I just want to be able to branch off of the code in this repo and do whatever I want with it, then I want to fork it. So I'm going to hit the fork button here and fork it to my user account. These are just groups that I'm a part of on GitHub. Sometimes it takes a minute to fork over all the code, especially with Vue JS because it's a large repository. Alright. And now you can see the repo is no longer under the View, j. s organization. Now it's under my personal GitHub. And now that I've forked this, I have complete control to make any updates or changes that I want to this code. So if I want to come in to read me, and hit the pencil, update this, I can say, Hi there. And now I can come to the bottom and commit changes again. So I can say, updated README or whatever I want, I'm just going to leave it with the default text, again, commit to the dev branch. So before we worked off the master branch as being the default branch, but sometimes when you're working in a larger project with other people, you're going to want to create multiple branches, like master staging, and dev for different kinds of environments. So in this case, Dev is set to the default branch for this repository, instead of master. So I'm just going to commit my changes directly to Dev. And you can see my changes here. Of course, they aren't part of the main view j s view repository, but they're part of the one that I forked because I forked a complete copy of that repository, including the branches associated with it. And you can see dev is marked as the default. So now what if I wanted to get my changes back into this Vue JS repository? Of course I don't, but what if I did, I would go and create a pull request. So new pull request, and then as my base the place that I want to merge my changes into I would put the repository that I forked from this Vue JS repository, and the branch and I want to compare that with My repository that I forked and the branch on my repository that I updated, of course, I'm not going to click Create pull request, because this is just a demo, I can also see the diff down here of the changes that have made and what commits I've made to this branch on my fork. Now, if I want to merge within my fork, I can do that easily. Let's say, of course, there isn't anything to compare because I'm comparing the same branch here. But I could merge into any other branch. Let me find master here. So I could merge straight into master. And you can see I can create pull requests. Now, I created a pull request. And I'm going to create pull request. And you can see they had a bunch of default text added to the pull request information. But I'm just going to go ahead and merge. Go back to the code. If I scroll down, of course, I'm on Dev, it says hi there. And now if I go to master, it also has my changes on master because I merged them. Generally speaking, after we merge a branch into one of our default branches like Master, then we would clean up the branch that has just been merged. In other words, we would delete it from GitHub and from our local machine, because we're not using that branch anymore. But it's a little bit different when we use branches like Dev, staging and master, because generally, you're merging your feature branches into either dev or master. And you have Dev and master and sometimes staging reserved for just merging into so you don't make any changes on Dev and master themselves. You'll just be merging other branches into dev or Master, depending on how your codebase is set up. In a large project like Vue js, we would merge all of our feature branches or bug fixes or whatever into the dev branch and then delete the branch that we just merged in. And then when all the changes on the dev branch are ready, those get merged into master. But dev never gets deleted, just like master never gets deleted, those kind of stay around forever. All the other branches are just temporary. So me having my own fork allows me full rein, full access, full control of CRUD operations, create, read, update, delete whatever I want to do with all of this code, all of these files. And if I want to make some major updates, what I'm going to do is fork the repository, which I already did, pull my fork down to my local machine, make all the updates that I want to test them out whatever I want to do, I'll push them back up to my fork, and then I will create a PR against the original repository. Thanks so much for watching. I hope that you enjoyed this video and that you also got something out of it. If you did, then don't forget to like the video and subscribe to the Free Code Camp channel. Don't forget to check out my YouTube channel called Faraday Academy where I do weekly videos and livestreams on Python and JavaScript and other related programming topics. I would also appreciate if you would leave me a comment here and let me know what you liked about the video or any other feedback that you might have. Have a great day and I hope you enjoy using it