Git Tutorial for Beginners: Command-Line Fundamentals

hey how's it going everybody in this video we're going to go over get command line Basics we're going to talk a little bit about what git is and then we're going to walk through how to get get installed and then the basic commands for working with local and remote repositories I'm going to use a couple of images in this uh walk through and these images were taken from the prit book written by uh these two authors here and it is licens under the Creative Commons uh if you want to read the book which is uh great resource you can go to the git website click on the documentation and the book is listed there so this video is going to be useful for three different types of people uh first of all somebody who has never used Version Control before this is a great place to start because git is the most widely used Version Control System out there um second for people who have used Version Control but not get so if you're coming from a version control system like SVN uh then it's going to be great to learn about git also and third this will be useful for people who have used git but have mainly used the guey visual tools so the guey tools are really useful but it's better to learn these command line tools from the very beginning because uh the goys can only do so much and you'll eventually run into a situation where you get stuck and the underlying knowledge of the command line would be extremely useful so with all that said let's go ahead and get started so first of all git is a distributed version control system so if you're coming from a version control system like SVN which is a central Version Control System then what is the difference between central and distributed Version Control well a central version control system is located in one place so people can check out from this central location and make their changes and then check everything back in but this can be problematic if you can't get access to that Central server or that Central repository um so for example if that server's offline or you're working somewhere that doesn't have a network connection then you'll only be able to see the files that you've checked out from that repository and no additional information about that Central remote repository also if something happens to that Central repository or it somehow gets corrupted then you've got to hope that there's a backup of that code somewhere now on the other hand a distributed Version Control System like git in this situation everybody has a local repository so you can have the option to have that censal remote repository uh which we'll look at here in a little bit um but your local repository has all of the information that your that your remote repository has based on the last time that you sync those two together so the good thing about this is that if you don't have access to that remote repository then you can still view every single change that's been made to that repository since it was created so in a way it's almost like every developer has an entire backup of the repository so in the worst case scenario of something happening to the remote repository every developer has a copy of that same repository on their machine so that's why it's called a distributed version control system so now let's go ahead and get started with Git now I'm not going to go into too much detail about the installation here um if you go to the website which is g-s cm. com uh and then you go to the downloads tab here then you can find the download the download for any operating system that you're working with and the installation is pretty self-explanatory so after we get get installed there is a firsttime setup that we have to go through so first of all after you get get installed then you can check the version to make sure that it installed correctly so if you run this command here get-- version so I'm going to open up my terminal window here now if I run get-- version and it pops up with some version here here it says get version 2. 3.

2 then that means that git is successfully installed now once you have git successfully installed now we need to set up some Global configuration variables now these variables are important because if you're working with other developers then they need to know uh who is checking the code in and out and making changes and things like that so this is a way to add your name to all of your check-ins and code changes so this is the syntax here to add these um variables in here so if I go back to my terminal I can type get config D- Global user. name and then in quotes I can type in my name here so I'll type in Corey Schaefer hit enter and now we can do the same thing for email so I'll type in user. mail and then here I'll type in my email address at gmail.

com hit enter and now after we've put in those values then to check th those values we can do get config d-list and this will list all of our configuration values here now I'm going to have a little bit more than you do you'll probably only have a few values here but I've customize my g a little bit over time so you can see all the values that I have listed here but the important ones look for are to make sure that we have our user. name set and our user. email set so once you have those values working then you are good to move on now get config was the first get verb that we actually used it was the first action that we used now if you ever need help with any of these actions then you can use this syntax either get help in the verb or get verb d-el and what I mean by that is using config as an example so say I want to see what you can do with the config action so I can do get help config and hit enter and it'll take me to the manual page and you can read all about it here um or the other syntax that you can do is get config d-el and read through there and you can do this with any get action so you get add- dhel does the same thing it takes you to the manual page for the add action so that's extremely useful once you start doing uh more intermediate and advanced things with git uh it's useful to look at those manuals and see exactly what you can do with them now there are two common scenarios for people to begin using git so the first scenario is that you have an existing project on your local machine that you want to start tracking using git and the second scenario is whenever there's an existing project remotely that you want to start developing on so first let's take a look at that first example where you have a local code base that you want to start tracking using git so in order to do this it's just as easy as running the git and nit command from within the directory in your terminal so for example let me pull up my terminal here now the code that I want to start tracking if I do an LS within this directory the code that I want to start tracking is with within this local repo directory so if I CD to local repo and then I do an ls- LA in here which will will list all of the files in the directory you can see that there is a project file here and there's a calc.

py file here so to begin tracking this code with Git it's just as easy as running git and knit and if I hit enter you can see that an init initialized an empty git repository and now if I do n ls- La then you can see that it placed this dogit file here now this dogit it's actually a directory this dogit directory contains everything that's relateded to our repository so if we ever want to stop tracking our project uh with Git then all we have to do is remove this git directory just like we would any other directory and if I do an lsla it's gone and we're no longer tracking this project with Git but we don't want to do that we want to uh track this project so let's do this again now you can see it put that uh get directory back there and now we are using get within this directory so now we're using git in our directory but we haven't actually committed anything yet so before we commit anything let's first run this get status here so if I pull up my terminal and I run get status you can see here that we have two untracked files project and cal. py now this project file is just a file that I created as an example of a file that we don't want in our repository for other people to see so there's a lot of files that contain personal preferences specific to our machine or our operating system that aren't actually part of the code that we want tracked so for example say that I had my personal preferences within this project file I wouldn't want to uh add those to the repository and whenever other people check those out they would be getting my preferences and we don't want that so what we want to do is ignore these files and to ignore files uh you just have to create a do get ignore file so I'm going to do a touch on a do get ignore file which will recreate which will create that get ignore file and now let me go ahead and open this up in my text editor okay so the get ignore file is just a simple text file where we can add files that we want get to ignore and we can also use wild cards so for example here in um this slide I have this star. pyc uh which will ignore all files with a pyc extension so that's a python example but that's not important it's I'm just showing the concept here so let's go ahead and add all these files here to our get ignore file and I'll paste that in and save that and now let me go back to my terminal now that we've added those to the get ignore file and saved it now let's rerun get status and now you can see here that the project file is no longer coming up in our list of untracked files it's only theg ignore file and the cal.

py file and we want to commit the get ignore file because we want the repository uh to know to always ignore those files okay now let's take a step back here and try to picture exactly where we are right now now with Git there are three states that we need to know about there's the working directory the staging area and the committed files and right now we're currently in our working directory so untracked and modified files will be in our working directory and it will list those when we ran get status so you can see here if I open up my terminal then these are the files in our working directory here now the staging area is where we organize what we want to be committed to our repository now the reason for the staging area is so that we can pick and choose what we want committed so if we've done a lot of work spanning multiple files and we want to make multip multiple commits from those changes then you can stage individual files and commit those in small chunks at once so that's going to allow us to be more detailed with our commits so for example you don't want to make a commit that where you add a message that just say says like I made a lot of changes to the code you want commits that are very detailed as to what changes were made so now that we know about that staging area uh let's go ahead and add files to the staging area so if we want to add all the files that are currently untracked or that we've made changes to to uh to the staging area then we could run get add- capital a um or we could add these individually so for example here if I did a get add. get ignore then if I do a get status and that's going to show us okay so here we have cal. py which is currently untracked and then you can see that our get ignore file is in our staging area because we ran get add.

get ignore and like I said in the slide if we want to add everything to the staging area then we can just do get add- capital A and hit enter and now if I run get status then you can see that all of our files are now in the staging area so if we were to run get commit right now then it would commit these changes to our repository now if you ever want to remove files from the staging area then you can use the get reset command so if I did get reset calc py and then did a get status you can see that the G ignore file is still in our changes to be committed which is in the staging area and our calc. py file is in the untracked files if you want to remove everything from the staging area then you can run get reset without any other options and it will remove everything so if I type get status now then you can see that all these files are moved back to our working directory as untracked files okay but we actually want to make a commit now so let's go through this process again what we want to do is we want to run get add- a to add everything to the staging area and now if I run a get status you can see that all of these changes will be committed and in order to get these uh in order to commit these files we run get commit and then dasm which will put a message now the messages are important you want to be detailed as to the changes that you made uh to the code but this is our first uh commit here so we're just going to put something like initial commit so if I hit enter there you can see that it added the two files to the repository now if I run a get status you can see that it says that the working directory is clean that's because um we've committed those files and now we don't have any modified or untracked files those are being tracked now and we haven't modify them since we committed them now another useful command here is the log command so if we run get log then we can see the commit that we just made so this gives us the hash number of that commit now all those hashes will be unique and then you can see that the our author who made the commit and then the message for that commit also so now for this example we are successfully tracking our local project and we have made changes and uh committed those changes to the repository so now let's talk about the situation that we mentioned earlier uh where we want to track an existing remote project with Git now this is likely how uh most of you will be using git if you're going to be using it in the workplace so for example say that your company has a remote repository and you want to clone that remote repository and begin developing on it now the Syntax for this is get clone then the URL and then where you want to clone that repository so in the example that I'm going to use I'm going to use this remote repo here which is actually just a directory on my local machine now usually this is going to be a URL so for example if this was coming from uh GitHub or something like that then it may look something more like this so you do get clone and then the URL of the remote repository and then where you want to clone that repository so in this case the dot is just means in the current directory but like I said in this example I'm going to be using uh this directory here which is on my local machine but it's going to behave exactly like a remote repository would so let me open up my terminal and let me go back to this get Basics directory now if I run an LS here then I have this directory called clone repo I'm going to CD into that now if I do an ls- LA here then you can see that this is completely empty these are just relative paths here so now I want to clone a remote repository here so I want to do a get clone and then the URL of the repository and then this dot means that I want to clone all the files from that repository into this current directory so if I hit enter you can see that it cloned into the current directory now if I do an ls- LA then you can see now I have files here now I set up this sample remote repository to be very similar to the uh example that we just used in the local directory so now that we've cloned that remote repository now let's see how we can view information about that remote repository so in order to do that we can use a couple of commands one of these commands is get remote- V and another is get Branch d a so if I was to do get remote- V then you can see it lists the information to the repository here so um this is just the location on my local machine of where this repository is and also if I was to do get Branch d a then it will list all of the branches in our repository not only locally but remotely as well now we haven't gone over branches yet but we will do that here shortly now let's make a couple of changes to the code base and we can take a look at how to uh commit those files and how to push them to the remote repository so over here I'm going to go into this uh clone repo and open up this cal. py file and now I'm just going to make a simple change here I'm just going to change this multiply function to return what we want it to return so I'll do return x x y and I'll save that so now we've made a change to our code so now that we've made a change to our code how are we going to push these changes to the remote repository so first we need to commit these changes locally just like we did before so if I open up the terminal here then the first thing I can do is get diff and get diff is going to show me the changes that I have made to the code so you can see here that it has this minus sign with the pass that's what I removed and then the plus sign here return x * y That's What I added in so those are the changes that I made to the code now if I run get status we've seen this before then you can see that in our working directory we have this modified do uh cal.

py file and now if you remember we want to add those to the staging directory so that they can be committed so we'll do a get add- capital A to add all the changes now if I run get status again then we can see that those are ready to be committed and now we can do get commit DM and then for a message here we can just do uh you know multiply function okay so now we have committed these files locally and now we want to push these changes to the remote repository so that other people have access to those now whenever you're ready to commit those changes and push them to the remote repository there are two things that you want to do a get pull and a get push now people a lot of the times forget the get pull but you have to remember that we're now working on a project that could potentially have multiple developers and people have been uh pushing code to that remote repository while we've been working on our own featur so what the get pull does is it will pull any changes that have been made since the last time that we pulled from that repository and as you can see after we ran that pool it said that we were already up to date because there have been no changes to that remote repository since the last time that we pulled from it and now we're ready to push and we will do a get push and this origin here is just the name of our remote repository and then the master is the branch that we want to push to so so if we run that then we have successfully pushed those changes that we just made to the master branch of that remote repository so now that we've worked a little bit with local and remote repositories now let's go ahead and take a look at a common workflow that uh a lot of developers use when working with Git so I said before that we were going to take a deeper look into branching so so far we've been working directly on our Master branch but this isn't really how you should be using it from dayto day so let's say that for example now instead of that multiply function we want to work on our divide function so a common workflow that you're going to use to do this is to create a branch for your desired feature and then begin working off of that Branch so the Syntax for creating a branch is get branch and then the name of the branch which we'll just call calc divide so I'm just going to copy that now let's open up our terminal and now let's create that Branch so get Branch Cal divide and now if I run get Branch without the branch name then it's going to list all of my local branches you can see that I have Master here which has the asteris beside it that means that I that's the branch that I'm currently working on if I want to start working on the Cal divide Branch then I have to check that Branch out and that's using this syntax here get checkout and then the name of the branch so I'm going to do get checkout Cal divide now if I rerun that get Branch you can see that I am working on the calc divide Branch so now let's start working on the changes that we want to make on this Branch so the changes I want to make here I want to work on this divide function so I want to return x / Y and I'll save those changes and now that I've made those changes now let's just commit this just like we have been doing so if I do a get status you can see that our calc.