Git & Github: Collaboration For Web Developers | Flow Speeches | Skillshare

Git & Github: Collaboration For Web Developers

Flow Speeches, Freelancer

Git & Github: Collaboration For Web Developers

Flow Speeches, Freelancer

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
26 Lessons (1h 26m)
    • 1. Introduction

      1:57
    • 2. The Evolution of VCS

      4:14
    • 3. Three Stages of GIt

      3:51
    • 4. Summary

      1:19
    • 5. Installation

      1:54
    • 6. Configuration

      3:58
    • 7. Gitting Help

      4:32
    • 8. Initializing Repos

      3:05
    • 9. Github

      2:38
    • 10. Github Repos

      8:49
    • 11. Quick Summary

      1:13
    • 12. Git Status

      1:50
    • 13. Three Stages Revisited

      1:14
    • 14. Git Add and Commit

      4:24
    • 15. Modifications

      5:06
    • 16. Abbrieviations

      3:30
    • 17. Pushing

      1:55
    • 18. The Log

      4:12
    • 19. Good Commit Messages

      3:30
    • 20. Remove, Untrack, Rename

      3:11
    • 21. Branches

      4:32
    • 22. Implementing Branches

      2:24
    • 23. Stashing

      2:41
    • 24. Merging

      3:33
    • 25. Reset

      4:30
    • 26. Pull Requests

      2:07
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

84

Students

--

Projects

About This Class

Git is THE tool web developers and software engineers use to work on software together. By allowing you to collaborate with your team and make modifications, as well as, implement new features without having to worry about permanently changing things, Git has become the most popular tool for people both professionals and hobbyists building software.

Meet Your Teacher

Teacher Profile Image

Flow Speeches

Freelancer

Teacher

Hi, my name is Andrew. I started Flow Speeches to help people learn foreign language. Basically, when I started learning foreign languages I knew nothing. Now I know slightly more than nothing. My goal here is to share with you the things I wish someone had just told me from the start.

 

Becoming Fluent 3-Day Video Series

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Introduction: hi and welcome to the course Now. Chances are if you're watching this course you've at least heard of get. And luckily, that's what this course is all about. And you may have been working in college, and your professor requires you to use version control or get for your projects whenever you're building your software. Or maybe you're just getting started as Web developer, and you've heard all sorts of people rant and rave about getting how you have to learn it if you're gonna get into Web development. Well, regardless of your circumstances, we're gonna be talking about three main things in this course. First, what get actually is second. Why it's so popular. Why so many different teams in so many different Web developers use get when they work on projects. And third, and perhaps the most important, we're gonna talk about how to actually use this thing. So let's start with Number one. What get actually is now, as I kind of said before, get is a V. C s or version control system, and what that basically means is it allows you to, for example, have a file, and you can make changes to that file over time and you'll record all of the different changes that you've made. This offers us a number of benefits. So let's say we have a project where we're building a website and we have version one of our website. Then we want to start experimenting and adding some new features. So we create version two of our website and then we realized that we made a mistake and we want to go back well with version control. It's very easy to go back to the original website that we started with without having to worry about some of the things being missing. This offers a number of benefits because it allows us to make changes to our different versions, compare different versions of our website, see what was changed when it was changed and even find out why that change was made. So this offers us a number of different benefits now, over time, there's been several different types of VCs is so we'll talk about a couple of the different types of VCs is in the next video 2. The Evolution of VCS: by knowing about the previous versions of VCs that came before Get you also kind of understand why get became so popular by seeing some of the flaws with previous attempts at version control systems. So the first probably most popular version control system was a local VCs, and this is basically just a local database stored on your computer. Ah, personal computer. And whenever you make changes to a certain website, AH version of that website is created and stored in patches. All of your different changes are stored is these patches and it can only contain changes from the previous patch. So, in other words, if you check out like version one of a website and then you make version two and version three and then someone else checks out version three of your website and the import that to their computer, they won't have access to the previous patches that you've made so they won't be able to look back and see what was changed, and that's pretty important. So, in other words, in order to see all of the changes that were made to a website, you would have to add up all of those patches and that's pretty hard to do. On top of that. This is problematic for a number reasons. I mean, it was better than nothing. It was better than having absolutely nothing, but is very simplistic, very error prone, and it made it difficult for a number of reasons. First, it was very difficult for people to check out different parts of the project. And on top of that, it was difficult to know what one person was working on, what part of the project or what part of the software Ah particular person was working on. So a solution to this was a centralized version. Control. Ah, the idea behind this is pretty simple. Basically, you have one single server with all of the different versions of the project store on it now. This was a lot better than a local version control because it meant that people could check out different parts of the project different files. And it also allowed people to have authorization, right? So, in other words, making sure that one particular person wasn't working on a part of the project that they weren't supposed to be working on. But it's still not that great. So there couple of flaws with this one as well. First, the data is all centralized. So in other words, if the server goes down, everyone goes down and all everyone is left with was these local kind of copies that they checked out. On top of that, if there was corrupt data since the data was all in one place, you would have to basically just pray to God that someone downloaded the part of the data that was corrupted. And there were other types of tomfoolery that went on. I know people used to pass around thumb drives with different versions of the project on it in all kinds of stuff like that. So then came along a distributed version control system Q. The singing monks ho. Sorry. Anyway, Ah, this is basically where get came along. I won't get too deep into the history of this. Ah, but basically it's really special, because whenever you check out a project, that is, whenever you download a repository, you're not just downloading one of the latest versions of the project. You're actually completely copying the entire project onto your computer, and this is pretty beneficial for a number of reasons. because it means that every single person that downloads the project has a full backup of the project. So if the server ever went down, you could just take someone else's copy of the entire project and load it back up. Not only that, but it allows you to actually. Well, sorry, jumped ahead of slide. It actually allows you toe work a locally on your machine. So that means that if you're at an airport or if you're in the car, you can still work on your project locally. And on top of that, as if there weren't enough benefits, you don't have to add up all of the patches together to see what all was changed on the project. Because you have every single person has the entire project on their computer. And so you can basically just compare snapshots of your different project versions and see what always changed, make comparisons and even look at messages from other developers and see why they made that change and what the purpose of it was. 3. Three Stages of GIt: now this is the slide that I accidentally clicked ahead to. How get actually works. Obviously, we can't go into a huge amount of detail. It would take way too long. It's actually pretty complicated, but we can't understand the general idea. First, get uses snapshots, not differences, not patches. So in other words, the way the other VCs is would store data is they would make changes to the original file, and all of the comparisons were based on the original file get sort of stores and thinks quote unquote of data as these snapshots. So, in other words, whenever you save a version of a file or a version of your entire project, you're basically taking a snapshot. And then the way that gets stores it is. Once it takes a snapshot of your file, it stores a reference to that file. And if the file hasn't changed, a get is kind of smart enough to not create a new reference to a new snapshot. Instead, it will use the same reference to the old snapshot, since you didn't make any changes and the file is still the same, aside from that, get is pretty much all local Obviously it's not completely local, but get can completely function locally. As I said before, since everyone's pulling down the entire project repository and all of the past versions of the project, you don't have to keep checking things out from a centralized server, and that allows pretty much everything to seem instantaneous. So this means that, as I said before, if you're on a plane, a train, a car and more you can still work on get, you can still save different versions of the project because you have the entire thing on your system. And then whenever you're back where there's WiFi, you can then upload it to the repository on the Web. Aside from that, I would say that understanding how get manages the data is probably the most important thing to remember. I'm gonna teach you some of the most common get commands and how to work with different branches of a project. But if you remember this core concept right here, you'll be good to go because you can always look up how to do a specific get command long as you understand the foundation. So we're gonna talk about the three different parts or the three different phases that are file goes through. Okay, The first phase, I would say, is committed. That means that it is saved to a local database or it is saved up online. So this is actually stored. It's officially a part of a version of the project. Then let's say you download the repository right, you pull it and then you start working on some files. You start adding some code, deleting some old commented out code. Now it's going to the modified state. That means that you're making changes to a version of the project. Then, after you're happy with all of the changes you've made, you submit it to the staged part, the staged phase. So, in other words, this means OK, these are the changes I've made to this original version of the project. Now I'm ready to commit it. That is, save it as another version of git. Now get goes into basically three different parts right here you have your working directory, which is changes to the file since the last check out have not been staged for commit. So in other words, that's the directory that you're working on. That's the directory that you're making changes in the folder. The file that your go since you checked something out, that's the one that you're making changes to. Then the staging area is basically you're done. The state of the file is done. It's been modified. And so now you are ready to forget to take a snapshot of this new version in store reference to it. And lastly, the dot get directory. The repository is the files in this state, the files that are committed and recorded and our version snapshots that can be referenced for other developers. 4. Summary: I think it's always prudent to do a summary of what someone has learned. It really helps kind of synthesize the information that you took in. So we learned a couple of things. First, we learned that get is a decentralized version control system, and we actually know what that means now. We also talked about kind of the progression of version control systems and how we have evolved over time, talked about how get uses snapshots. It doesn't use patches. It basically takes a picture of your file system and stores, a reference to that picture for comparisons. We also learned that get his local meaning that you can actually work with your project without being in a WiFi hot spot at all. We also learn, get has integrity. The reason it has integrity involves talking about cryptography. But basically, if data is ever corrupted or if data has ever changed, it's almost impossible. Forget to not know about it. We also talked about the three stages that a file goes through from committed to modified to actually committed again or staged in the three different main parts of a get project. That is, whenever you're checking it out and whenever you're staging it, and whenever you're actually uploading it or pushing it to the repository. With that being said, we talked enough about it. We have enough of an idea of what get is, so let's go ahead and download it and start working with it. 5. Installation: All right, So now we're gonna go ahead and get the actual get installed so that we can get started now . For Lennox users, it's going for every person who has a different operating system. It's gonna be a little different, but it shouldn't be too painful. So for Debian, users of Linux yogis sudo apt dash, get install, get So you open up your command line and type in this command, and it should install get as a package. Then, for fedora users, you'll use pseudo yum Install gets. So this should work for Lennox users and then for Windows users. You can essentially just follow this link right here. You can literally just hype get dash SCM dot com slash download slash win, and that should automatically open up a papa that tries to download the installer for you. And it should also download something called Git Bash, which is sort of like a command line that you can use, and it gives you kind of a more of ah, I guess a Lennix feel for whenever you're typing in the git commands, I personally prefer to use git bash a lot of the times, except for certain operations you'll have to use Power Show. But for most of the course, I'll be using Git Bash, which is really nice. And then for Mac users, you have a couple of different options. Ah, you can follow a similar link you can do get dash SCM dot com slash download slash mac and that will once again automatically download the installer for you. Or, if you have home Bruce set up on your machine, you can use the command brew, install, get. And, of course, if you don't even know what I'm talking about here than just use this link that I provided . Go ahead and download the installer. Activate the installer, follow the set up instructions, and you should be good to go. There's really shouldn't be any special configurations that you have to do. 6. Configuration: now throughout the course, I'll be using a Windows machine. So the first thing I'll do is I'll open up and look at all of my different, um, programs that I have downloaded. And if I scroll down, scroll down to the G section, I should see something that says, Get if I'm not mistaken. Let's see, there is a folder that says Get open it up and you can see there's a couple of things we have the get gooey. I don't recommend using the gooey. For now, the buoys can be useful, especially if you're using more complex operations. But for now, I definitely don't recommend it. What I want is actually the git bash. And so I personally would actually pin this to my task bar. This is like my command line of choice most of the time, So I'm gonna click it now because I've actually already upended it. So let me click that real quick. It should take just a second to load up, and then once we do, we can make sure that we've actually successfully installed the version control on our computer by typing in one command, and all it's gonna be is get dash dash version. And by the way, for those of you who are not super familiar with the command line, don't worry about it. I'm going to go over some of the most basic commands, so that way you're not lost. But for now, if we typing, get everything after that is going to be all of the commands that we type are going to be associated with get. So if we do get Dash dash version, you can see it prints so 2.11 which means that we haven't successfully installed it on our computer. Now the next thing for us to do is we need to actually configure a couple of things a couple of pieces of information inside of get, namely our user name and our email. The reason that we want to do this is because well, whenever we make changes to our files, we need to be able to associate those changes with a particular person. So what I'll do is I'll typing git config, Dash, Dash Global, which I'll explain in a second user dot name, and then I can type in my name here. So in this case, I'll do Andrew Holloway. Okay, so now that I have that set up, I can go ahead and hit. Enter, and then I need to configure the email. So in this case, I'll do config Dash, dash global and for the email. I'm gonna make something up. Um, I'm going to do something like men on the moon at Yahoo. This is not a really email, by the way, don't bother this person. Whoever has this email, I'm sure there's someone out there who does. So with that being done, if we want to check out a list of all of our different configurations that weaken, do get config dash dash list. Now that we have that you can see all of the different things that I've typed in here and it has a couple other pieces of info. And if you want more specific pieces of information instead of prince account a list of all of your configurations, you can just do get config and then you could do something. Like for example, user dot name, and it will just print out my user name in this case and so on and so forth. Um, now a quick explanation of the global flag. Basically, what this does is it makes sure that I only have to set this configuration one time. So if I'm changing files in one part of my computer or another part of my computer, it doesn't matter. Ah, this is a global meaning that it's always going to be Andrew Holloway in the emails, always going to be a man on the moon. Now, if I want to override this in a particular project, I want to change the information. Maybe I'm working on a work project and I want to change it to my work email than a great way to do that is just to type in the same exact command. So I would do get config user name, for example, and just get rid of the global flag. And so that will change the configuration locally while leaving all of the global configuration the same throughout the rest of the computer 7. Gitting Help: So as you can see, I've pulled up some documentation because one thing that's more important than having all the answers is being able to find all the answers. So this is actually all of the documentation of forget. And more importantly, you can actually just use your command line and access all of this documentation the entire get manual locally. Now there's a couple of ways to access it. The first way is to use git help and then get again. And that's basically going to get you help for the entire get tools. So this is pretty useful. And another cool thing I've set it up to where it opens it up in another file or another window on my machine, which is pretty nice. So now it's actually reading it from my, ah, my browser, but it's all completely local. As you can see, it's all inside of my program files right here. And this is a list of all of the different things that get offers. And if it doesn't display or open up in your browser, it'll actually be displaying inside of your command line. So just something to keep in mind now, aside from that you can see there's a lot of different things right here, right? Well, not to worry. You don't need to worry about a lot of these. Most the ones will be focusing on are what are called high level commands or what get calls . The porcelain commands thes air, the high level commands that you'll be using day in and day out when you work with git. And then if we scroll down, you can see there is a bunch of other commands bunch of other commands. And you also have what are called low level commands or what they call the plumbing. Uh, these allow you to work with interact and, more importantly, change the inner workings of get, and we mostly won't be working with these. These are pretty complex commands, and honestly, most of the time you won't even use the command line to use these most the time. You'll be using tools and things like that to actually execute these complex commands, and I really don't recommend using these commands unless you know exactly what they do now . Aside from that, we can also type in just get help and what that's going to do is just print out some of the most common commands by default, and you can see it shows how toe start a working area to clone something to make branches and check things out and so on and so forth. And you can see it even gives you some references here, like started working area, get help, tutorial, get help everyday commands and so on and so forth. So if I type that in get help every day, it'll actually loaded up in my browser. It'll load up one of my local files that I have for the everyday commands. And if you also want more specific information Oh, I guess that didn't work. Let's see what went wrong. Get help every day. I'm gonna miss type that. I don't think I did, though, huh? That's supposed to work. I forgot the every in every day. Okay, I was wondering. I was like, I know that works. But, anyhoo, sometimes we missed type things and we forget a letter, at least the courses realistic. Right? So this should open up in my browser now, and I can read it from my browser, and I set it up to open in my browser cause I just think it's easier to read it this way and it shows you all of the everyday commands. Another cool thing about it is it will give you examples and just show you how you can actually do it and talk you through every step of it with bullet points and what not? And if you want help on a specific command, you can use get help and then whatever specific thing you want to know more about, for example, configuration and another thing you could also do is you can even get help on the help command. So pretty much you can just type get help and then whatever you want to know about. So if I wanted to know more about the help command, then it'll actually load up a reference to get dash help, and it will show me all of the different things I can do. They're like, So give me a description, all of the different flags that I can pass and so on and so forth. Um, by the way, to open the get manual the way that I did it was I use get help, get but another way to do it is to actually say man, get ah depends on your machine. This command doesn't work on my computer, but it doesn't work on some people's computers. So if you're having trouble with the command, get help, get and then I do recommend that you check out, man, get so that way you can load in the entire manual and look at it and reference it. 8. Initializing Repos: So now we are actually going to turn our folder or project into a git repository. Now, in order to do this, the first thing we need to do is CD into our project, which I have attached as a resource inside of this section. So I wanted to actually work with the rial project. So that way you can kind of see how it would typically go kind of get you used to how things really would be. I tried to make the project as universal is possible. It's mostly just html CSS, a little bit of JavaScript and a lot of react, and you can ignore the gulp. It's just for basic just Dev environment stuff. So in order to get to your Projects folder, it depends on where you are. I put my project folder on my desktop for easy access. Um, so what I'll do is I'll clear everything away. Very useful command clear right there. And if you don't know where you are in your command line, you just hit LS. And it gives you a list of folders or directories, as they're called, that you can reach directly so I can reach my desktop from right here. That's pretty nice. So in order to reach the or change into my desktop, I'll just you CD desk and then hit tab. Another cool thing. If you just hit tab, it will finish the command for you or the file path. So now I'm inside of my desktop. And if you're on a Windows and you insist on using something like Power Show, um, you can use Dura and that will give you a list of all of the different files. As you can see now, I have access to Miss. So that's just the name of the theme that I made comes from another course that I did. So I'll just CD into Mrs now. And so now we're directly inside of our theme. Now, in order to turn this into a get project, we need to initialize a repository or often it's abbreviated to a repo. This is basically just digital storage right here, okay? And it's going to be what allows us to use version control within our project. So what we'll do is now that we're inside of our project, Holder will just use git in it right there, and that's going to initialize a git repository for us, and we can see that this happened by changing into c d dot get forward slash and now we're inside of the git directory. And if I hit list, you can actually see that it has all of these different files right here. Now the interesting thing is, by default, this is hidden and you can back out of a file by doing dot, dot, slash with CD. So if I hit list you can see I actually don't see the dot get filed by default. It's hidden, and there's a good reason for that. And it's out of scope of this course to really talk about everything that's inside of the dot Get subdirectory. Ah, but for simplicity's sake, just know that it's basically all of the important metadata that get needs to be able to use version control with our project. Keep track of all the different versions. As you get deeper and deeper into get, you'll begin to figure out and learn about what each of these different folders do and what role they play in the larger scheme of version control 9. Github: So let's talk about get hub now in order to get to get help. Obviously, you're gonna type in, get hub dot com But it is actually an integral part of get. And for those not super familiar with this aspect of Web development, they may get those two confused Get Hub has a number of benefits, and it integrates seamlessly with git. However it is not get Basically what it is is a place where we can upload our repositories , sort of like almost like a cloud hosting service. So that way we can have access to our projects from multiple devices. So let's say I'm working on a project at my work computer, and then I decide I want to go home and pound out the code there, so I need to be able to access it from maybe my personal computer, my laptop and so on and get allows us to do that. So that way I could log into my get hub profile, access the repository, pull it down to my local machine, start working on it, and then I can start making changes to it, create different versions and leave messages about the changes that I made and then upload all of the different changes that I made, and so on and so forth. Ah, the way you make an account is really, really simple. What you're gonna do is, if you don't have an account, you won't be logged in like me, like right here. That's my that's my face right there. And so what you'll do is you'll hit. Sign up. Ah, it'll ask you for a user name. It'll asked for a password in an email. You've done this before, right? And then after you intern in all of those things, it'll actually ask you what plan you want. I would pick the free plan for now. At least you know. Just picked a free plan. No problem. It'll ask if you want to receive some promotional deals that's completely up to you. But once you've done that, the last thing will be for you to verify your email. And once again, that will be completely up to you. So you'll have to open up your inbox and they'll send you a verification email. I mean, you've done this process like a 1,000,000 times. I mean, it is 2018 so once you've done all of that. The next thing that will need to do is actually make a repository, because the project that we created or that we have on our local machine, we've initialized a repository. But now we need to be able to link it up. So that way we can use get with get, um, we'll have our projects stored on the cloud on someone else's computer. So that way, if we accidentally delete our project or something like that, we always have a backup somewhere. OK, so make sure to get logged in, get everything set up. If you have any difficulties, please do let me know and I'll see you in the next video. 10. Github Repos: Congratulations. You have your account on Get hub. You're one step closer toe being on involved member of the Web developer community. Now, the next thing for us to do is to create a new repository. And before we jump into that, I just want to say there are so many features of get Hub. I mean, really, there are quite a few different features, and it's really amazing. I totally see why Get Hub is so popular. Ah, but we won't get to see a lot of those features that are so interesting because they're mostly collaboration features. Ah, you'll see things if you go to. For example, I think V s code is on get hub visual studio code. It's like a ah, basically like a text editor slash i d e. It's it's kind of a funny thing, but if I go ahead and go over actually, I think you can go to maybe an extension or something. You'll see that people are collaborating and there's all of these different commits, which is where people ah, push code to this repository and all of these different branches which were different versions of the code, and it has all of these different contributors with people talking about issues that they found or bugs they found with the code. And it even includes these cool tutorials right here. So there's a lot of cool stuff that you can do with Get Hub. We're gonna be talking about the most essential things that you'll need to use as a developer, especially as you start collaborating with other people and getting into, let's say, for example, a job. Now what we'll do is we'll make a brand new repository, and there's a couple of steps to follow here. First and foremost, we need to give it a name. So in this case, I'll give it a name of Let's see practice will just do mock bootstrap dash theme. Unfortunately, you can't do spaces. I wish you could, but you can't, um and then we can add an optional optional description. Ah, I would definitely say you could do something. Like, for example, this is just to test out a bootstrap theme that I made and kept. And then you have a couple of other options. Ah, you can either make it public or private. In this case. I don't care if someone takes the theme, so I'll just make it public. And then it says you can add a read me file right here. So basically, this is what allows you to tell people more about your project. For example, if you were using, like, a framework or you built a framework, this would be your opportunity to kind of tell people more about the basics of your framework. Ah, what it does, what some of the main functionalities are and how to implement them. So we're actually going to make this within our get bash or are command line. So we don't need to worry about that for now, So I'll believe this unchecked. The next thing it says is at a dog. Get ignore. We'll talk about this a little later, but essentially, it's as its name implies. Ah, certain files that I won't get to ignore or files that I do not want to push to my repository online. Okay, so a good example of this is like node modules, right? Ah, node packages. I don't want to download the note packages. I just want to download packages dot Jason and then they can download whatever packages they want Ah, licensing, uh, also kind of out of scope here, but there's several different licenses that you could add, like M i. T. For example, if you want to find out more, there's definitely this information icon right here that you can click for now. We'll just leave it, No license, and we'll go ahead and make a brand new repository, and as soon as this loads up, it'll give me a couple of options here. Now Oak Top. It says that you can have either an https link or an ssh link. I'm not gonna go into huge detail about the differences between things. I'll leave the link so that way you can check it out. Sometimes it's confusing, and people don't know if they should make this one or if they should use this type of link and ssh link. Ah, with https, it is the preferred one or the recommended one, and you can use it even if you're behind a firewall or if you're using a proxy. So it's really good. And, um, basically, we're going to be using this link toe link up the repository that we've made on Get Hub and we're going to link it or connect it to our local repository that we made using. Get in it. Okay, whenever you use an ssh key, instead of asking for your user name and email, you'll have to generate a sort of hexi decimal pass phrase essentially. But I'll leave a link so you can decide which one you want to use. In this case, we will be using this https right here. So we'll just click the clipboard and it should be copied like So Now the next thing I want to do is go ahead and copy this right here. This is how you make a read me file right here. So I'll go ahead and shrink this a little bit like so and we'll just copy what it says right here, and I'll explain what it does as well. So the echo hashtag mark boot strap, dash theme quotation greater than greater than read me dot M. D s. So what this dude does is basically this eco hash command right here says I want to make ah file. I wanted to say h one and it's going to be put inside of the read me m d. So Now we can add this to our project right here. And so now we've officially made a change to our project. So get is actually tracking those changes. However, we haven't put them in this staging area. If you remember from the previous model, so we haven't told get Hey, I'm done modifying this project. So in order to let get know that we've made all of the changes that we need to make, we do what's called get add and then dot right there. This is going toe out all of the different files that we've changed to the staging area, like so. And then after we do that, we can go ahead and do a get commit, and this is basically going to commit the changes so it will be saved officially as a version of our project. And if this is kind of unclear what I'm doing, go ahead and go back to the video where it says three phases of get or three sections of get and it'll clear things up for you. So now we're gonna commit it, and we'll use dash in to leave a message. Always leave a message explaining the changes that you made, and in this case, we'll just call it first commit. Okay, so we're literally just following the tutorial right here. Gives us some interesting information. Ah, but it's letting us know all of the different files that were changed, All the different files that were things that were inserted. So now we're set. The next thing to do is we essentially need to point this local repository, this local storage that we have to our storage on the cloud with get hub. So the way we do that is we do get remote, add origin and take that https link that you copied. And then we'll paste it right here. Hit. Enter. Okay, so now they're linked together. And the next thing to do is get push Dash, you origin Master. So now the previous line of code essentially or the previous command pointed my local directory at my directory or my Excuse me, My repository on get hub. So now what I'm doing is I'm pushing, which means that Okay, I modified the files. I added them to the staging area. I committed them, meaning I saved it as a version. Now I want to push it onto the cloud. Okay? And that's exactly what this command does. It will take a second, and it should ask me for my user name and my password. And I honestly hope that I remember them. Otherwise, this will be embarrassing. But as soon as it does that, it's always a little slow when I need to add to push to the, um, to push to the cloud. Essentially. But I'll go ahead and skip this part there ago. So now we have that set up. I'll remember my user name, hopefully, fingers crossed. Okay. And then my password. Okay, Nobody look. Nobody look. All right? Hopefully that was the password. If not, don't worry. Okay? Yes, that was the password. I totally nailed this. Okay, so now that I have that set up, it's going to be pushing to my repository. And in the next video, we'll check out what we added and see what else we can do. 11. Quick Summary: So we have officially created our repository. You can see everything that we added, including RMD file right here. All of our different packages gulp, etcetera. With that being said, we have learned a lot in a short period of time just to summarize, we learned how to actually install, get how to get help by doing things like get help every day for the everyday commands or get help, get toe, load up the manual and so on and so forth. So you always have access to the entire documentation of get even on your local machine. After that, we learned how to initialize a local repository, turning our project or giving get control of our project. Then after that, we learned how to make an account on get hub, create a repository on get hub and then connect our local repository to our repository on get hub. And then we can make changes to our files, commit them or stage them essentially and then commit them. And then we can push all of our changes along with all of our messages about the changes we made to our repository on get hub. And so it's pretty nice now in the next module, we're going to get into the most important features of get whenever we're working inside of a project. 12. Git Status: So now let's get into the most important or at least the most common commands you'll be using. These are the high level, the porcelain commands. So first thing we'll do is we'll clear our command line. So we have a lot of space to work with. And then after we clear, the next thing we'll do is we'll. We're still inside of our project folder, by the way. And so we'll hit, get and then status. Okay, this is really cool because it means we don't have to guess what state were in a Sfar. A Czar project is concerned, so let's talk about what the status is. It says on Branch Master and your branches up to date with origin slash Master. So what this means is branch is a fundamental concept of the gift. What you can do is essentially, let's say you're working on a project and you want to make some changes to it. Maybe you want to add some search functionality to it with elastic search engine or what have you. So what you would do is maybe branch off from the original project or fork, in other words. And don't worry, we're gonna talk about branches in more detail, but right now we're essentially on the main branch that is the core branch, which is actually called the Branch Master or the Master Branch. So it's saying that our branch, the one that we're working on right now, is up to date with the origin or master, meaning that the project that we have on our local machine is actually identical to the project that we have on our get hub repository. So and it also says there's nothing to commit, meaning that there is nothing that we've modified. So there's no nothing we need to change, nothing we need to save, and the working tree is clean, so that being said get status is super, super useful. Um, and as you get deeper and deeper and you start adding things, staging things and committing things, you will see how it becomes more and more useful 13. Three Stages Revisited: So we've already talked about this, but since we're about to use the commands, I figured we go over it one more time. The three different stages of your project. Now the first stage is committed. Now, that, of course, doesn't mean it has a lot of dedication. It means that the snapshot or the file that you have right now was included in the previous snapshot. So the way that your code is written right now was included in the previous snapshot that get took of your project. And then you have staged meaning that basically the changes that you've made are going to be included in the next snapshot that get makes and then modified means, um, the code that you wrote is different than the previous snapshot the previous commit that you made. And we saw how we do this already we do get add to stage something, and you can specify a particular file, and then you can do, get commit to actually save it and include the changes or the modifications that you've made inside of your next snapshot. With that being said, try and spot the different stages that your project will be in as we go through the course . And, of course, you can always get an update on what the status is by using get status. 14. Git Add and Commit: so I don't know if you looked at the file structure of our bootstrap thing, but if we do an LS, we can actually look inside of it and see all of the different files that we have here. So inside of the source file, we actually have more files. So what I can do is list source, I believe, and that will actually show me what's inside of the source file. And as you can see, I have an index dot html and that's the only HTML file I have because I made essentially a landing page. So what I might want to do is make a brand new file. So the way we do that is pretty simple. We do touch and then the name of the file. Now, by default, it would make it inside of the Miss folder, and I actually want to make it inside of this sort source folder right here. So what we'll do is touch SRC, and this is why I recommend that you use git bash. It's a lot more of a Lennox feel, and it allows even people who are using Windows machines to follow along the same way that a Mac user would or a Lennox user might. So inside of there all do source. And now the name of the file. Let's say we want a products page Saudi products that html hit enter, and that should make a file for me. Now, whenever this happens, the status of my get product changes so we can type and get status like so and you can see it says I'm still on the branch Master and my branches up to date. However, there's an untracked file now, as we said before, get will track our files and whenever we add a new file to our repository, get is not tracking it, meaning that whenever it takes snapshots for different versions of our project, these files are not being included in said snapshots. So there's nothing added to commit, but untracked files are present. So in other words, we haven't made changes to the files that we already have, but we have a file that's not being tracked. The way that we track the file or tell get to track. The file is with the get add command, as before, so you get ad and then the name of the file is products dot html. Let me see. I might have to add source products dot html like So now once I do that and I type get status again, you can see the status changes your branches up, the rate changes to be committed. So right now we have a change that needs to be committed to our actual project. This isn't a big change. Typically, I wouldn't make you commit if I just made a new file. But, I mean, in this case, you could so we would do something, like, get commit and then dash m always include a message. So in this case, the message will be, let's say, um make product page for website. Okay, Now that has been committed to our project. So get has made a snapshot of this version of our project. So now if we do get status, you can see it says on branch master your branches ahead of origin master by one commit. So this means that you've actually added something to your project. Your local project that is not on the original project that we linked to on get hub. So use get pushed. The publish your local commits. So that would be us shoving our version of the project on to get hub. And there's nothing else for us to commit. Everything else is fine. So let's go through this one more time. Essentially, we had everything up to date. Our project was in sync or the same as our get hub repository. Then we made this new file with touch, and after we made that new file with touch, essentially, we check the status and get hope tells us Hey, you made this new file. We were tracking all of these files, but then you added this new file and get hub by default. Will not track a file unless you explicitly tell it too. And so we tell Get hub to track the file by saying get ad, okay. And then we tell him the file that we want to track. We check the status again, and now it's telling us, Okay, this thing is being staged to be committed, meaning that we've had all of our changes made. And now this change will be included in our next snapshot in our next commit. Still, we commit the change, so get huh? Argh! Excuse me takes a snapshot. That's the version of our project and saves it. And then it lets us know that we are one commit ahead of our original project on Get up. 15. Modifications: So for this next section, you'll need a text editor or I D. E. I personally recommend visual studio code. You can use whatever you want, though it could be anything from brackets to something like Web Storm. So whatever floats your boat? Really? Ah, but then you'll click on the Project folder and then open your text editor. You can do open code. There's also a command on get huh? Or on the command line that you could use. You could use open Dash A, the name of your text editor and then whatever folder you want to open. In this case, I'm just going to right click on the project file and hit open with code for visual studio code, so that would be it right there. Then once you have your text editor or I d open, I want to make some changes to my files because we've we've seen what happens whenever we add a new file and it's untracked and how we actually add that to our staging area and then committed. But what happens whenever we actually change something that was already being tracked, for example will keep it simple. We'll just go to my index dot html right here. And maybe I want to change something simple, like the title, because right now, for example, the title is bootstrap for starter pack, right? And like, I don't want that there, I Maybe you wanted to say, for example, um, miss from bootstrap theme. Okay. And then it auto saves it. Um, and one of the reasons I actually love Ah, visual studio code is it comes with a built ing Ah, gooey for the actual git that we're using. So and it even shows an M for modified right there. And it marks it and shows what changes I've made. And I can click on it, and it's it's really, really cool. And it will show you what it used to be in what it is now. So it's really, really cool. Honestly, um, but like I said, we're gonna mostly try to stick to html if we can, just to keep things pretty universal. So now that I've made that change, if I go to get status, okay, you'll see that things were different. Now it says, and I'll even widen it. And so it says All in Branch Master, as usual, your branch is ahead by one. Commit nice. Ah, use Get push to publish your local commits changes not staged for a commit. All right, So this is how it handles when we make a change to attract file. So it says I've modified my index dot html right here, and it even tells me exactly how to do it. Use get ads. So that's exactly what Will dio and then the file name. So get ad and then it's ah source index dot html trying to tab. If you tab, it will finish it for you so you don't have to type the whole thing and then we'll add that . So now if I hit get status, it should show changes to be committed. So it's in the staging area and you can think of get add as basically include this file in the next snapshot. So in the next version. So now that I've done that, maybe I decide I want to change it again to miss Ah, bootstrap And it's not really a theme. It's just a landing page. So I change it to landing page like so and then I go back to get and if I hit. Get status. You'll see something pretty interesting. Ah, it's both. So in other words, we have our index dot html that's in the staging area, and then we have our index dot html. That's modified, but it's not staged for commit. So how can it be both at the same time? Well, it's pretty simple. Um, whenever I said Get ad, I said, include this version of HTML in the next snap trap this version of index dot html. But then I made changes and I never told get to include this new change in the actual next snapshot. So in order to include the change that I just made and the change that I made before, I would just use get at again So we can just copy that command that we made like so and now if I do get status, you'll see that we just have changes to be committed. So they're in the staging area, and now, in order to make that commit, it's pretty simple. What we do we just get commit, include our message to let people know if what changes we made and why. So in this case, change title to bootstrap Or actually, you don't even need to include the change that you made change title elements like so or will change to change title content of index. You like so And then after we committed it will take just a second to commit it. And after it does one file change one insertion, one deletion. And that refers to the actual text that we deleted. And then we can do get status one last time and it will say we're too commits ahead. But there's nothing else to be committed. Nothing is in the staging area, so we have a clean tree. 16. Abbrieviations: So let's make a few more changes to our actual theme or landing page, if you will. Right here. So, um, if we go down, for example, to where it says boxes, it says be better. So in this case, I would say it. Does it say be stronger? I want to add Be stronger. Yeah. Okay. Be better. Be smarter. Yeah. Okay. Never mind. So I don't want to change this. So maybe we'll just, um, actually go back up to our title right here. We can just keep messing with it, so we'll just add landing pages like so And then if you go back, it says get status. But instead of doing get status, I want to do a short cut. So we'll do get status. Dot s, which is basically short right there. So that's just a short term for short. And if I print this out, you can see it puts an M right next to it in just means that I've modified it. Okay, so now if I add the source dot index right there, index dot html and then do get status. Dot s again. It will say a for added. I believe which is another word for stage like So I meant to say yes, get status. Let me type that. Yes, I did mean to say Get status as you can see get is very helpful. So now it's so is modified with a green, which means that I have modified it. But it's also in the staging area, so it will be included in the next snapshot. And then, if I change it to, let's say, bootstraps, Miss Bootstrap landing page. So we'll change this back again. So we'll do something like boot Miss Landing page with bootstraps. It will do with bootstrap. Yeah, I cannot type today. There we go. So now that I've done that, if I do get status one more time and we can just do the up arrow toe, get the previous command, you can see it. So's both. So the reason it's showing both may seem kind of confusing to you. Um, if it's in the first part right here, it's just staged, and if it's just in this part right here in the second box, you can think of it as three boxes. It's modified, so that's how get will display the short abbreviation status staged is the first box or the first part modified is the second and third would be the actual file name. Now, once we actually commit this again So we'll do you get commit and do, um, for example test commit just to demonstrate it like so And then we do our get status again . You'll see that we still have one thing that is modified right there. And you noticed this little space right here. So that little spaces where the green M would go and that's for when something is actually staged. So we can add it now, like so source index, like so add to get status again. Now it's in the green spot right here. So we can just get commit this time, like so get commit all of our changes. And now if we do our get status, you can see there is no short status right here. But if we do our long status, it will show everything that it showed before. So get status dash s or get status. Dash short is a great way to kind of get the gist of what you have changed in what you've staged inside of your project. 17. Pushing: So we've made a bunch of commits to our local project, and essentially we've made commit snapshots of everything that we've done. And on top of that, we've also included messages. So that way we know what changes we made and why we made them and get also made a bunch of helpful data associated with those snapshots about what was deleted, what was inserted, who did the deletions and insertions of data and so on and so forth. With that being said, if we actually click on, get status or type in, get status, you can see it says are branches ahead of the origin slash master, which is our hosted project on Get Hub by four commits. And then it even gives us a little help right here and lets us know what a common step after this to do is. And that is to go ahead and push it to the hosted project. So that is, take our changes and add them to the hosted project instead of keeping them local. So the way we do that, as it says, is get push in the name of our local project, which is origin and in the name of our hosted project on Get Hope, which is master. So as soon as I enter, this will obviously take a second, and it's going to generate a bunch of data. Ah, but the general point is that this will update my project on get hub with all of the different commits that I've made. And so the number of commits should jump up to about five animal include messages for each commit that will go ahead and look at and digest in the next video. But remember, type in your user name in this case, all type in my user name right here and then you should be prompted to type in your password. Once you do that, it will take a minute to push. Let me go ahead and type that in like so pretty sure I typed in wrong. I might not have, though. Okay, And once this is done, it will start pushing. As you can see, it's doing that right here and boom, we're done. Now, in the next video, I'm gonna show you how we can look at the different commits we've made on get Hub 18. The Log: So far, we've only made four commits. So honestly, it's pretty easy to keep track of all of the different changes that we've made to our project. But as you begin working on any project of riel size or substance, you'll find that it's almost impossible to remember all of the different commits that were made. And so, over time, you're gonna want to look at what different versions of the project looked like and what was going on and what was added and who added it and so on and so forth. So a great way to do this is with the get command log, okay? And this is gonna print out all of the different commits you you've actually made. Ah, so we have first are shawl one hash associated with this commit snapshot, the author and their email address, as well as the day in time that the commit was made. Now you can also shrink this a little bit, but you can also see the messages that we wrote for each one. Change title content, make product page first, commit so on and so forth. You can also make this a lot shorter. So if you only want to print out a certain number of logs. You can just do get log minus or dash, Really, in this case and the number of commits that you want to see. So if I only want to see to, it'll only print out these two right here. And you could do 57 700. So on. Another thing you can do is you could print out sort of a mini version of it. So you would do get logged dash, dash one line, and that will just print out these sort of one liners. These really abbreviated versions of the commits with an abbreviation of the Shaw one hash as well as the message associated with it. So this gives you kind of, Ah, a really quick overview of all the different commits that were weighed that were made and going in the reverse direction. If you actually wanted more detail, a way that you could do that as you could do, get log, dash, dash, stat. And those will give you Ah, much, much more detailed. Look at all of the things that happens. So if we go up to this last commit right here, you can see it shows the number of things that were changed. And it shows that there was one insertion and one deletion, which is really useful. Same thing with all these other ones right here. And so if we keep going and hitting enter, you can see it will give you a lot more detail about all of the different changes that were made, all of the different things that were added. And most of these air coming from our initial commit when we initialized art project and whenever you're done, you can hit Q or you can hit control C to exit out of that. And that's one way to get a detailed view is get logged. Dash, dash step. Another way to get uneven mawr detailed you is to do dash patch. Now, this is actually gonna show you what was chained so it's pretty cool. Ah, we can scroll. Where is it? We're typing in Get long patch right here. So it tells us everything the author, the date, the time and it also shows the def. So this will give you a similar similar results when we did get def dash dash staged. So that will be pretty useful and you can see exactly what was changed here. I changed the title. I changed the title here as well. If we keep hitting enter, it'll just show you all of the millions of times I changed the title. And now it's just showing you every single file from the initial commit so we can get out of this with a que or a control. See. And those are the basic main ways to get an idea of what the different commits were. Obviously, there's a bunch of different ways we could search for commits. We could do it by date, by the author and so on and so forth. I just wanted to show you some of the most common ways that you will actually be looking for specific commits. And if we also go to our get hub where our repository is located, you can actually see the number of commits has gone up because we pushed to the to the master to the hosted project on Get Hub. And if we click on commits, you can see we get a really nice view of all of the different commits that we've made in a nice, gooey, and we can even click on the project and check out the repository and see what the repository looked like at this given point in time, which is honestly, really cool. So that's about it for that. If you have any questions about commits or about going through the history, make sure to leave a question below and I'll see you in the next video. 19. Good Commit Messages: now you may have noticed whenever we did something like get logged that thes messages right here aren't super helpful in general. Whenever you right commit messages, you want them to be informative because a lot of times you're using git and get help for collaboration. And whenever people look at different versions of your project, they're gonna want to know what was going on. So there's actually a really great article that tells you everything you need to know about great commit messages. If you go to Chris. Ah, let's see. Chris dot beam dot io slash posts slash What was it? Get dash Commit like so. And if you want to pause it right now and type this and you're more than welcome to. But I'll go ahead and hit enter and he basically talks about seven sort of rules or guidelines for a great commit message. Now, depending on where you work, they might actually have their own guidelines for having a commit message. And for some reason, let's see it's not even finding the website. But if you're working in a particular place, they may already have something like this set up, but either way, this is a really good guideline in general for personal projects or if your company doesn't have any sort of guidelines for their commit messages. So as you can see here, it starts off by saying why they're important. And it's obviously because if there is a bunch of different versions of a project, you need context to know why a certain change was made. But he goes on to talk about the seven rules, the first of which is to separate the subject from the body with a blank right here he goes and shows you how you might do that. And he explains the difficulty of actually using that with the Dash M flag to get it to make a commit. And actually, he talks about how, a lot of times it might not even be necessary Toe have a commit message with a body and a subject. Sometimes it's just a one liner, like the commit messages that we've been making, for example, fixing typos or something small. But if it's something that requires more context, you may need a subject line and make sure to keep your subject line less than 50 characters . Ah, just kind of a rule of thumb there. Capitalize your subject line. Don't put a period at the end of it and make sure to use the imperative mood, which is essentially like, for example, closed the door as he says here and go to the bottom of the page and write this. Did it added up. So that's the imperative. It's kind of forgiving commands and then wrapping the body at 72 characters, Um, get never wraps your text automatically just kind of a recommendation once again, and this is probably an important one right here. Use the body to explain what and why versus the how. A lot of times the comments that you leave inside of your code are meant to give more information that can't being gleaned from just looking at the code. But the commit message can be used to explain what you did kind of end also why you did it . So the subject, part of a big commit message, is really meant to give extra context, and then you keep your ah subject line at 50 characters or less capitalize it and no period at the end. So that way they know that it's supposed to continue on really great article. Highly recommend that you visited chris dot beams dot io slash posts slash get dash commit . I'll leave a link below, so that way you can just click on it. But really good article gives you everything you need to know about making a great commit message. 20. Remove, Untrack, Rename: Now there's a couple more things that are very important that you know how to do, the first of which is, if you remember way back at the beginning we had a source file and inside of that force source while I use the touch keyword to actually create a file so that we could show what happens whenever we add a new file, basically get doesn't track the file, and we showed how we could tell get to start tracking the file. It was actually the products page. So let's go in C D into a deeper part of our project and do an LS to see what's all inside of there. As you can see, we have products dot html right there. So with that being said, the next thing we might want to do is clear this so I can have a little more room listed out again. And maybe I want to tell. Get to basically just get rid of the file so we'll do get RM for remove and the name of the product in this case, products dot html. And then if I go ahead and do that, you can see it responded with RM the name of my file and quotes. And so that means that it worked. Now, if I do get status, you can see that it says modified, which is the index dot html and then deleted, which is products thought HTM Oh, so that is in the staging area. It has not been committed, so it's not in the next snapshot yet, but it is ready for the next to be included in the next snapshot. Now, that being said, we may want to just make sure that get just stops tracking a particular file instead of actually for example, deleting the file. So the way we do that is pretty similar. It will just use the index dot html, for example, so we could do get RM, dash, dash cashed and in the name of the file. So in this case will do index dot html and this will basically tell Get to stop tracking the file. So if we do get status one more time, you can see that now changes to be committed are for index dot html to be deleted, and for products that html to be essentially deleted as well, and then in the Untracked Files section. We have index dot html so in in the eyes of Get, it's being deleted because it's gonna be omitted from snapshots from now on. But it will say that it's being deleted. Deleted. Now, with that being said, the last thing that we can do is definitely move around a file. So I'm gonna CD back in outside of source. So we do that with dot, dot, slash and now we're inside of our actual product projects folder MZ You could see before we were in MZ slash source. So that's how you back out of files. And with that being said, maybe I want to change the name of my read me file to just read me with no MD so we could do that by doing get envy, specify the name of the file and then specify what we would like to change it to. So in this case, I don't want it to be dot MD so I can do get in the and that's the original name, and that's the name I want it to be now. And if I do ls again, you can see that the name is completely changed to read me. So that is how you essentially delete your file. Get get to stop tracking your file untracked hit and how to change the names of your files within Get 21. Branches: All right, so let's get hypothetical for a second. Okay? So we've just made some changes to our files, right? We deleted the products page. We made it to where we stopped tracking the index html. And we also made its where we change the name of our read me file dot MD to just read me. Now let's say I want to start experimenting, right? Maybe I want to add a sidebar to this landing page or I want to add a check out button, but I'm not really sure if I'm gonna like it. I'm not sure if I'm gonna keep it. I just want to experiments with this new feature and see if I want it. Well, what I could do is I could commit the changes that I've already made and then start working on this new feature. And if I don't like it, I could just take it out. But another way and honestly, a better way in less confusing way of doing it would be to use branches now, in order to kind of illustrate what branches do and kind of conceptually how they work. I visited this really cool website made by the people that get hub. It's really cool. If you want to follow along during this video, go ahead and go to get dash school dot Get hub dot io slash visualize ing dash Get I know it's a mouthful, but just pause it. Type in this URL and you'll be good to go. So, as you can see right here, we have a doll. One hash right here. That points to this version of our actual project. And this is on the master branch. Okay, so this is the main branch now. What we could do is right here in this little box. We could types, um, get commands right here. I'm gonna typing gets if it'll let me. Is it typing? Let me see. There we go. Gets commit. Okay, so now this creates a new commit snapshot. And now we have a new version, a new hash pointing to a new version of our actual project so we might do another get commit. All right. And now the next thing I may want to do is now that I've made all of these commits, I may want to try out my new sidebar feature I want when I experiment with this new feature . So what I might do is I'll make a new branch. So how do you get? Check out and don't worry. We're gonna decompose this. Break it down. Do dash bee the bee flag for branch and then the name, so whatever we want to call the branch. So in this case, we'll just call it New Branch. Okay? Hit. Enter now a couple of things happen. First, the head right here stopped pointing at our master branch and it started pointing at our new branch. Okay, let's go a little further before we start explaining things. So we'll do a couple of get commits like so and then would you get commit like So now this is really cool. As you can see, the master branch stayed behind in this new branch was created. So now if I'm adding on a sidebar feature, it doesn't matter if I mess up or if it turns out I don't want it because I can always go back to the master version and everything is still the same as it was before. And on top of that, I can change back to the master version by using this check out. So let's talk about this command. This check out means I want to change to this other branch right here and keep making new versions of this branch. But I don't want to add it on to the master branch. Okay? And then we create the new branch with this dash B and we give it a name right here. And so this check out come in is just to switch the head over and point at the new branch. Now to switch back to our master branch, we do the same thing except when you get check out and then master like so and now the head is pointing back to the master and we may make a couple of changes on the master branch at a couple of new things will do to get commits right here. And as you can see, it branches off completely. So this way the master branch continues, and we keep integrating new things into the project without affecting this branch right here. So this allows us to experiment with new features and all kinds of things without having to worry about actually affecting the Master branch. The main software that's already working. So in other words, it makes it more difficult to break things, and it makes it a lot easier to collaborate with people. Branches are probably one of the best parts of working with get. It's very powerful. Obviously, we're just scratching the surface. But I really just want to give you all of the tools that you need instead of it being just like reading documentation to you. So hope you enjoy this. Now we're gonna go into our project and see how we can implement this. 22. Implementing Branches: now back inside of our working directory. We are basically having to files right here, one to be deleted and one to essentially be untracked. And we have our index dot html in the untracked files section and you can check that out by just typing. Get status and you'll see that right here. We're still in our project folder, Miss on the Master branch. No, we're gonna go ahead and make a brand new branch just like we did before. So whether you get and we want to check out to that branch So we want to start making changes from that branch. So after that, we will go ahead and do Dash B and the name of the branch. So in this case will do the same thing. Just call it new Underscore Branch. Now, of course, get will actually tell you what branch or on by just typing get status. So now you can see that we are on Branch New Branch and it still has all of the changes to be committed. And that may seem strange to at first I mean, this is a new branch, right? So why would it have things from the staging area of our master branch. Well, if you think about it, it might actually make sense if you really think about it, because essentially, we're creating a branch directly off of the master branch. So everything is going to be identical, including what was in the staging area. So it's actually pretty logical. It'll literally copy everything from the master branch and take it to this new branch, including your staging area, the files that were in the staging area. No, what we'll do is we'll commit him so we'll go get commit dash M and will include a message saying Remove products dot html in the Imperative and untracked index dot html hit Enter, too. Files changed. 341 deletions. Perfect. Now that we have that set up, the next thing for us to do is check, get status, see what's going on, huh? And it looks like we still have a file, and that's in the untracked section right there. And noone mawr. Interestingly, if we check out back to our master branch, get check out master like so you can see I get a warning. The warning says the following untracked working tree files will be overridden by check out . Please move or remove them before you switch branches aboard. So why is this happening? Well, let's take a look at this and understand it in the next video. 23. Stashing: so something pretty strange happened right before we essentially committed all of the changes that we had in the staging area from our master branch, and we made those commits on our new branch. However, whenever I run, get status, as you can see right here, it still shows are untracked file index dot html right here. And whenever I try and check out to the master branch, it actually prevents me. And there's a couple of reasons for this First the way that we stop that file from being tracked as we basically ran, get remove dash, dash cash and this removes the cached version of the file. But the file does still exist in our inside of our file system. And so basically, what get is saying is Look, you need to do something with this file. You can either add it to be attract again, or you can completely remove it now. Obviously, we don't want to do that right. We don't want to completely remove index dot html because it's important, and at the same time, we don't want it to be tracked. So what can we dio? Well, there is a good command. So what we'll do is first. We'll add it to the area, the staging area, and then after that will run. Get stash. Okay, Now what gets Stashes going to essentially do is save the current state of our working directly. So it's going to save what we're currently doing as it is right now in the index state work in progress on the new branch. And it's going to remove all of the things that were in the untracked files status. So if I run, get status again, you can see it gives us a clean working, TRIA clean working directory with nothing to commit. Now, if I want to go ahead and get this back, the way I would do it is get stash list to see what all is being stashed, and this will provide me with the one that we did save right here with our commit message right there. And if you want a short version of that, you could get stash show, and it will show you, ah, kind of abbreviated version of all the things that are being stashed. And of course, if you want to pop it back in, so that way it's being tracked, and you can work with it again. You would do get stash pop like so Obviously we don't need to do that right now. We just want to be able to switch out to our master directory so we'll check out to master , and now everything should go as planned. We are back and my branches up to date with Origin. Master and I switched to the master branch. Now, if everyone get status inside of here, you can see the untracked file is no longer in the get status of the master branch either because we stashed it. And if we need it later, we can come back to it. But we saved it as it is right now in its current state. 24. Merging: All right. So there's a couple of more super important things that we need to know how to do, the first of which I'm going to illustrate by making a new file inside of my master branch on the miss folder. So what I'm gonna do is I'm gonna do touch, and then SRC and we'll just call it something like ideas dot html. Okay, So, essentially, now I've made changes to my master branch, and I've made more changes to my new branch to illustrate this. What I'm gonna do is I'm gonna make a couple of commits with our handy dandy visualize er and this is essentially what we've done so far. We made a couple of commits on our master branch, and then after that, we made a new branch. So what you get, we'll check out to the branch that we're about to create with a dash B and then new branch like so. And then after that, we made a couple of more commits, right? And then we checked back out to our master branch. What's got to do a get check out Master, We went back to our master and we made a few more commits and we made this new file like So now Branch is a really cool because they allow us to create these nice, safe sandboxes, and we can test out new features that we might want to add without having to worry about messing up the actual main project. However, the sandboxes wouldn't be very useful if after we finally finished the new feature, we couldn't implement it in the main project. And we can actually do that by merging the branches together. The way we do it is simple. We just get merge and in the name of the branch we want to merge with. So in this case, new Branch. And as you can see now, they reference both branches, both histories at the same time, which is really cool. So it'll merge whatever branch I'm on with the branch, I specify now we can just as easily do this with an R code by seeing that were on the master branch. So we want to specify what were emerging with. So you get merge and then after that before that actually need to commit my change, because if we do get status, you'll see that it's untracked. So you get ad and then we'll just at all. And that's what the dot does. It just adds everything, clear it, and then we'll do a get commit and at a message, make ideas file like so in a little typo, try not to have typos. And then if I do get status again, you can see we're clear to go. Perfect. No one emergence. All you get emerge in a new branch. So this will merge the master with the new branch and the them should pop up. Now the them is kind of a subject in of itself. But we only really need to know how to do one thing right now. First, we're gonna do I to insert some text. And as you can see now, I'm adding text right here. And this is essentially like a commit message, but for emerging a branch. So we're leaving a message about how we're committing this thing. So right here, as do New Branch merged with Master, something simple. Now, the next thing you're gonna do, try not to click too many buttons in here. Okay, hit, escape and that'll take you out. And the next thing we'll do is out of colon. And as you can see, it's being added down here. Well, do you W q Okay, What this does is the W is going to save our changes, and the Q is going to quit the them. So now if I hit enter, all of my changes are made like nothing happened and the two branches are emerged together . So now if I go ahead and do an LS inside of my source, you can see I have all of these new files right here. And I also don't have the products page. And I don't have the index dot html because those air changes that we committed on the new branch and those changes are being combined with the changes on our master branch. Okay, so that's pretty much it. Now we're gonna learn how we can undo what we've done so far. 25. Reset: Sometimes we want to undo the things that we've already done. I mean, we're human after all, So we're gonna make some mistakes, right? And this is common enough that get has specific commands dedicated toe undoing what you've done. Ah, it's actually called Get reset. And there's a couple of different flags you can throw to set the degree to which you reset or undo something. The first flag is dash dash soft, and what this does is it takes your commit from the committed stage back to the staging area. This could be very good for a kind of regrouping your commits if you want to do ah different set of commits than what you've already done. This will take it from the git repository to the staging area. The next one is the one that's used by default, which is get dash dash mixed. This will take something from the committed stage all the way back to your working directory, so it won't even be staged anymore. It will be just in your working directory, as it was before, and the last one is get dash dash hard. Now, this is basically going to completely delete your commit or it's gonna erase it. Now, obviously, this is a very destructive command, So you want to be very careful. Whenever you're doing this, you don't want to delete your hard work. Okay, so just something to keep in mind now. What we'll do is we'll take advantage of get log. So what you get? Log, dash, dash one line and this will give us some one line not online. And I think it's just a flat. There we go. OK, there we go. We got enough. So the way that we specify what commit we want Theresa is we take this number right here of this Shaw one hash. So and that's, of course, how we identify our snapshots. That's what we identify them by. So I'll go back to We can go way back in time if we want to. I've merged a couple of branches so I can go back to when I just added the careers page before or when I just remove the products. So what I'll do is I'll do you get and then reset, and we'll do dash dash soft and then we'll specify the Shaw one hash. So in this case, We'll go back to this right here, copy it and then paste that like so and then enter. Okay, now, if I run the get log one line again, you'll see It's like I went back in time. It's all of these Commits don't exist anymore, right? But if I run, get status. You'll see that all of these changes are waiting. Okay. All of these files that I was to add are now in the staging area. Now, what I could do is I could actually do get reset. Or do you get reset? Dash, dash mixed. It does the same thing and do the same exact thing I did before. It's all pasted in. Whoops. I guess it didn't do what I wanted it to you. So I'll just copy it this time. Like so a copy. Run the command again. Whoops. There we go. Next reset. And then we'll paste in our shawl. One hash, which identifies our snapshot. Hit that. And now if I do get status, you can see that all of these files air untracked. Now they're not in the staging area. I haven't even added them before I added them. I just needed to commit my changes. Now it's just completely undone. And the last thing we can do is, of course, the get reset hard, the most destructive of them all specify the same Shaw one hash like so. And for some reason, it's not doing it the way I wanted to. But now I can just a matter of fact, we'll just get the one liner against would get one line wherever that is. Perfect. Now I can do get reset hard flag in the Shawal. One hash to specify the exact commit I want to delete, like, so copy and then we'll paste it in right there. Bam! Now this is completely deleted. So if I run, get log one line again, you can see like it's it's gone like it's completely gone. Now. We're just in our working directory, and we don't even have these files as untracked. So if I basically do this, if I do a list on my source file and then you can see it's just gone so very destructive command very, very useful for undoing your changes. Most of the time, you want to do a soft reset or a mixed reset. That way you don't completely delete your progress, but sometimes ah, hard reset is necessary 26. Pull Requests: So at the beginning of this module, we learned how we can actually push our changes up to the repository stored on get hub. And the way we do that is pretty simple, right? We just get push origin, master, and that will submit all of the changes that we've made so far. Now what we also might want to do is, let's say we're working on our work computer and we're working on this Project White. So now we're uploading our changes to get hub. So that way, everyone has access to the new version of the website and they could check it out as they need to. Now. What we might also need to do is go ahead and pull down. That's asking for things we might actually need to pull down a copy of this repository on our personal computer. Maybe we want to work on the project from home, right? So the way we do that is actually pretty simple. While this is pushing to get hub, the next thing I'll do is I'll go ahead and go to my get hub right here and you can navigate to it from profile and then clicking on the repositories tab, and I'll reload it just for to be sure that it's working. And now we can. Let's say we're on our personal computer now and we want to work on this project from home so we can pull down an exact copy of this by clicking on the clone or download tab and then hitting this clipboard right here and then All we do is really simple. Okay, we can now put this entire project on our computer. So what we'll do is we'll CD out of arm is and go to our desktop. They want to get clone, and then we'll just copy this year. Are Ellen right here and then hit? Enter. Okay. Once it does that, it's going to create an entire copy of the project that we can work on from home and version it using, get work on different versions, implement new features, merge those branches and then push him back up to get hub, and the cycle repeats itself. So with that being said, that is the end of the course. Guys, I really hope you've enjoyed it as I have. And if you have any recommendations for new courses, you like me to do new topics you'd like me to cover. Please do. Let me know and I'll see you next time.