Repositories not on our local machine are referred to as remote repositories. The local git repository can be made aware of the remote repositories, and can push or pull commits to/from remote repositories. We can use remote repositories for a variety of reasons from back-up to collaboration, and in some cases, even for deployment. The most popular use case, however, is for code collaboration and we'll spend this section talking about how to work with remote repositories hosted by Github.com.
Before we get into Github.com, however, let's talk about code version control systems in general. Because of git's decentralized nature, it does not provide a built-in way to collaborate on projects.
In some server-client SCM systems, developers are always working with the server, which acts as the central repository for all developers on a team. The server hosted code acts as the single source of truth for your project codebase, and team members commit directly to the server.
In a de-centralized SCM system, such as git, the developer is always working against a local repository, unaware of any centrally hosted codebase. In theory, a de-centralized SCM system is much more immune to single point of failure or control.
In practice, however, team-based projects require some sort of centralized control. This is where Github.com comes in. Most teams work with local copies of the codebase, but use the Github.com hosted repository as the "centralized" repository, where it acts as the single source of truth for the entire codebase.
Note that it does not have to be Github.com. Teams can use any other service or application, or even self-host a git repository to act as the central repository.
When you start looking for a repository hosting service, you will find that there are many options. Here are a few:
In this book, we will use GitHub.
It is also possible to host your own repository server using software that is made specifically for that task. Large companies will often do that to keep their codebases secure and in-house.