Version Control with Git, 2nd Edition

Chapter 12. Remote Repositories

So far, you’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; 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 separated contributors.

Essentially, separate repositories are useful whenever:

• Developers work autonomously.

• Developers are separated by a wide area network. A cluster of developers in the same location may share a local repository to amass localized changes.

• 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, separate 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 ...