Remote Repositories
Collaboration Setup
As a lone developer, you're probably comfortable working with a_local_repository. In this first lesson, we're going to talk aboutremote repositoriesand interacting with these remote repositories.
Let's say that you have a friend, we'll call her Farrin, and one day you two were together and you showed her what you've been working on. She had some ideas on features she could contribute to the project. But you don't want to give her_your_computer for her to make these changes, you want her to work on her computer. And, you don't want to have to_wait_for her to add these features, you want to keep working on the project and then just merge in her changes when she's finished. So how can we do that?
Well, let me tell you that emailing the project back and forth would be a maintenance nightmare after about two emails. You're already tracking your project with Git, so we'll use _it_ to manage everything.
So Farrin will work on the project on a specific branch and any changes she makes she'll add to that branch. While she's working in her branch, you'll work on the project but on your own specific branch. And then you can merge these branches together when you get the branch from Farrin.
💡 Always Use Topic Branches
Remember that it's incredibly helpful to make all of your commits on descriptively namedtopic branches. Branches help isolate unrelated changes from each other.
So when you're collaborating with other developers make sure to create a new branch that has a descriptive name that describes what changes it contains.
What is a Remote Repository?
Git is a_distributed_version control system which means there is not_one_main repository of information. Each developer has a_copy_of the repository. So you can have a copy of the repository (which includes the published commits and version history) and your friend can also have a copy of the same repository. Each repository has the exact same information that the other ones have, there's no one repository that's the main one.
Up until this point, you have probably been only working locally on a_local_repository. A_remote_repository is the same Git repository like yours but it exists somewhere else.
A local repository is the one that you work on in your local machine. Remote repositories live elsewhere (e.g. a friend's computer, GitHub, etc.)Ways to access a Remote
Remotes can be accessed in a couple of ways:
- with a URL
- path to a file system
Even though it's possible to create a remote repository on your file system, it's very rarely used. By far the most common way to access a remote repository is through a URL to a repository that’s out on the web.
The way we can interact and control a remote repository is through the Git remote command:
$ git remote
You're also not limited to just one remote. You can add as many remote repositories as you want!
A local repository can be connected to more than one remote repository.
Why Multiple Remotes?
Why would you want to have multiple remote repositories? We'll look at this later but briefly, if you are working with multiple developers then you might want to get changes_they're_working on in their branch(es) into_your_project before they merge them into the master branch. You might want to do this if you want to test out their change before you decide to implement your changes.
Another example is if you have a project whose code is hosted on Github but deploys via Git to Heroku. You would have one remote for themasterand one for thedeployment.
Make a Remote
Now that we've learned about the purpose of remote repositories, let's add a remote repository to our own local one.