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
