Master: git remote
In this video we'll learn some of the additional uses for git remote.
In init: git remote we covered what a remote is, how it's used, and listed our remotes.
Let's setup and manage some additional remotes.
In this case, we've forked the gettinggit repository and then cloned the fork.
So origin points to our fork, but we don't have a reference the gettinggit repository directly.
So, let's create an additional remote for the gettinggit repository.
That way when updates occur in the gettinggit repository, we can pull them down to our fork.
Let's add a remote called upstream that points to the gettinggit repository.
We'll go to the gettinggit repository on GitHub and copy the clone URL.
Then I'll run git remote add upstream and paste the clone URL.
upstream is a common name for the remote referencing the parent repository. It contains the work that will feed into your repository.
If we run git remote -v again, we'll see the upstream remote was added.
Sometimes you may need to manage an existing remote.
You can change the name of remote with git remote rename.
In this case, I'll rename the upstream remote to parent by running
git remote rename upstream parentIf I run git remote -v again we'll see this change.
We also change the URL with git remote set-url.
In this case, I'll change the URL for the origin remote to use the https URL by running:
git remote set–url origin https://github.com/jasonmccreary/gettinggit.gitAgain, we'll verify this by running git remote -v.
Finally I can remove a remote by running git remote remove.
In this case, I'll remove the parent remote by running:
git remote remove parentAnd one last time, we'll run git remote -v to verify the parent remote was removed.
Although it may seem you won't need to manage multiple remotes. You will if you are working on a large team. For example, you may create remotes to reference other team members' repositories.
Even in the case of contributing to a repository, you'll likely manage both the origin and upstream remote.