Master: git remote
In this video we'll learn some of the additional uses for
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 parent
If 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.git
Again, 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 parent
And 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.