Start Using Git Today! -- No Frills Source Control | Aaron Craig | Skillshare

Start Using Git Today! -- No Frills Source Control

Aaron Craig, Helping Everyone Learn the Best They Can

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
29 Lessons (2h 14m)
    • 1. 1 - Introduction To The Course

      0:50
    • 2. 2.1 - Git Overview

      2:04
    • 3. 2.2 - Why We Need Git & Source Control

      3:42
    • 4. 3.1 - Installing Git

      4:34
    • 5. 3.2 - How We'll Use Git

      3:41
    • 6. 3.3 - Configuring Git

      4:34
    • 7. 4.1 - Github & BitBucket

      5:50
    • 8. 5.1 - Cloning Your First Repository

      7:11
    • 9. 5.2 - Git Status

      4:46
    • 10. 5.3 - Git Add

      4:28
    • 11. 5.4 - Git Commit

      7:08
    • 12. 5.5 - Git Push

    • 13. 6 - A Brief Warning & Encouragement

      3:33
    • 14. 7.1 - Branches Overview

      5:52
    • 15. 7.2 - An Example of Branches

      2:33
    • 16. 7.3 - Creating Branches

      6:09
    • 17. 7.4 - Finding All The Branches

      3:52
    • 18. 7.5 - Deleting Branches

      6:29
    • 19. 8 - Git Pull

      4:58
    • 20. 9.1 - Merging Overview

      3:47
    • 21. 9.2 - Merging Without Problems

      4:54
    • 22. 9.3 - Merging With Conflicts

      7:51
    • 23. 10.1 - Forking Overview

      3:03
    • 24. 10.2 - Forking A Repo

      3:54
    • 25. 10.3 - Pull Requests

      6:18
    • 26. 11 - Remote Servers

      9:55
    • 27. 12.1 - Git Ignore

      7:09
    • 28. 13 - Best Working Practices

      3:50
    • 29. 14 - Errors & Issues Intro

      1:07

About This Class

Source control can seem like modern day magic -- Incredibly powerful, but impossible to learn. That's not true at all. While many tutorials on source control and git focus on how it works, this course focuses on how to use it. I've been using Git for years, have developed a workflow, and want to teach you how you can start using it today.

It doesn't have to be mysterious or impossible. Git is an awesome, powerful tool, that only takes moments to get set up and running. With my course, you'll learn exactly what you need to get started, and then how to figure out what else you need in the future.

Are you ready? Let's get started!

Transcripts

1. 1 - Introduction To The Course: greetings and welcome. My name is Aaron Craig and I will be instructor for this course that is short and focused on learning how to use git and source control. I'm going to give you just a very brief history. We're gonna get it on your machine, and then we're going to start using it right away because I believe the quickest and best way to learn how to do something is to actually start doing so. I'm gonna teach you the commands, and we're gonna get through everything you need to know to start using it right away. It is not a magic software that is Impenetrable to the normal masses. Everybody can use it and most people should be using. I'm gonna de mystify it, show you how to use it. And in just a few short hours, you will start integrating it into all of your projects like a professional. So with that, let's get started. 2. 2.1 - Git Overview: all right, so now you're ready to dive in to get. But before we do that, let's look at a brief history of git and also clear up what may be some confusion for people. So get is not get hub. They are separate. They are not the same thing. I don't believe there developed by the same people. Get hub is a place that you can store your code everything that you're working on through get a lot of it for free, but you can also pay for it. Git is actually the software behind how that works, so there's not the same thing at all. It's just that they took the name, get put in their website name, and now it is pretty much the most popular place to use when it comes to version control. Now a brief history of get because it's actually pretty interesting. So Linus Torvalds and the community was working on Lenox and they were using a source control called bit keeper, but they had a falling out. It didn't work out. They revoked their license bit keeper did, and then Linus and the community was like, we need something because we've got people working all over the world. We need to still be able to communicate and do all these things that we were doing. And so they went out and designed their own system. And in 2005 git was born. Get is free, it's open source. It's quick, and it is pretty much become the de facto for source control. There are some other software source control out there, but it's very rare that you will run into them as get is just taking the world by storm. It is pretty much completely won the battle for source control. So if you see anything else, uh, well, I would stay away from it. But if it's for your job, then definitely you gotta learn and stuff like that. But you most likely won't as get is what every business and every project uses. So with that, let's jump into why do we need it in the first place? And I'll talk about that in the next video 3. 2.2 - Why We Need Git & Source Control: So now that we know where get came from, why do we need it in the first place? Like why was it created? And that's a really good question, because it's something that you might not think about when you actually sit down to start working on a project you don't envision. Oh, I need to have a way to back all these files up and see the changes and do this and do that . You, as a developer, probably just want to get working, which makes sense. But as you start working on projects, there are things that can happen. Mistakes, errors, deletions, crashes. And when that occurs, it's very helpful to be able to go back to recover from those problems. And that is what source control is all about. And so source control allows us to basically see everything that has ever been done to our project. Bye bye, who it was done when it was done and exactly what changes were made. And it's simply fantastic. So there are different types of source control. There are local, there is central and then there's distributed, which is what I get is so basically what this means is that if you create a project, then you initialize it with get which we'll talk about that later on all the terminology. But if you set get up and you use it properly, then every single time of changes made to a file of any kind. And that's really the awesome part is that it's not just for developers. Anybody can use version control, and anybody can use git any time a changes made. So if you edit a photo file, if you add a line of text inside of a code file and then you save those changes, you can show inside of git. When that was made, who did it and compare the changes that were made compared to what was there before. And that is where its strength is. It allows you to see everything that has ever been done in your project and then go back to any of those changes. So if you've got multiple people working on a project and one of them ends up believing everything and then they push that out and that's now your project, well, that would be a big problem if it was on Lee on one machine. But get is distributed. It's all over the place. It's on everybody's machines was using it. And if you're using a remote server remote cloud like get up orbit bucket, it's on there as well. So somebody goes and deletes everything. All you have to do is go in Graham, an older version of your project. Pull those changes, and now that person's mistakes is completely wiped out. It's like they never did anything. It is super powerful. And when you begin developing projects or really anything like, I've even used this for homework and college, just keeping track of things. You want to have source control. It is super useful. You don't need it, but you definitely want it. Because if you ever run into a problem with source control, you can just jump back to the last working solution with just a few strokes of the keyboard . Super easy, super simple. Well, once you know what you're doing. So with that in the next video, we're going to start talking about how we actually use it and why there are so many ways to use it and which one I would recommend 4. 3.1 - Installing Git: So without any further stalling, let's go ahead and download. Get and get working on stuff. So the website you're gonna want is gets dash SCM dot com If you just type g i t. Uh, while give that might come up, G i t. It will be the first search result for what you want. You can click on that and cook on download. It should automatically find your system. If it doesn't, you can click on that download button, and then you can choose other versions of git, and you can find exactly which one that you need. It will take just a few minutes downloading maybe even less as mine is now already done. So I'm gonna go ahead and open it up. And the reason I'm gonna walk you through this install specifically is that there are a lot of options. Forget. So what are you on your system? All good. If it's not, let's walk through this together because they're some ways that you could probably mess this up. So put it where you wanted to go. That's not that important. If it exists. If not, it will make the folder. Uh, here's your icon set up. Now, this part is kind of important, especially for how I'm gonna be doing some tips and tricks later on is on the Windows Explorer integration. You want tohave get bash here. You don't need the get gooey here. And I also don't put the icons on here and I don't use true type or check it daily for Windows update. So this is how I am actually installing it, which you can do the same if you're on Mac. I believe there's also a way to do this, but I'm not sure how they handle it. So let me know as I don't have a Mac myself. So then I'm not gonna create a start menu folder. Don't need to worry about it Now. Here you choose the editor used by get, and this part is important as well. So them is the default, but them is not user friendly. If you've used them before, you probably hate it. If you've used of him a lot, I hear that you actually begin to like it. But I don't like them. So instead, I'm actually going to be using visual studio code as gets default editor. If you don't have visual studio code, then you can download that as well. If not, then you can just use either no pad plus plus or nano or whatever one that you feel comfortable when visual studio code is what I would definitely recommend. So when I click on next there and now we've got the path environment. So I'm going to use git, bash or use get from get bash only. And what this does is it makes the terminal Onley git bash. So otherwise you can use git commands from the Windows Command prompt, which is okay. And then you can also use git and optional UNIX tools from the Windows Command. Prompt. Um, I wouldn't recommend that it's a little more advance of an option. I would just do this 1st 1 It's nice and easy, and it doesn't come with any modification of path variables. So next up is the back end. I would use the open SSL library. That's always worked well for me, uh, configuring the line ending conversions. So here I would just do the check out windows style. That's what I'm familiar with. And it has worked very well as well, so I would just go with that. And then you've got convicted the terminal emulator, so I would use men T t y. It is the default one. And it has always worked well, so you don't need to use the windows default console window. So, like I said, there are a lot of options in here. So here are the extra options. I would just go ahead and click next with all of them, especially the credential manager. It helps when you are logging into give a bit bucket, it will store those for you. Otherwise, you're gonna have to provide your credentials every single time you try to save using git, and that could be kind of annoying. And then you go next and you install it. I had a process running there so close to that for me, and that's insulting. Get a lot of options, a lot of different things that you can do. But if you did the exact same thing I did, then you should be all set and all ready to go for when we start using git. So I'm gonna take a brief pause in between used installing git and using it, and I want to talk about why I'm gonna be using the version or the type of get I use, which is get bash. And so I'll talk on that in the next video. 5. 3.2 - How We'll Use Git: So the question is, how do we actually use git and not the terminology but the actual interface? And by the way, if you're get bashed looks a little different than mine. I have customized some options, and you can do that by right clicking, doing the options and changing that looks in here. And specifically I changed the window size because I like mine to be a little bit larger. Se point done, one of the actual interfaces that are available for using git. Well, there's actually quite a few. So any software that you use that's like a full I. D. E is going to have source control built into it that you can plug get in. So, for example, if you're using Eclipse, you can see here that it has my git repositories here, and I could do things inside of a gooey a graphical user interface. I can click on buttons, and I don't have to actually type out commands, and it will do everything that get needs to do. Then you've also got things like visual studio code and visual studio. They have source control options in here that you can set up and configure and you just have to look at the icons and push the buttons. But I highly recommend that you do not do that. The primary reason is that this course is going to be using the gets bash terminal. So if you're trying to follow along using a gooey, they're gonna be in trouble. The second reason is that all those Gu Ys are doing are just typing in get commands for you . And that means that they air abstracting that away from you so you don't know how they're actually working. So there are. There's a command called get commit and you don't need to know what it does right now, But there's going to be a button that says, kind of like commit and then it will do something on the back end. But if you don't know the actual command to type, dash him and then to put in a message here, then if you change software, if you are not using visual studio code anymore, you go somewhere else. You're going to be lost because you were focused on how to use get inside of a piece of software instead of understanding the commands that run that suffering behind the scenes. So that's why I highly encouraged to use the Bash terminal, even though it's a little intimidating. If you've not used the terminal before, it can be hard to jump into it. When I first started using git, I will say that I used a gooey the one that you can install with git And honestly, it made things more confusing. It was a visual representation of some things, but I didn't understand a lot of the options, and I didn't know what they did, and it just made things worse for me. So we're gonna be using the git terminal, and hopefully I can explain things well enough that it will make sense. And by the end of this, you will feel extremely confident inside of this terminal, and it has some of the same commands as like a regular terminal windows, Lennix, apple, whatever. So you'll actually able to do some of the commands as well, such as CD and LS. These are things that you could do, and you can run them on any terminal, which is pretty cool. So that is why we're gonna be using the terminal, and that is how we're gonna be using git. There are other ways, but I highly encourage you to ignore them completely and stick to the terminal. Even when there are options baked into the software, you'll be better off and you'll be able to work with get from any system anywhere because you'll know how it works on the back end. 6. 3.3 - Configuring Git: So now that we've got to get installed, we need to do one more thing before we really start working with it. And that is to configure our name and email. So this is important, because every time that you make a change, this name and email will be associated with that change. So let's look at how to do that. So inside of the git bash terminal, we're gonna type out to get G I t. Now, I want you to be following along because you need to configure your name and email, and now is a great time to do it. So you type out, get G i t. And that is the preface for all get commands. And we're going to say config space we're gonna do to Dash is Dash, Dash Global, and then we're going to another space. So we're telling you that this is gonna be global across our entire system. We're gonna set the user period name. We're gonna set it by pressing space and opening the quotation marks. And then we're gonna put anything we wanted here. So I'll put, uh, Tom thumb close that out in press enter. Now. If it works. You shouldn't get any kind of error if it doesn't work. If, say, I don't have a space between name, and when I start typing in my name, it's going to say error Invalid key. That's one kind of air you can get. If you don't have a space between global and user, you're gonna get an error that says Unknown option. And it's gonna give you all these options and it's trying to be helpful. Can just fills up your screen, though, and those are the kinds of errors that you're gonna get now. They're a little bit difficult to read, especially at the beginning, so follow along as best you can. And if you get any errors that I'm not covering, feel free to shout out below, and I'll do my best to help you. Now one little trick that you've already seen me do, and I'll explain how I do it is by pressing up on the arrow key. You can actually put in there what you have just typed, and this is extremely helpful in a lot of different scenarios, and if you press down on the heirarchy, it'll go to the one. I guess after that so you can press up and back quite a few times. Um, super, Super useful. So I've got my name set. It works. Now. I want to check if that works. It did work because I didn't get there, but let's look at it. Let's go to get config. Dash Death list Press enter. It's going to come up with a lot of different options, but down near the middle, bottom ish come up with user dot name and it will say, Tom Thumb or whatever you put in there. So that's awesome. Now we're gonna do email. The exact same way is a git config dashed after global Space user period E mail space. Open quotation marks and put in whatever you want here. I'm gonna put in my games email impressed Enter press up twice on the arrow key and bring config list back up and you can see here that my user name and my user email are now set. If it any time on your system, you want to change your name, you can use this command and it will work just fine. But if you have multiple projects running and say that inside of one project. You are working under a different name in different email. You can change that inside of there by using get config Death staff local. Now, I can't show it to you right now because you actually have to be inside of a repository. And we haven't talked about that yet, so I don't want to rush too far ahead. But it is possible toe have different user names and different emails for individual projects on your computer, and that's a really good thing to know. Now we've got get configured and set up. So in the next section, we're going to start talking about where you can use git and we're gonna look at get tub and bit bucket one of those I'm guessing you've probably heard of, at least because I've already mentioned it and we're gonna look at what they are, what services they offer and why you might want to use one over the other 7. 4.1 - Github & BitBucket: So what I want to talk about right now is the two most popular or at least probably the most popular places for you. Toe actually store your code online so that you can work distributed Lee or remotely with lots of other developers. So there are a lot of places, but I'm only going to cover two of them because they are, like I said, the most popular and the ones that you will run into if you're working with other people or if you find a project that you need to then download or clone or whatever. So we're gonna walk through some of those and I'm gonna look at some of the features that they offer. Now get Hub is, I think, the most popular one. Although just think two weeks ago now it was acquired by Microsoft. And so some people are a little worried that Microsoft is going to come in and mess up this good thing because get hub is open source and it is a fantastic place to use, partially because it inquire encourages cooperation among everyone because you can see people's projects now. Bit Buck, on the other hand, is taking advantage of Microsoft buying get hub in telling everyone that they should move to bit bucket, which I think is pretty funny now big bucket ISMM or for individuals, I guess if you're not looking to share your project or be found as easily So let me show you what I mean. If we long into bit bucket or longing to get up here, you can log in with after you making account and you can see here that this particular profile doesn't have any projects associate with it. I fork to this one. Which door what that means. But if I wanted to find a project such as Enemy start CSS, which is a great library for just animating anything, HTML, you can find it by searching and then you can download it super easy. And this particular repository, they have a website that redirects you to hear because get hub is hosting it for you. They take care of organizing it of showing everything that has been done. You can view all of the changes that have been made since the very beginning of the project goes back to the very beginning so you could see how it has evolved over time and you confined every project on here that isn't private very easily. Now, a bit bucket, on the other hand, is a little bit, uh, guess more private focused. So if I log into my account here, I've got several repositories that I have here, and you can see here that I can search, but I'm not going to really come up with anything. So if I search enemy got CSS, it's only going to search my repositories. So it's not gonna find anything. It is much more focused on your personal group or team, and not as much about sharing. Now if it isn't private like these for a private, but this one isn't so. I could easily share this link, and anybody who finds it can come in and download it and use it. But you can't find it by searching is easily so That is one thing that get hub has over a bit bucket. If you have an active get hub profile, if you're contributing to projects, then that is actually a wonderful thing to put on a resume. Your developer or your your employer would love to see that you were active because it shows your skills, your work, ethics on all the history of the work you've done through projects, so you're get help. Profile is really fantastic that way. And if you're looking to build up a good thing to show off to future employers, make it get up, account and use it very often and contribute to other projects, help people out. Now, if you're just looking to store code and you want it to be private, then bit bucket is the place to go. And the reason for that is that when you create a new repository, you can make it private and it is free as long as there's only a certain number of people working on that repository, and I keep using these words. But don't wait what they mean just yet. It's just a project. So if I try to make a new project repository here and I want to make it private, you have to upgrade your account. You have to pay $7 a month at least to be able to do that. So for me personally, because I develop games and projects that I don't want other people to have access to just yet. I use bit bucket because it allows me to have private repositories for free as long as I think there's like five or less people on your team, which for most of my stuff there is, actually for all my stuff there is, so get hub versus bit bucket. If you're looking to do a private repository and you don't want to pay bit, bucket is definitely the way to go. If you're looking to be more social, have your product we found and used all over the place. Get Hub is definitely the way to go. It is larger, it's more social, and it's fantastic in that regard. When it comes to features, though, both of them are. I think pretty equivalent Get Hub has mawr side features. They've got more things that you could do. Uh, but for the most part, when it comes to working with your project, they're gonna have exactly the same things everything that you can do and get help for your project. You can do on bit bucket so personally I like bit bucket. It's kind of what I started with, So it's what I use. But if you use get hub. I'm gonna be showing how to use that as well throughout this series, so that's no worries there either. So I think that covers the two major hosting websites. And with that, I think that's everything when you know. So let's go ahead and start making our repository start creating projects and I'll show you how to use git. It's gonna be awesome. 8. 5.1 - Cloning Your First Repository: in this section. I'm gonna go through cloning a repo, adding a document and pushing those changes to that repository. I'm going to do this very quickly and I'm gonna do it through get hub and bit bucket in this video And I'm gonna not take the time to explain each individual command because I think the most effective way to learn how to use git is just to see it in action and then have it broken down step by step later. So this video is gonna be a quick overview in the next section. I'm gonna break down each command what it does and how exactly you use it and will also cover what to do when commands don't work properly. Because that's something you'll probably find quite a bit. So let's get started on the overview I'm inside of get had to make a new repository inside of here. You find this green button that says, new repository, we make it and we need to give it a name. I'm gonna call mine my first repo, and we don't need to change any other settings right here. So I'm gonna go ahead and click the other green button saying Create repository, then it gives you a lot of options. Now, if you're branded a source control, I find these options to be intimidating and utterly useless because they are just completely foreign if you have never used it before. So what we're gonna do instead is opt in for the option that does pretty much all the work behind the scenes. And honestly, that's what I do on all of my repose. I don't go in and manually create a repo. I just haven't do it for me. It's faster and it's always correct. So what we need is this address right here. This is actually the address of our repo. So I'm gonna go to my desktop first, right? Click, get bash here, and what I'm gonna do is type get clone. So every time you use a command inside of git, you need to actually say G I t get the command and then any optional parameters or required parameters that have come after it. So we say, get clone. We're gonna go back to here. I'm gonna copy this. You can use this or you can press selected on in control. See and come back to here, right click pasted inside of here and you can see that I am. Now get cloning this address. I'm gonna click enter and it's gonna tell me I've cloned an empty repository because I have There's nothing inside of it. So I'm gonna exit that. Enter here. Now, if you can see hidden folders on your computer you're gonna see this dot get This is something that you'll never want to mess with. This is the all the behind the scenes work and you want to let this just do its thing, which is why it's a hidden folder. But I'm gonna show you how to add something. So I'm going to right click, make a new word document. Just call it my document Now inside of here, I'm going to right click, open up, get Bash! And now we can actually add things to our repo because we have the dot get folder inside of here. Now there's two ways you can do it. You can add to the documents specifically, or you can add everything inside of it. I'm gonna add everything inside of it because it's faster and most of the time you want to back up everything inside, but we'll go over how to do both of those things. So I'm gonna say get add, period. Adds everything inside of there. Now we look, we can see that we have a document that says there's a new file in a repository. What do we want to do with it? We want to commit it. When you commit it, you give it a message. I've added a document. So that's the message that goes along with this change that I've made to my project, that I'm going to say, push all the changes to the server So they're going to be pushed up and they're going to go where they're supposed to go takes just a second has that new branch of master as it does by default. So then we can come back here, and if we cook on code or we refresh the page, you're going to see that we have added a document with our message here. And here is our document. It's empty. There's nothing there that makes sense, but it is now on a server. You can access it from anywhere in the world and your folder that we downloaded is constantly being checked and tracked, and you can make sure there's lots of things you can do. It's awesome, but that's how you add it to the repo from Get Hub. Now let's do it from bit bucket. Same thing really quick from here. You need to click this little plus icon on the left. It's going to let you create lots of things, but we want to create a repository. I'm gonna say my second repo will make this one private. Just keep everything the way it is. Create a repository now inside of here. This one looks a little simpler in my opinion, and this even has to get clone option. However, this defaults to S S H, which is not what we want because you need authentication when you're doing that. So we actually want to just do https. So this already has to get clone inside of it. I'm gonna copy this whole thing, exit out of here, get bash on the desktop again, and I'm just going to right click paste and you can see the whole thing is already in there . Click Enter. It's gonna do the exact same thing that it did before copied into an empty repository. Yep. But it still has this dot Get get is gonna be the same. It's just that we're hosting it somewhere differently. That's all the differences, the commands, everything are still the same between bit bucket and get hub. So let's add a new document with the quick list time, it will be a power point. My presentation. I'm going to right Click Open up, Get bash! I'm gonna say, get ad commit at a power point. Get push. It's gonna push it up, save it to our server and there we go. So we come back to hear Refresh the page. It is now in here. That is my message. All this saved. That is a really quick overview without really any explanation about what is going on. But you see that it works and you can start doing it right away. So let's jump into what we're doing, how it works. And then eventually we're gonna start talking about errors because you may have already discovered some errors. If you're trying to do this and if you have jumped to that error video, I'm putting together a document of errors that are very likely and common, and that's one of the things that you will find with source control. No matter how careful you are, you will find errors when you are trying to do commands when you're trying to push up when you make a mistake and you don't know how to fix it. Source control is beautiful and wonderful and terrible at the exact same time. Hopefully, it gets better in the future, and we don't have near as many problems. But for now, check out the era video. If you have any. And if not, let's jump into what these commands do and how you can start using them. 9. 5.2 - Git Status: in this video, we're gonna look at the git Status command. So to use the status command, do we have to also use other ones, So we'll use them. But I'm gonna explain Get status as we go along. So use one of the repose. It doesn't matter which one. I'm going to be using my first repo just because it's there. And right now, if I type, get, remember, get needs to go before any command. So any time you want to do anything with git, even though you're inside of git bash or if you're using the command line terminal or, you know wherever you are, you need to type, get, and then you say status if you type enter. If everything is good, then it's just going to say it's up to date. Nothing to commit working tree clean. This is when you have the most recent version. No one has made any changes. Your computer is up to date, so that's great. But that's not gonna happen that often. So what do we need to do well to make it change? Let's go ahead and add a document. Let's go ahead and add another Microsoft dark say another document? No inside of here. If we say get status again now it's going to show a red line that says untracked files use . Get at it, trying to tell you what you need to do. Another document. So it has found our document. Exactly. It knows it's there, and it wants you to do something with it. Okay, so that's one thing. Now, if we add a new folder and that's add in something else so an access database No, I'm gonna change the name. Well said, Get status again. Now we have another document and we have a folder inside of here. So now there's a hierarchy. So get is tracking everything inside of your even into folders and folders and folders. Everything can be tracked now. This is the same thing that looks like up there. It's just tracking more things that make sense. So now, to change this, we need to add them. So adding them we'll talk about in the next video, but for now, just know that it gets them ready to be pushed up. So if I said get status now, you can see that now they are green, so get has actually said OK, I know you want to keep these so I have added them and I have checked them in. But right now they are just like at this waiting area. Basically, they've taken a ticket and it says you will be seen too soon. But for now, I've got you, so just hang on. So to get him further long, you need to do a commit so test must go typing anything here. It doesn't matter. So once you have committed them, they basically kind of gotten on a train or an airplane. Or however you want to think about this, they are now ready to G O. And they're just needs toe pedal to the metal to be pushed off, saved to the server. So if we say get status, we now see that there's no folders, files that haven't been found or they haven't been added. Instead, your branches ahead of origin slash master by one commit. So we've made a commit and we're ahead by one. And if you see the very first status, we were up to date. But now we are ahead of it. So if we push those off, they go to the server. Get has said I tracked them. I know what's there. I've told everyone that needs No. So we say get status. Everything is good. We're back to being up to date. All is settled. So you're gonna use get status a lot. You're gonna need to see files. You've added files that are ready to be committed things like that. I used get status quite frequently just to see what's changed. Things that I've added When you have merged conflicts, you're gonna want to use get status to see exactly which things are in conflict. Don't worry about that right now. But remember, get status. It is one of the primary commands that you were gonna need to know when using source control. It's really simple. It's easy. It's a word that makes sense, which is nice, because not all of these words do make sense. They don't all do what you might think they would do. But get status is the one that really does. It tells you how things are going and what's up with your source control. So remember that use it a lot, and now let's move on 10. 5.3 - Git Add: in this video we're gonna be talking about Get ad and I'm using my second repo just to show you that it doesn't matter which one we're using here. You can keep using the same one or follow along with me. It really doesn't matter. So open up, get bash inside of your repo, and we need to add a new document of some sort. It doesn't matter what. So I'm gonna add a new war document? Not I'm gonna bother changing the name. So if we take, get status, get nose is there. But just having the file in there doesn't do anyone any good right now. Get is not actually going to be tracking that file. It's not gonna be seeing if changes were made. It's not going to know who made him. It's not gonna be pushed to the server. It's not gonna be backed up in any way that's meaningful. It's not doing anything. And that's because we haven't added it yet. When we add a file or folder or everything, all the ones we are putting it inside of gets memory kind of like the example used before of taking a ticket. So right now, this file wants to get in there. It wants get to take it and let the know that Hey, I'm here. I'd like to be tracked. Will you do this for me? Right now? It's not. But if we tightly get ad and I said before that there are two ways to do this. The way I showed you before was with the DOT. This right here will add everything in your git repository and it will be added all at once . If you know what you're doing. This is the quickest way to do it. Otherwise, we need to add them in manual. So if your file or folder has spaces, we need to do quotes. So this is new. So this is a single quote. Get add. Single quote, new Microsoft, a word document with the extension dot doc ex and a single quote. And we can add it in there. And you can see once again that now we've added that. So if we add another one, though, excel all to say this is a test one. So that doesn't have a space. But get knows it's a going to get ad. It was a test one dot Excel s X. Yeah, that's it. So if we do that, that works Fine. Get checks it in. There's no spaces, so it works, Okay, But if there is a space, then you have to use those single quotes. Otherwise, it's not gonna work. So if we try to do this again with just a text document, I can say get ad new text, document, text and it says a fatal path spec new did not match any spaces inside of get inside of any command line that you're using usually indicates either command or a parameter of some sort . So a space is not allowed, so you have to use those single quotes. Most of the time I use get, add docked. And that's because whenever I add a new file, I wanted to be tracked. Very rarely am I gonna add files that I don't actually want get to track. There are cases and we will go over them. And there's also ways to manage that so that you don't always have to type in all your things. All your files single, adamant like that. There are ways to ignore certain files, which is awesome. But I don't want to work. Worry about that right now. So most of the time I use get add dot at everything. It's quick. It's simple. If I put something there, I want it there. But now you know how to do it both ways so you can add individual files or you can add everything all at once. Whatever you need to do. If you're not the owner of your repository, you probably want to make sure that all the files you're adding are appropriate, that they don't contain any sensitive information and that all of those things are good to go before you actually push them off to be saved elsewhere. So that's get ad in the next video we're gonna talk about committing. 11. 5.4 - Git Commit: all right, I'm picking up exactly where we left off before. So if you aren't doing that, then make a new file inside of your repository and add it and then you'll be there. So if I take good status right now, I have new files inside of here. It tells me exactly which ones they are, which is awesome. That's good to know. No continuing along with our analogy of boarding a train or a plane or whatever. Uh, these files have gotten tickets. They have been checked in. People the people know get knows that these files are there. Now we have to do is basically get them onto their plane or because I need to pick one. Let's go with plain because they're fast. They're these documents need to get onto that plane. But to do that, they need to be actually, like, checked in all the way. They need to actually get on there to get on there and get it's called commit. And when you commit, you need to add a message. Now, this is important. When you start using source control, use good commit messages. You will find articles people writing about this. You'll find arguments online. Let me just say in practical experience, when you are going through your repository, you want tohave good commit messages. It makes it quick to find change is easy to see what happened, and it is all around a time saver and worth the few seconds every time you type it in. So how do you do it? You type, get commit to EMS and then you can do it two different ways. You can just type, get commit. And if you type enter, it's gonna bring this up. And this looks kind of intimidating. If you've never used vim or vibe before on Lenox, then this could be very confusing, which is why I actually never use it. But if you're in here with me also, you had to get out of it. First, you go down to the bottom and then you press a for upend or i for insert either one press enter one time so that your at the bottom here you can't have any of these pounds symbols, hashtags and front. So this is where you actually type your message. Adding a bunch of new files, OK, press escape, and then press shift colon semicolon. Then you can see down here that that actually shows up there, press w Q. Which is right and then exit. I don't know why he was exit like it's for quit. That makes sense. And then you press enter. So that adds the commit message. And if we do get status, you can see that they are all there. So if I do get pushed for the quick that will get added to the server and then we can go and look at it. And this was inside of here, so I'll refresh this page and Walla. So I added a bunch of new files and you can see that this message is actually on all of them. And you can also see that it was a minute ago, even though we just added it, and that's because we actually committed it over a minute ago. We only just pushed it now. So the commit it takes get tracks when you commit it, Not necessarily when you push it like it knows when you push it, too. But the commit is right there because you can push several commits at a time, which is actually really good thing to know. So if you have several changes that are going on, so let's say I add a new file here. Rich text document. Uh, it's called Document. Open this up. I can say get ad and then the other way to do commits. You type, get commit. It's a dash M. Then you open up quotes, double quotes and you say here, type whatever you want. Here's a message and you ended the double quotes and press enter. Same thing that's gonna happen right there. It's just a lot faster and a lot easier to get in and out. That's what I would recommend doing now. I said, get status. It says that were ahead by one commit. But we don't have to push it. You can have lots of commits stacked up and ready to go. So if we go, actually, if we come in here and we can actually delete a document, I say get status. You can see here. And now that this is deleted so I can come in here, I can get ad get status. So now it knows that it's been deleted, and that might be a little un intuitive when you delete a document you have tow ad, you might want to think of ad is just like adding any change that has ever happened to this repo. So it was deleted. It needs to know that it was deleted and tell the server which then Comptel every other machine that's using this repo. This file was deleted. So now I say gets commit, lead it a file. If I say get status, you can see that we're ahead by two. Commits. So commit is just getting everything ready. In this case, I guess it would be like getting two planes ready, ready to take off at the same time, I'm not really sure it's kind of breaking down that analogy, but I hope that makes sense. So we push these now, they'll both go. They'll both be at different times, and they'll have different messages, which is, you know, I think that makes sense. We refresh the page with F five and then we can see that are changes have been marked. Now you don't see the deleted file here anymore, and that's because it's been deleted. You'll no longer see it inside of here, but if we come in, Actually click on commits. You can actually see all the messages right here, and this is why it's so important. When you look at your commit history, you can see exactly how things are going. If I say just deleted a file or left it completely blank, nobody on the team would have any idea what happened in that commit, and that is frustrating when you're working with the team. Trust me, I know when you are working with a team, even when you're working with yourself, you want to leave good commit messages so you can go back. There are commit messages inside of here. If you come on to get bucket, get, have and you can look at the commit messages here as well. You want to have good commit messages. They will make your life and everyone else's life so much easier. But that is commit in a nutshell. That's how you use it. In the next video, let's talk a little bit more about push 12. 5.5 - Git Push: all right. 13. 6 - A Brief Warning & Encouragement: before we jump into the more advanced features of get, I want to take just a moment to talk about how you can totally screw up a repository. Now. I don't want that to sound scary. Instead, I want you to think about all the ways you can destroy a repository and then realize that that's how it was built around. So on your own computer. If you destroy the hard drive like just obliterated it, you would be out of luck. But get is not in one place. It's not centralized, it's distributed. So if your computer dies, that's fine. If bit bucket and get hub servers blow up tomorrow, that's probably going to be fine because it's on your computer, your co workers, friends, some random dude who cloned it online. It's everywhere, so you have access to it because it's not in one place, so that's awesome. If you go in and delete everything again, same thing it's still distributed. And if it doesn't get updated before after that's been deleted, you still have a working copy of it somewhere. Then you can make a new repository with those files and folders and be totally fine. So a lot of the worst case snares I can happen get is designed, especially distributed using get tub and bit bucket. It's designed to be, uh, flexible and recoverable by nature. That being said, there are times that you can make some mistakes when you start doing things with source control. You might run into instances when you do accidentally delete a repository or you remove a branch and it just messes everything up. There are times when you can make mistakes and completely destroy repository, and it might be unrecoverable. There are times when that can happen, but I want you to take a breath and rest assured that you can come away from it and it's OK and you will not be the 1st 1 to do it. If you go online and look up, get horror stories. You will feel so much better after any mistake that you make. I know that I have made a lot of mistakes, and I've been using it for quite a while. I still make mistakes and run into errors. That's just the name of this game, and that's okay. You will not be alone and you will not be the first, and it will be okay. Just know that. And when you run into a problem, when you make what seems like a game changing destruction mistake, just take a breath. Work through it. It will be okay. And I want to say this because it's going to happen to you. Most likely. Even if you're careful, it's probably gonna happen. Maybe you won't be the one to do it. Maybe it will be a teammate, and you'll have to be the one trying to fix it. Just know that in your time, working with source control, it will happen. But I can tell you from personal experience that it is worth all of that potential stress for the benefits that you get using source control. So with that out of the way, let's jump into the more advanced features. 14. 7.1 - Branches Overview: All right, let's talk about branches and what they are in general, why you want to use them. And then in the next couple videos will get into specifics of how to use them and things like that. So branches you can imagine are a way of taking your project and trying out different features without affecting your main project. So if we think about this, there are several different ways that you could try to implement a new feature into whatever you are developing, and one of them is good and all the others are not so good. So the 1st 1 that you could do is just go ahead and make some changes that you're thinking about. Say, you're building a website or mobile app or a video game, and you get this idea for something and you want to test it out. But you don't know if it's a good idea or if it will work. So you decided to go ahead and try it out just on your main branch, and we'll talk about that in a second, so you just go ahead and do it, and if you do that and it doesn't work out Well, you're using source control so you can just go back. Look at all the commits you've ever done and say, Okay, I'm going to start on this commit and that's what we're going to use. Just delete everything else that we did. You know, after this, commit and let's revert back to it. This you can do. But it's not very clean, and it's not a very good idea, especially if there is anyone besides just you working on this project. So let's scratch that idea. The second idea is to take your repo and say I have a new idea now, So I'm going to make an entirely new repository, copy all of my code into that, upload it and then try out my new feature on that. Okay, again, this is not a great idea. It could work. Uh, if you're only doing something by yourself, then yes, you could do it this way. It would allow you to make changes, and the main project would not be affected. But if you're working with more people, it's not gonna work. It's a lot of overhead, a lot of extra time. If the new repo is what you actually want. You should probably go back and leave the other one. And then you just you lose all your commits when you make a new repose. Well, so that's it's not a great plan. So let's not do that one either. But the third option is actually kind of similar to the second, but in a much better way. Ah, Branch allows you to take your project wherever that's at. So it's goto bit bucket here. I'm gonna show you because they can actually make a branch on here. Uh, I wouldn't recommend doing that because you want to do everything through the git bash terminal, but here you can do it. So I'm gonna show you because it has a good visualization of it. So if you look at branches, you'll see that the master branch is the main branch, and that's just where we are. That is the default branch that everything starts on on. You can see that very obviously, if you open up any of your repose, you can open up, get bash, and it will tell you right here that this is the master branch. So by default were on the master branch and that makes sense. Okay, Now, if we want to make a new branch, we're going to take where we are in the project, clone it, and then all the changes we make on that cloned branch will not effect the main project. So if I click create branch, you can see here that this is where we're going. This is the main project, and we're going to shoot off from that. And then we can do whatever we want on this branch on this version of the project. And if we like it, we can do something called merging It Back into Master, which we will talk about merging and then merge conflicts later on. And that is a great way to do it. Because if you like all the changes you've made, you can just put it back into master. And you have the history of everything you've done, and you just put it together. And if everything goes well, then you have a working project with the changes you've implemented. And if you don't like it, then you can just check out master again and say, I'm going to go back to this and get rid of all the changes I made before because they're on a different branch. They don't affect me now. The reason that this is better than the second option we talk about is because you can make as many branches as you want with just a simple command. All you have to do is create a new branch with one command inside of git, and you have a new branch to work with. This is my preferred method of working when I am developing a website or video game or an application. Whatever the case may be. Whenever I start working on a new feature, even if it's something I know I want, I make a new branch for it. So if I'm developing a website and I have the landing page done and I want to start working on a new page for the website, I will create a new branch and then we'll start working on it. And this allows me to retain the master, all the original work and not have that messed with. That means that I know at this point back here my website is working perfectly. And then over here I've made some changes and there might be a few things that don't work properly. But at any time I can go back to here and it's working just fine. So that's an overview of branches, and at first it might not seem that intuitive. And that's okay. So with that all being said, let's dive in and actually start creating some branches and checking them out, and then I think you'll have a much better grasp of what they are and why you'll want to use them. 15. 7.2 - An Example of Branches: all right. We talked about branches really quickly, but I want to take a moment to actually show you why they are so awesome. Okay, so I've got ah website. I'm building for myself as a portfolio, and I am using git as the source control for it. Now inside of here, I have made new branches for each of my webs week. What pages that I'm using. So I've got a landing page photographer you teaching in a web development. Now I have branches for each of those, and I still have them active because I'm actually still working on each one. Now, let me show you what's really cool. When you're using a piece of software that is smart and you can use source control with it , it will know which branch you're on, and it will reload automatically when you change branches. So if I say get check out Master, it's gonna do that. Come in here and it's gonna reload because it knows that we have changed the branch that Ron and when it's changed all of the code, that's inside of it. And if we look at here, you can see that I only have three pages right here. I've got my about contact and index, and that's missing a lot of stuff. So if I come back and hear and I check out my most recent one, this Web death page, it's going to get all of the stuff that has been added over time, and it's going to then reload this and now it has all of this new stuff. So I have all of these pages that I've made all the work I've done over time, and I have access to all of the different steps along the way that I have been taking that I just have to check out a new branch, and I have access to all of that. So it is phenomenally easy to try out new things on your project. There's no risk at all. You can make a new branch jump into it, try to feature and switch back and forth completely, risk free, and it just takes seconds to type in those commands. It's awesome, and I use it all of the time. I wanted to show you that as an example of actually using branches inside of a project, because this is how I do it. And I'd also recommend you using branches kind of like this. Whenever you're doing something new, when you're done with the branch, you merge together, which will talk about and then you continue the process again and again. That is good design and development using source control. All right, let's jump into you making branches and figuring out all about them. 16. 7.3 - Creating Branches: Let's take a look at branches and how to make some and look at them so we know that we're already on a branch. Everything inside of get is on a branch. If you're not on a branch you're not inside of get, it's something has gone terribly wrong. So we know we're on master already. But are there any other branches that we get? Well, there's an easy way to find out. If you type get branch press enter, you will see that all we have is master, and this asterisk means that we haven't checked out. It's also in green, which helps you see that so we know that there's just one branch. Well, if we want to make more, the way we do that is by saying Get check out and we need to add something here to tell it that we actually want to create a new branch. If we don't add this optional parameter, then we will just be trying to check out a branch that already exists, so we don't have that yet, so let's make a new one to do that. You do dash, be so Dash B for Branch, and it's this is going to make a brand new branch. So we're gonna call this my new branch and you can see right here that we switched to a new one that we just called it, and now it says that were on that branch. So I say, Get branch. Now we can see that we're on the new one that we created. That makes total sense. Now. We have not actually sent this data up yet. If we tell you get status, we're going to see that we're on this branch and it says that there's nothing to commit. But there is something that we need to tell our repo that we've done. And that's that we have made a new branch. So if we go back and we take a look at this, I refresh this page for this is my second report. That's where we're supposed to be. It tells us that there's still only one branch inactive and emerged, so there's still only one current branch. Even though we've made another one, it doesn't show up yet, and that's because we need to say, get push, and it's going to tell us that it doesn't know where to push it. And that's because when you make a new branch, it doesn't know where it's actually supposed to go. So it tells you right here that you can set it, and this is exactly what I do. I say make a new branch when I'm ready. I say get push And then I just haven't tell me what I need to say. I don't have this command memorized exactly, But let's go through it and look at exactly what it does. So get pushed, Dashed asked Set. So we're going to be setting something we're gonna set upstream, and we're gonna talk about this more in future videos. So for now, just follow along and we will cover what each of these things means and how to actually make different repose available to you inside of your repo. It's a really cool feature, but not right now. Origin. My new branch, you press enter and then it's going to push up this data that we have made a new branch. You can see here that it goes to create a pull request. We're gonna talk about that in a little bit toe where we wanted to go and it says new branch has been created. Okay, awesome. So if I refresh this, we can see here that under here we still don't have any more. But if we got emerged, we have a my new branch. Now we're filtering by active and merged. So active means that it's actually ahead of the main branch. And right now, it's not because we haven't made any changes. This isn't that important? No, currently. But just remember that there are different ways to view branches, so these are kind of bad terminology. But basically, if you've been working on a branch, it will show up in active. If it's behind master, it'll show up emerged. Damn. So that's how you make a new branch. And that's how you said it to then be ableto actually send that data off to the server. So let's make a quick change and make sure that things are actually being done that way. So I'm gonna open up this word document. It's gonna take a second, and I'm gonna make a change inside of this word documents. Let's go ahead. I've made a change. Save it exit and open up. Get back inside, get status and you can see that now something has been modified, tells us what was modified. So what we need to do good at it. We're gonna give it a commit testing new branch feature and get to push. We've already set the push so we don't need to set it ever again. It's gonna push that up later, Riggio, and then press at five. And now you can see that it tells us that we are one ahead of master. And this is important because this means that the main branch is now behind other working branches. And this is important because you're gonna eventually want to merge branches or you're gonna want to delete them. You can see that's no longer emerged. Uh, because you don't want to have a lot of active branches at a time, you want to make a branch work on it, and then you bring it together with the master branch that you're always on the same workflow, so that's how you make a branch and you check it out. So in the next video, I'm gonna be talking about how to look at all of the branches that you have, even if you don't have them necessarily on your system yet 17. 7.4 - Finding All The Branches: So we have made a new branch. We've done something to it, and that's awesome. So if I typed get branch right now, you'll see that we have those two branches, but sometimes they'll be branches that you're gonna want but you don't actually have access to because other people have made them. And you haven't gotten all those changes yet, or you've just clone the repo when you don't have them all yet and they're not gonna show up if you just type get branch, you need to actually type get Grant Dash R and this will show all of them So you can see here that it's gonna show the upstream which again we're gonna talk about soon and the branch name and this is very useful. So let's look at this in a more useful context. I'm gonna go ahead and delete my second repo. We're going to come back to this and I'm gonna go into my repository and I'm gonna clone this again in bit bucket. You can come up here and just type in clone and you want to https. We're gonna copy this on my desktop. I'm gonna come in here and just paste it So I'm just copying my repo once again. So this time it's not an empty repo, so we know that. So if you open that up Walla, it's all there. Open up! Get bash! You can see that I'm on master by default. If I tell you, get branch right now you're going to see that I only have Master. Now we know that there are other branches So if we type get branch Dash are you can see that we have Well, now we have three and that's a little different. We have origin head which points toe origin Master. So there's always a branch and master is the default branch that you start with and head is pointing to master so so head you can imagine is the start of your branch So it's here you're pointing to origin and master. Now we see that we have my new branch, but it's not there yet, So to get access to it, we need to say get check out and then just type in my new branch. So once we check it out, we have access to it. So now we know that we have that branch right, I get status says that it's perfectly fine if I type get push. You can see here that everything is up to date all of the settings that has already been applied for this branch you get when you check it out. So this is really important. You're going to discover lots of branches like this, especially if people don't clean up their branches. So this is every single branch that has ever been made. Now there are ways to delete branches, and then you won't be able to see them in. Everything about that branch gets deleted. But if you download or you clone a repository that's been going for some time and and no one is there to up, keep it to get rid of branches that are no longer active or useful. When you do get Branch Dash are you might get a lot of branches and you won't know which ones are active unless you actually go to that repo and hopefully they have good documentation. They've got at least someone saying, If you want to work on this project, this is what you need to do, or this is what you should download from almost always it's gonna be master that you download from. There are other work flows. And if a repo has a different workflow, check out their documentation. Check out there, read me. That should explain how to use it and where the important branches are, which ones they use. But this is how you look at all of them. So in the next video, let's look at how you actually delete the branch. 18. 7.5 - Deleting Branches: So let's talk about the leaving branches because I think it's important to know that this is where it kind of gets confusing and difficult and also a little scary, because when you delete a branch, especially if you delete it remotely and locally is when you can really start messing things up. So if you believe the branch remotely, it takes it off of the server completely. If anyone has the project on their own systems, they won't get that change until they pull those changes down. But if it's just you and your server and you say I want to delete these branches locally and remotely, then you lose all of that. So you need to be very careful when you start deleting things. So those are the two things that you can do when you delete. You can delete on your own system and on your server wherever you're keeping them, so that might be get hub or it might be a bit bucket. Or it might be something else entirely like your actual own server that you could do so I'm back in my first report on Get Hub, So let's make a couple branches and then let's work on deleting them both locally and remotely to show you how that's done. So check out Dash B, my new branch. Okay, get pushed. And it tells us what we need to do is we're gonna set the upstream my new branch. So now we have made two branches and we've pushed them up to get up. So if we check that out really quick by saying get branch will see those right there. And if we were to go into get hub, we can look at our branches right here We have another branch and my new branch right there , so inside of get up. You can also delete branches and you can do pull requests and things like that. We're gonna talk about pull requests, but I would recommend doing, deleting and creating a branches again inside of the terminal itself. Inside of git bash. Try to do as much as you can inside of get bashed instead, accept pull requests. We'll talk about those and how you probably want to do those from the website. It's a lot easier. Okay, we've got these. Now let's look at how we actually delete branches. So we first, let's look at believing them locally to delete them locally. It's actually not that hard. There are two things that you need to know first is well, I guess three things. How you do it is your type. Get branch. And then you say Dash and it's gonna be either D or it's gonna be de so it could be lower case or upper case and lower case actually means delete makes sense. Upper case d means more like delete forcefully. The difference between these two is that the lower case D is going to delete this, But it's going to give you a warning. And it might even stop you if the branch you're trying to delete is ahead of master. And that means that if you've been using this branch for a while and it's actually ahead of master, it's not gonna just delete it. It's gonna give you a warning message, and it may even stop you, and that's a good thing. But if you know that you don't want this branch because it's a feature that you were trying out, it's just no good any more. Then you're gonna want to do capital D to just get rid of it and that's what we'll do. So we'll go ahead and just do lower case, do you? We don't need to do delete force because we're not ahead of this and we can't delete the branch were on. If we try that, it's going to give us an air. Obviously, we can't delete the branch wrong. Okay, So if I press up arrow, I can go back to the last thing I typed. I'm going to say, let's believe my new branch instead. So if I type get branch, you can see that this is gone. And even if I push this up, it's gonna tell me that everything is up to date because it iss we've Onley deleted it locally. It's still right here. Nothing has changed there, so we'd leave it locally. It doesn't get rid of it remotely to delete something remotely. You need to do something that doesn't exactly make sense. And tactically so just go along with me. Here this is get push. So we need to actually push these changes that we're making is gonna be dash dash, delete. Now we need to say the remote name and most of the time is gonna be origin. And we know that because that's what we actually typed in for this branch. So its origin and then the branch name and the branch name Waas my new branch. So we're gonna push that. We're deleting this branch, so it's gonna wipe it out from there, so we can then just go back in here, refresh the page, and now it's gone. We look at all branches, it's gone. It is nowhere that you can be found. It has been deleted completely. So there are two ways to delete you can delete locally and remotely and doing this again. I caution you to be very careful. Deleting the local branch is perfectly fine, deleting them remotely. Although important, you want to make sure that they are no longer needed. If you type, get grand stashed are we're not going to see it because it's gone and sometimes you'll have a lot of branches, and that's okay. You don't wanna have to money that it becomes impossible to read, and you want someone to be proving those branches. But you also don't want to get rid of a branch that's still being used by someone you lose data that you just can't get back that way, at least not very easily. But that's how you delete branches locally and remotely. So in the next section we're gonna talk about how to actually put branches together. And that's called merging. Along with merging. We get merge conflicts and those are not as fun. But I'll show you an awesome tool, and I'll show you the best ways to handle merge conflicts. 19. 8 - Git Pull: So I want to talk really quickly about one of the git commands that we haven't touched on. And that's because up until this point, we haven't really needed it. And that is get pull P u L l. This command will go out to the server and pulled down any changes that have occurred. So if I pressed Enter right here, it's not going to find anything because I'm the only one using this repository and any changes I make get pushed. And they're already on this computer now where this concomitant handy even if you're the only person working on it, is when you have multiple machines and I do quite often. So if I am working on one machine and I push changes, if I come to my second machine, they're not going to be on there. I have to ask for my repository to give me all of those changes, and that's what get pull does. So when you have changes in the server that aren't on your local machine, you have to do that. Now get pull is actually doing several different things, and I want to show you this, and we're gonna do this by going into bit bucket and we're going to go to branches. And we're going to create a branch because I need to do something that is here, and that way I can pull it down. We're gonna make a new branch. This is gonna be called Test Branch. I'm gonna create it. And now this has been created on the server, not on my local machine. So, actually, let's go here really quick. You can see that. This is saying get fetch and get check out Test Dash Branch because I added the space there as dash automatically. Now, fetch is one of the things I'm going to talk about here with a quick So if I say get full, it is going to find that new branch, pull it down and add it to my system. You can see it's right there. Now if we come back here with quick branches and I go to create branch and I say test branch to create it, come back into here and I say, get fetch. It's gonna kind of do the same thing, so it's gonna find that branch is gonna add it. It's gonna look like it did the same thing, But these are two different commands, and that's because get Pole is also doing a merge. And that is when you take all when you take stuff from one branch and putting it into another and you're combining those changes. So it is doing a get fetch, which is just seeing what has changed. It's like looking into a room after someone has decorated it. You're just seeing what's changed. You're not doing anything with those changes yet. When you do a get fetch and then they get merge, you are then merging into that. You are changing those two things together and get pull is a fetch and emerge in one command. Now there's a lot of debate out there about whether you should be using fetch and merge or just pulled. And I will tell you, in my experience, get pull is perfectly fine. It is quick, it's easy, and it does everything you needed to do very, very rarely. In fact, I've never had an instance where I needed to do a fetch and merge. Will you need to do a fetch and merge, and that's because most of the time you want to pull down the changes, and you want to integrate them into your project already. Very rarely will you want to just see changes and then knit pick, which changes you want to take into your local copy. Most of the time, you want to have your local copy and the server copy match up exactly. It just makes it easier all around, but that is get pulled. In a nutshell. There's not really much more I can say, because we need to talk about merge conflicts and we will, and that can come up when you do it, get pull. But once you know how to deal with those, that's really no problem. And I would just suggest, always doing get pull. It's faster, easier and, in my opinion, a lot cleaner. So that's get pulled. It's important, especially once you start working with multiple people. Multiple repose for three pose all that stuff, which we're gonna talk on. Uh, it's important to do that every time you sit down. If you start working on a local copy and the server is already ahead and you try to do it, get pole. You're gonna have a lot of issues, so Every time you sit down, type, get pulled, it will save you a lot of frustration and a lot of time. Do that and you'll be good to go. 20. 9.1 - Merging Overview: Now that we've started working branches, we have to figure out how to put them back together because it's awesome that we can have several different branches, test out features and all of that. But if we can't bring them back together than we have a problem, so when you have multiple branches and you want to put two of them together, it's called Merging and the command is just get merged and you set the branch you won't emerge with. So the syntax itself is actually pretty easy. Understanding how it works and then resolving the conflicts that come up are much more difficult. So let's just talk about it in the general overview right now that I'm going to go through regular emerges and then merge conflicts and the software that you want to be using when you do that to make it so much easier than if you didn't have it. So I'm already kind of explained what merges are, but this illustration right here is really good as well. So here we have what's called. They call it a common base, but this is your repository at the point right before you make a branch, so this is master, or it could even be a different branch. It doesn't matter at all. You can branch from a branch from a branch from a branch. It doesn't really matter. Branches are just copying whatever you're on taking it and then allowing you to do something in this new branch. So you can imagine this is master or anything else. So you here and then you merge off. So this is becomes a new feature of some sort. This is the original. So we're gonna call this master still, So it keeps going along. You can keep working on master's someone else could be working on a feature. And then when you're ready, you bring those two together. Now, if all works well and perfectly, which it rarely will, you won't have emerged conflict. Things will just line up. All the code will come together and your project will be working perfectly. Now that's a pretty rare thing. And that's because when you make emerge, it checks for all of the differences that have occurred from the current branch and the feature branch that you are emerging. And oftentimes, when you're working on a new feature, you go back and you change some of the original coat. Some of the original words, anything, anywhere in the original document if it is changed in the new branch. So this one over here, when you merge them together, you have to tell it which which ones you want to save, which ones you want to get rid of, because get conduce a lot and it when you it'll auto merge a lot for you. But sometimes it just doesn't know if you want to keep this line of code or that line of code. So it's gonna tell you there's a conflict, and then it's going to tell you to resolve it. It'll tell you which one's which documents you need to go in and check, which is great. But then you have to make those changes. It will tell you exactly where they are, and I'll show you how to look for them and find them really easily. And so it's really nice that get does that. But then you just have to go in, choose the changes. You want to keep change, choose the ones you want to get rid of hope that they are correct, and then you add it all together, commit it and push it and you're done. So in theory, it's not that hard. In practice, it becomes a little more difficult. But my goal is to make it as easy and as simple as possible for you because you're probably going to run into it quite a bit. So let's look at how to handle it and the best way and the best software to use to do that . 21. 9.2 - Merging Without Problems: all right. I'm here in my second repo and in this video, let's just look at merging without any conflict. So if everything goes great and you don't have to go in, let's take a look at how that works and what it looks like. So in here, I've got my master branch. I'm going to great a new branch. I'm just going to call this new merge or a new it doesn't matter. Gonna call it new merge. I'm going to set up the bush so it knows where to go. And then what we want to do is specifically at this text document. Now, I've been adding in Microsoft office documents, but you don't want to try to use those in this example. There are third party tools that you can use to use git and source control with Microsoft Office. But I will tell you that they are not documents that can be edited with git easily. So what we're gonna do instead is use this dot txt document. This is a plain text document. So if you don't have one, make sure you add one, because this is what we want to use. You're not gonna be able to do it with these other ones with these Microsoft office ones that we've added because they are binary files. They're not just text files. They have a lot of additional information that get I can't read as well to show you where the changes have been made. So make a normal text file and let's go with that. So I'm gonna open this up, and right now it's blanks. I'm going to say this line it was written in a a new branch. Save that. I'm gonna come in and I'm going to add that commit it edited, Doc, I'm gonna push that in. We do that, I'm going to check out Master. And then if I open this up, you can see that it's empty. And that makes sense were on two different branches. One of them I've written in one of them. I haven't. So what we want to do is be on the branch that you want to merge into, so most of the time, you're gonna want to be on the original branch, whether that be master or develop, or whatever it is you want to be on the original one that you branched from because what you're gonna say is a get merge and then type in that branch name that you want to merge. Take all the stuff in the other branch. Put it in this one. We're gonna call new, merged, get merged New merge, press enter and you can see here. That is a new text document. Has one file changed one insertion. So I come in here. This was written in a new branch, but it is now in master because we have emerged to them successfully. So if I had that well urged different Brinks and I can push that up that is merging without any conflicts. It's very simple. It's quite straightforward. And there's very little that you have to do besides type in that Get merge. Just remember that you need to be on the branch that it came from originally. If you're not, you're probably gonna have some issues because you're gonna be merging a branch that you don't want in 21 and it's just gonna cause some issues. Now, if we type get branch, you'll see that new merge is still here. That's because when you merge it, it doesn't go away. but good practices that once you're completely done with the branch, you then get rid of it. So then we would want to say, Get branch daft D new merge and get pushed back staffed elite origin, new merge. So we delete it from our local system and then we delete it from the server. Now it's not here, but the changes are so we have those. We've made the change. We've merged it. We've cleaned it up. You're all set now. In the next video, let's take a look at merge conflicts, because that's what you'll be dealing with a lot of the time. 22. 9.3 - Merging With Conflicts: all right, we know what emerge. But what happens? We have emerged conflict. So the first thing to know is that emerge. Conflict occurs when you've got two branches that have both been changed and you're trying to put them back together and get just doesn't know which one you want. Most of the time when you merge, get will actually be able to handle it by itself. It doesn't need any human intervention. And that's because it's going to take the most updated branch and merge it in there. So all of the most recent changes will be saved because it's going to think that you made this change more recently than the older branch where that line is that so you want this new one, and that's how that works. But if you've got two branches you've worked on both of them, and then you're trying to merge them, you get a conflict because it doesn't know which one you actually want, because both have been changed. So to do this, let's test that out. So first we need to make a new branch. Get check out, uh, call this merge conflict branch. We need to push this up so that it's there. Set extreme. Okay, now, once this is done, let's open up this new text document and let's get rid of this line. I don't like this life, so just change it, that anything else and that will be fine. So if you check out status, obviously it's been changed. So we need to add it in the midst and push it up. So you make those changes, you save it to your server. Everything is all good Now, once you've done that, what you need to do is go back into master check out master or whichever branch you merged off and then opened that same document and you can see that this line is still here. So let's change it to anything else. So, uh, computers are rad and get is, so save that we're gonna have it committed and push it. And I'm just doing bad commit messages in this in this course. But I hope that you do realize you want good commit messages. Don't follow what I'm doing here. So that makes two branches that have been changed. Now, remember, you need to be on the branch that you want to merge into so our own master, we want to merge the branch called Merge Conflict. So let's let's do that. And now you'll see that auto emerging conflict right here merge conflict in the new text document, automatic merges failed. And you can see here that we're on master and were emerging. And it doesn't tell you which one you emerging from. It just tells you that your own master and you're merging another branch into it. Now, if we type get status, you're going to see that it says both have been modified. New top new text document dot text So this is great. It tells you exactly what has been changed. And if you want to abort it, you can. You need to either aboard it or fix the conflicts and then run. Get commit. Now if we open up new text document just looking at it by itself, we'll see that get has actually marked where the conflict is that. So here is head and you follow from head to these dots to these dashes here these equal signs and everything in between his head. So this is the master branch. This is the one that we are on. This is the one that were coming from. So I don't like this line is what we changed it to on merge Conflict Branch. So from the equal signs to the merge conflict where it actually does with the branch name that is the other branch. And this is the master branch, the one you're on. So that's how you read that. But this is, although helpful, not that helpful. Once you start working with larger documents, what you want to use is software that has merge conflict integrated into it. And that is where visual studio code comes in, something we've already downloaded. So it's exit out of here and open this up with visual studio code. Now, yours might not be on their by default. You may have to go in and choose another app or find it another way. Go and do that and open it up because then you're going to see that this is beautiful and shows you the changes and it tells you where they're from and will change them automatically once you're ready to do that. So we have head. This is the current change and incoming changes right there. So you can accept the current change except the incoming, except both and compare. So if you compare them, it just brings them up like this so that you can see them side by side. So from here you can choose one of those three except options. You have to accept one of the three, save it and then commit to fix this merge conflict. So let's go ahead and accept the current change. Visual studio code will take care of getting rid of everything that doesn't need to be there, save it, exit out. So now, even if we type get status, you see that? It says that there still both modified. So we've saved it. We've changed it, but we need to say at it. Then we need to commit it. Merged branch. So we've merged it, and now you can see that there is no merging here anymore, and that takes care of merging with emerge conflict. Now, if you try to merge without making those changes, you're going to get an error. And it's going to tell you that you need to choose which ones you want to keep, which changes you want to keep. And then save it so that get can then do its thing. Once you do that, it works just fine. Then you add it and push it and you're all set. So that's emerge. Conflict Using visual studio code. It is so much easier toe handle. Merge conflicts, especially once you start having large documents because you can see visually where they are, and it will automatically take care of making those changes. I've had merged conflicts that have dozens of lines of code, if not more. I have toe scroll through it, looking to see where exactly head starts where the middle is and and finding that without using visuals to your code. Because I didn't know about it at the time, and it is awful. So use this software every time you get emerge conflict that you can. It will make it so much easier and quicker. But that's merge conflicts in a nutshell. That's how you handle them. They don't have to be that scary. You can handle them, you could make it work, and you can do it like a boss. The next section we're gonna talk about forking and what it is and why you want to know how to do it when you start working with source control 23. 10.1 - Forking Overview: When we begin talking about forking a repo, you might see something that looks kind of like this, and the images kind of looked like branching. And that's because it's branching, but not your repo. So if you find a repository on get hub that you like or that you want to contribute to, how you do that is by forking it and that will basically take their repo. Whichever branch that you choose, it will take it. Make a brand new repository for you, which is what this is kind of like what a branch does, and then you will have access to that repo and everything inside of it, and it becomes yours. And that's kind of the beauty of open source. Is that everything that's open source out there you have access to. You can go and look at it. You can go and make it your own. You can make any changes you want, put it up and then allow other people to do it. And that's how awesome projects get made. And that's what get was made. Four. So forking a repo, you can take it, make it your own and then through other means like pull requests. You can then contribute back to the original one. Or you can go and make the project completely your own. It's totally up to you. So what that kind of looks like is this You have a repo that you like. This is called Cool Repo, and then you fork it, it becomes over here, and then you take that one to your local machine. But you can also pull from that real remote report the original one as well. This is the best way to work. So I'm going to be doing this over the next two sections. I'm gonna show you had a fork in this section, and in the next one, I'm gonna show you finally, what origin means and how to change that. And this picture has a really great example of that. So you fork it, you get to then use that forked repose, make all the changes you want because it's yours. And then you can push your changes to that remote rebo through pull requests which will get into as well so we're going to be covering ah lot over the next couple of sections. And a lot of this is based around teamwork. If you are doing a product completely on your own, you will not need to fork. You will not need to do any pull requests. All of that stuff will not be around because it's your rebo and you're not using anyone else's. So if you want to just do stuff on your own, you already know pretty much everything you need to to get working and anything you don't. A very quick Google search will fix that for you because there's a lot of things that get conduce you. But this course is designed to just get you up and running as quickly as possible. That being said, you'll probably end up forking someone's repo, so this is important to know. With that being said, let's dive into it. 24. 10.2 - Forking A Repo: the best way to learn to fork is just to do it like most things will get. So they have a trending page, which is pretty cool, so you can see on get have all of the coolest repositories of the day. So I was going through here looking for one, and I found one that looked pretty cool. It's called pixel. It's a retro game development environment and python. Now we're not gonna do anything with this besides, fork it, so don't worry too much about it. What we're gonna do is just find any repository. You can use this one or you can use any repository at all. It can even be one of yours if you want. It doesn't matter. You can go up to this button here, and this is the fork button. So you fork it and what this does is it's going to take the entire repository and copied over and make it yours. You can see here that this says it's mine, but its forked from here. Now I can clone and download this, but I can also see the entire history of commits that this group or team has made. I can see everything about it, including all their branches. They only have to right now. And I get there, Read me. I get everything when I fork there Repo. But now I can go in and make this completely my own by changing it in whatever way I want. So that's basically what forking does. You do it in the software in the website that you want to do it with. So now let's go and look at bit bucket, so it's a little bit harder to do it here, but you still can. So if I wanted to fork a repo now, this is private, so you can't fork this one. And since you can't search on bit bucket for other repose, it's a little bit harder. But I'll show you where to do it. In case you ever come across one, you find the report that you want, you come over to the plus button, and then down here, you just fork this repository. You give it a name, which you'll want to name it a little bit different. So, uh, website forked and I forget. So this is gonna do the same thing that didn't get hub. It's gonna make it now is already my repository, so its not making any really big change there. But the cool thing is that this allows everyone to work together. So now this is forked. If I come back and I look at this, you can see that it's in here and that's Ah, so you can fork any repository that you confined that's not private, and then you can start working with it. So once you have a repository fort, you can go and play out of that as much as you want. But what if you want to contribute or do something with the original repository as well? You probably can't just push to it. They're not gonna allow that. When you fork a repository that becomes yours. And unless someone is authenticated to push to a repository, you're not gonna be allowed to do that. So if I came back to this person's repository, I couldn't push to this. Even though I have forked it, they're not gonna allow that. Instead you do something what's called a pull request. So if we look at this, you can see that they actually have a pull request right now and So this person has forked the repository, made some changes and is doing a pull requests, which is basically a public push. That's the original group can look at, bring in and test before they actually completely approve it. So that's really cool. And I'm gonna show you how to do a pull request in the next video. 25. 10.3 - Pull Requests: so it pull requests like I explained is basically emerge from your forked repo into their original repository, and you can do it from specific branches and you can choose which branch you're going from and going to, and you can then set it up. And the original author of the original group will then look at it and they approve it or decline it. Now, when you're working with a group, this is how you're going to do most of your work. You will have one central repo, and everybody on the team will fork it. And then, once they are done working on a certain branch of certain feature, whatever the case may be, they will do a pull request or a PR into one of your one of the central repository branches and who's ever designated will check that out, make sure it works, make sure it doesn't break anything and then approve it and emergent. So how do you actually do a pull request? Well, you can do it from the command line, but this is one of the few things that I would not suggest trying to do because there could be a lot of conflicts, and you want to be able to see these in get hover bit bucket or whatever you're using and it makes it a lot easier. So I'm gonna go through get hub and bit bucket because they're both a little different. So the thing that stays the same is that you need to be in your forked repo. So here I am, in the repository that I forked and I haven't done anything yet. But that's OK. If I come in to pull requests, you can see that there's nothing here. If I click new pull request, it will set this up. Now. I'm not actually going to submit this because, well, for one, they're identical, so there's nothing I can do. But I also don't want to do at random PR to this repo. It wouldn't make any sense. So what we've got, though, is the option to choose where this goes so you can see that the base fork is this person here. But then you've got all of these other people who have also forked it so I could choose to go into any of them that I want. I can choose where it goes so which fork which reports going to? And then I choose the branch develop or master. Now I'm gonna talk about good practices using source control. And this is one of them. You never want to do anything directly into master. Uh, I'm gonna talk more about that, but just trust me. Imagine you have a live website or a video game that people are playing. You never want to directly change the source code that is running on people's machines. Instead, you make another branch and you go into that and thoroughly tested before you, then push it out to everybody. But I'll talk more about that a little bit. But here you can choose between these two branches because that's all there is now. If I made more branches, I could choose which one I'm coming from. And you can choose other ones here. But I'm on minds. That's obviously what we want to do. So if I am made a new feature here, I would choose that branch and I would choose exactly where to put it. I'd be putting it into their develop and then I would say, send off this PR and let them look at it now in Big Bucket. It's fairly similar. You come in here and what you need to do is go to pull requests. So I'm in my forked repo and you do a create pull request from either of these two options here, and it's gonna be very similar here. I can choose where I'm doing it from where it's going. So it's one of these two. You give it a title, you give it a description and you see if there's specific people who will review it and then you actually create the pull request. Now, this is something that's really cool, and I'm I'm sure get up does it's well, we just can't look at it right here. You can see that all of my commit messages get automatically added when I do a PR, and this is another reason why you want good commit messages. They can come in here and look at this and see everything I've done, and I can add something on top of this and just say yes. So this is what I've been working on here. Some of these commit messages you could look at, but this is the overall summary of this branch that I've been working on, and then you create the pull requests and you can see who's been working on and everything which is really cool, and then you send it through, and that's what a PR is. When you actually start working with PR's, you will want to get used to this workflow. Sometimes it can take a very long time. Sometimes groups are on top of it, but once you put that PR in, the only thing you can do is to cancel it. You can't approve it. You just have to wait for them to actually look at it and say, Whether it's going to go in or not, you can always take it back If you find there's a problem or you don't want to do it anymore, that is still on your end and in your control. Now, with all this being said, and with this being explained now, we can then go into talking about what origin is and how we can actually start adding different up streams to make working with forked repose a lot easier because currently, if we were to clone are 43 bone, we still want to have a way to know what the original repository is doing. Otherwise, the only thing that we could do is get changes for that we've made and push changes to our repo that we've made. But we want to be ableto also check what the original repository has been working on because we might want to be pulling down there changes as well. And to do that we add another upstream, which is what we'll do in the next video. 26. 11 - Remote Servers: So once we have a fort repository, we need to figure out how we can actually pull from this repository and our own inside of the terminal. So let's jump into it and check that out. Let's clone this repository that we've got. So I'm gonna take this Copy it. Coming to my desktop type would get clone, since it's not there for get hub and Paste This. It will take just a second Daniels, because this is kind of a small project, and now let's open it up and get fashion here. So if I type get branch right now, there's only the master branch by type. Get branch Dash are you can see that there is a develop in there as well that I can pull, but they are all at origin now. We haven't really talked about origin, so let's talk about this now because this is how we're going to be able to pull from multiple repositories. Origin is the word that they have given for the remote server that these branches are pulling from. It could be any word, but here origin makes a lot of sense. It's the original. It's where it comes from, so if we want to add more of them, we can. And we can check this first by saying get remote Dash V and this will actually tell us exactly where these things were coming from. So you can see that these are my project. This is fetching and pushing from this location, and that's make sense. That's where we want to be doing right now. So if we want to add a new remote that is not origin, this is how we do it. We say get remote. What we're gonna do is we're gonna add one, and then we need to name it something. Traditionally, it's called up stream. But if you had several of them, you can name them. Whatever you want upstream is what will go with here now. To do this, we need to get the address of the repository that we want to add. So let's grab that. And that's gonna be from the original repository. Don't click on Clone here and copy this address right there. Right Click and paste it inside. And now I have added that remote we can check by typing and get remote. Dash V who one more time and you can see that now we have a new remote. This is called upstream, and this is the address that it's at. So origin is ours. Upstream is the one that we have forked from, and this becomes very powerful. Now, when we're working, we can say get, pull and say where we want to pull from to get those new changes from different repositories, not just the one that we're currently working in, which is awesome. So when you start saying pole and when you start doing some of these commands, you actually want to specify where you're doing it from and there are a couple of ways to do this. So if I just said get pull, this would be pulling from origin because that's how the repository is normally set up. So that is the same as this. Get pulled Oregon, specifying specifically origin. Now, if I wanted to specify upstream, I would just type upstream, get pull upstream and you can see that we have found two more branches. So it pulls down everything on there. And if you have several that you want to update at once, you would say, get full dash. Oh, uh, get pulled, Dash, dash. Oh, and this would fetch all of the remote that you have all at once, which is great. Now, this becomes a little more confusing when you want to start switching around branches. So if I say get Branch Dash, are you can see that we have origin and we have upstream, but we have them named the same. We have an origin develop and we haven't origin. We haven't upstream developed in an upstream master, an origin master. Now we're currently on origin Master, because that's the one that you always start, so we can always come back to that. But to get that origin develop, we can't just say get check out develop because there's more than one upstream developers here as well, so we can't access it. So how did we do that? There are two ways. First, you can come in and say, get check out, type in the remote name's origin and then actually put in the slash develop. Now, this will put you in what's called a detached head state. So basically we have moved from the most recent commit into one previous, and we can make changes here and it's not gonna mess with anything and we could go back and check out any commit that we ever want, which is a really powerful thing, and we can talk about that later. But we are in develop. So if we wanted to, we could say Get check out Dash, be to make a new branch and call it developed And this would take origin develop which we're currently in, and make a new branch cult developed so that we could just say, Get check out developed at any time. But let's not do that. Let's go back to master. We have to develops and we need to be able to access them separately. So the other way to do this is by using something called the track feature. So if I say get check out and due to Dash is called Track, we can say and specify origin slash develop now Branch Develop says it's set up to track remote branch develop from origin. So we're saying we want to track origin develop with this branch called Developed, so we can attempt to do the same thing here and type it out and just say upstream. But that's not going to work here because they have the same name. We can't do this exactly. Even though we've typed upstream is going to try to create a branch called Develop. But we already have one locally. So instead we need to make a new branch, name it something different, but tell it where to pull from. So to do that, let's go back inside of here. We've got this still here, but now we need to say, Get check out. We need to put Dash B. Let's get rid of the track abortion and we need to give it a name right here. So let's say upstream develop now. We have created upstream develop and it is set to track from the branch develop from upstream. So if we do it, get pull. It's not gonna do anything because they're already up to date. But now this will allow us to have this branch honor system named something specific but pulling from a different remote and this is very powerful. It allows you to have multiple repositories inside of here and not have toe have different folders, but all from the terminal. And that's awesome. It gives you a lot more flexibility in a lot more power you can pull, you could merge. You can take what other people are working on in a different repository. You could have Ah, 100 different repositories in here if you so desired. Probably a bad idea, but you could. It opens up a whole new world of possibilities of working with multiple branches, working with multiple people and having lots of different forks all over the place. But having in one repo that you can easily pull into emerge with. So that's how you do that, and that's what origin is. It is a remote pointing. Remember, get remote Dash V. It is just a remote that is pointing to an address. You can set them to be named whatever you want, and you can have them pointing to wherever you want. It doesn't matter. You could have them pointing to different websites. You could have them pointing to anything that you desire, as long as it's going to be able to get and receive get calls. So that's what origin is. That's how you change it. That's how you use forks. And that's most everything that you actually need to know toe really start using git that covers really the basics and a fair bit of advanced stuff as well. And really, once you begin working with git, you'll become much more fluent and you'll get much faster at it. You know, feel much more comfortable after you make these calls a couple of dozen times and you get used to it, so I'm going to wrap this up, and then I think we'll be all done. 27. 12.1 - Git Ignore: one awesome and very important feature inside of git is that it can have a file that tells to ignore other files. This is called a get ignore file, and it allows you to put files into your folder and not have them be added to the repository. And this could be useful in a number of situations. There are two that come directly to mind. The 1st 1 is that you were adding sensitive information like a P I keys or business information, and you don't want that in there, but you still need to be able to access it for some things. So you put those specific files in the get ignore, and they are not added to the server there Onley stored locally. And that's perfect. The second thing is, when you use some software like visual studio or other software that compiles it can create a lot of excess files that you don't actually want to push to the server they air on Lee used locally, and they're on Lee created when it's run on that system. So you want each system that runs it to create those folders for itself full division files and that is very helpful, saves a lot of space, and it makes it a lot easier to clone projects. So I'm gonna show you how to create a dot get ignore file and then also talk about how to auto generate some depending on the software that you've got. So we just need to add a text document, and we need to select it all. And if you're on Windows, you need to do this exactly on Mac. I'm not sure if you have the same error you need to say dot get ignore. And you need to add another dot at the end. Otherwise, it's going to give you an error of that. It can't be a blank filing. If you do this, it will give you this warning. Say yes. And then it will delete the dot at the end and you'll be all set. So we open this up and inside of here. There are guidelines for how you do it. The only ones that you need to know right away is that the hash symbol is a comment. Empty lines are just ignored, and the asterisk is for all types that you put after it. So if you wanted to ignore all power point files. This is how you would do it. So ignore all types of one file. You can ignore a single file by putting in that exact file we could say test to or test one dup x l s x, and that will ignore this test. One file, except that if a file's already been added to get, then this get ignore will not work for it. You have to actually remove it from get first, which you can do by finding the command very simply, uh, if it's already in there. But if it's not in there, if we have a 2nd 1 that we added in, then it wouldn't add it here. You can also ignore directories, so we don't really have any inside of here. If we did, we could put a slash and we could say, uh, new folder and then ignore everything inside of there. And those are the kinds of things that you can do. And for the most part, those are all the things you need to know how to do. You can ignore directories all kinds of one file and specific files, so that's super helpful. So if we do this like I said, if a file is already in there, it's not gonna work. But if I save this and we load up, get Bash, let's take a look. So we've added a get ignoring. What's at this in added get ignored file? No, we have ignored inside of here all power point files. So let's add a new power point and go to get and say, get status. It doesn't show up. Normally, when you add a new file, it tells you that it's untracked and you need to add it. But here, it's not going to say that because we are ignoring that and we also ignoring a specific dot test to file. So let's create a test to Microsoft Excel and let's make a test three just to show that it is actually working properly. Okay, get status. The only one that shows up is test three, so you can see that works exactly the way we want it to, which is awesome. Now let me show you one more thing. When you are using software, you need two. Probably have it. Auto. Generate the get ignore template. Now you can search for it online. There are actually repositories that people have created that have templates of pretty much all of the big software out there that you can just download and throw into your project for adopt getting north. And that's cool. But if you don't want to do that and you're using something like visual studio, you can have it out of Generate that give ignore file, and the way that you can do that is when you are inside of there inside of your project, wherever that is, every software is going to be different, and I can't show them all to you because there's so many. If I come into the source control home section here, you can see that it knows my repositories that I have on here, and it can I can ADM. Or I can connect things. I can do all of this from here, which is really cool. But what I want to do right now is actually coming here to the settings, the repository settings and I can have it auto generate the ignore files, so there's already one right here because I've already generated it. But if this wasn't here, I could auto generate this entire file? And this is a lot of things to ignore that you don't want to even try to do yourself. So when you're using software like this, be sure toe auto, generate the dot, get ignore. And that's what I've got for you on that section. It's very helpful, very useful. Don't forget about it, especially if you are using important documents that you don't actually want on your server , but you need to be able to access locally. 28. 13 - Best Working Practices: The last thing I want to talk to you about is best developer practices. When using source control, just like everything else that you do, there is a good way to do it and there's a bad way to do it. And then there are lots of ways in between that are okay and will work, but not the greatest and slower. And you get the idea. So let me give you the best way to use source control. At least for most projects. There can be some variants, but for the most part this is what you're gonna want to dio along your master branch. This is the final working no bugs product. If it's a website and it's deployed from, get a bit bucket wherever. This is something that you only update to when you are absolutely sure it has been thoroughly tested. If it's a product that is in use anywhere, you only push to master. Rarely you never push directly to master, really, ever. In any circumstance, it is always a bad idea. Master is something that you Onley go to after it has been tested and so that is where these other ones come in hot fixes something you can do if there's a problem that you need to get out right away. But most of the time, what you're going to do is have a feature and you're going to work on that. And it's going to then be pushed to develop and these names can be changed. But for the most part you want develop, develop is one that is pushed to from outside your team. If someone has forced the repository or from in your team, if you are merging so you would merge a certain feature in to develop and in develop you check the merge conflicts. You make sure things are still working fairly well and when they are, you push them to release and inside of release. This is where they get tested thoroughly from outside inside automated testing. Whatever your company is doing, whatever you're doing, this is where you do that. When you were sure that everything is great, you push it to master and you also push it back to develop. And then you continue that cycle on and on. You never push to master. You always merge into develop and then you check and you check and you Onley move to master when you are either fixing something that is broken and didn't get found or after it has been thoroughly tested and everything is good. This is the best way to be using git and source control. So if you're on a team, you want to make sure that everybody's on the same page. I had a project in college where one of my classmates decided that since he was the owner of the repository, he would just push directly to master. And, of course, it happened the night before a big review and broke everything. It is always a bad idea to push directly to master unless you're working on a small project that's not live and it's just you and you don't wanna have to have multiple branches for something that's fine. But if you're in a group and the team never pushed to master, go through this staged process, it will help you become a better developer and how you think and how you plan and how you get your product out there. That's my encouragement to you, and I hope that this process will work well, and with that that's all I have to teach you about get and source control. You are now ready to go out there, create your own projects, fork some repose and do some damage. 29. 14 - Errors & Issues Intro: Well, if you found this section, then you're probably having some issue with git in source control. And that sucks because problems with source control are frustrating and sometimes they can take a really long time to figure out. So here is my plan, and I think it will help all of us when you encounter a problem or run into some kind of error. Leave a question on that video where it occurs, B s specific as you can and let me know what the problem is and what machine you're running in all of the details that you can get because I will update this section with more video responses to specific errors. My hope is that this section will start to encompass all of the errors that you can encounter and the solutions to them. This document will also be available, and I will update it as we go along. Look for a link to this in the first section underneath the first video somewhere. So with that being said, take a deep breath. Try to see if your problem has already been solved here and if not, let me know what it is so I could help you fix it. Thank you very much.