Version Control with Git, 3rd Edition

Chapter 11. Remote Repositories

So far, we’ve worked almost entirely within one local repository. Now it’s time to explore the much-lauded distributed features of Git and learn how to collaborate with other developers via shared repositories.

Working with multiple and remote repositories adds a few new terms to the Git vernacular.

A clone is a copy of a repository. A clone contains all the objects from the original repository; as a result, each clone is an independent and autonomous repository and a true, symmetric peer of the original. A clone allows each developer to work locally and independently without centralization, polls, or locks. Ultimately, it’s cloning that allows Git to easily scale and permit many geographically distributed contributors.

Essentially, separate repositories are useful under the following conditions:

• When developers work autonomously.

• When a project is expected to diverge significantly along separate development paths. Although the regular branching and merging mechanisms demonstrated in previous chapters can handle any amount of separate development, the resulting complexity may become more trouble than it’s worth. Instead, diverged development paths can use separate repositories to be merged again whenever appropriate.

Cloning a repository is just the first step in sharing code. You must also relate one repository to another to establish paths for data exchange. Git establishes these repository connections through what we call remotes ...