Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
The course shows how to use Git, the popular open-source version control software, to manage changes to source code and text files. Using a step-by-step approach, author Kevin Skoglund presents the commands that enable efficient code management and reveals the fundamental concepts behind version control systems and the Git architecture. Discover how to track changes to files in a repository, review previous edits, and compare versions of a file; create branches to test new ideas without altering the main project; and merge those changes into the project if they work out. The course begins by demonstrating version control in a single-user, standalone context, before exploring how remote repositories allow users to collaborate on projects effectively.
In the last movie we created a GitHub account and created an initial GitHub repository, and that's on the remote server that we can then connect to. We now need to tell our local repository information about where it can find the remote. When we set up the remote repository, GitHub came up and offered us some helpful information. Go ahead and leave that page up, because we're going to want to come back to that. But first I want to switch over to your command line and make sure that you're inside the root of your project already. If not, you'll want to navigate into it, and from there let's type our first command which is git remote.
So git remote will come up and give us a list of all the remotes that it knows about. It doesn't know about any right now about. So it doesn't return anything. The git remote works a lot like git branch does. We use git branch to see all the branches, git remote shows us all the remotes that we know about. Now the next command we want to do is git remote add. So git remote add will add a remote and then what we want to put in. Don't type this part. Just wait for second. Git remote add and then the alias for what we want to name our remote followed by the URL of where it can find it.
Let's go back and look at that and GitHub page again, because it tells you the name, the URL, where you can find it. That's what this is right here. So you can just copy and paste that, and it suggests the default name of origin. Now this is an alias. You can call it whatever you want. Let's say origin and then that whole long string pasted in. This will create a new remote called origin that points to that remote server at that URL. Now we don't have to call it origin. By convention, typically, you call your primary one origin, that's what most people do.
But if you want you can call it GitHub let's say. I'm going to go head and call mine origin just so we can stick with that default convention. Now I do want to make sure that I call attention to the fact that I'm using a URL which has my name in it, because that's for my GitHub account. Of course, for you, you will want to make sure that you are using the one that has your GitHub account, and from now on if you're using the exercise files where we have a remote defined, you will want to make sure that you take a second to change that remote to point to your GitHub account, not to mine.
So that's very important. You want to make sure that you customize it so that it's looking at your remote repository, and not trying to find the one that I created. Now it's worth noting that you can have more than one remote for your project. We don't have to just have this one remote server out there that we are connecting to. You can have several different ones and in that case you would definitely want to give them each a different name. So now lets try out git remote command again. Git remote, and this says ah, here is origin. Let's do git remote with the -v option after it, that will give us a little more information.
Now it shows us the URL that it's going to use for fetching and the one that it's going to use for pushing. Now typically those are going to be the same ones, but they don't have to be. It could be different ones. We could have a read-only remote that we're fetching from, but we're pushing to one that lets us write. And if you're wondering how Git now knows about these remotes, it stores those in the .git folder of course, in config. Let's take a look that file, and you can see that now it says, okay, I have a remote called origin and here's the URL for it, and these are instructions that Git will use to tell it what information it's going to pull down from the remote repository when it does a fetch.
The last thing I want to show you is just that if you want to remove a remote is just simply git remote rm followed by the alias. So that would remove the origin remote that we just created. So I've removed that. If we now take a look, you will see it's not in our config file, and of course, I can add it again just like that, and now git remote shows me it in the list again. So now our local repository knows about the GitHub repository that we've created. We haven't shared any data yet. None of our branches or commits or anything like that are on the remote repository yet.
At this point, we've just simply created the mechanism by which they can establish a connection so that we can begin pushing our code up to the remote repository, and that's what we will start doing in the next movie.
Find answers to the most frequently asked questions about Git Essential Training.
Here are the FAQs that matched your search "":
Sorry, there are no matches for your search ""—to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.