As you begin to work in Git, you're going to hear the term "remote repository" on a regular basis. So, I'm going to take a minute to explain what remote repositories are, and then we'll set some up so that you can experience how they work.

A remote repository is, at its core, another instance of the repository you're working in that is linked so that changes made to one can be pushed to the other. The remote repository could be hosted on a Git hosting service like GitHub or BitBucket, it could be on a co-workers machine, or it could even be another folder on your local machine.

In a typical Git project there is one remote repository known as the "Central" repository. The central repo is almost always hosted either on a private server setup for this explicit purpose, or on a Git hosting service. Because creating your own Git server is fairly complex, and unnecessary for the average user, in this series, we'll rely on a Git hosting service to house our central repository.

With that out of the way, let's look at a few examples of how you can interact with remote repositories.

Push Local Repo to Hosting Service

The most common way to use Git is to host the central repository with a hosting service. If you already have a repo that you've been working in locally, you can push that repo to your service of choice, and declare that one to be the new central repo.

Pull Central to Live Hosting Machine (Maybe even dev-stage-live)

If you'd like to work on a website locally (which is faster, and helps prevent making mistakes on your live site) you can pull the central repo to your live server and host the site from that copy. Then, work away on your local machine, knowing that nothing you do will affect the live copy. Once you're happy with the changes, You can push them to the central repo, and pull them to the live site.

Since Git is at its core a version control system, you can then roll the code back to its previous working state in case something does goes wrong.

Collaborate on a Git Repository

If you have a friend or co-worker that needs to contribute to your project, they can clone the central repository to their machine and work on it there. Because Git repos are entirely isolated, nothing they do on their local machine will affect your local copy, or the live version until their changes are pushed up to the central repo, and pulled down to another machine.

Now that you know how remote repositories can be used, let's set one up. I'm actually going to show you how to use two different Git hosting services: GitHub and BitBucket (There are plenty of other services, but these are the two I'm most familiar with.) Each service has its benefits, but here is a basic comparison, and recommendations on when to use each one.

So, if you're looking to get started by yourself (or on a small team) with a private repo, BitBucket is the way to go because it's free in that scenario. However, if you want to create a public repo where anyone can see the project and copy it or contribute to it, GitHub is the way to go because it'll be free in that scenario. If you need to setup a private repo for more than 5 collaborators, that's when you'll need to compare the paid plans to see which one fits your project best.

I do most of my work solo, so I almost exclusively use BitBucket, but GitHub is arguably the most commonly used service in the open source world (because of the free public repos of any size), so in the following videos I'll show you how to setup a project on each service so that you'll know how to use whichever one you choose.