Chapter 11. 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 scale to projects that are large and dispersed.
Essentially, separate repositories are useful:
Whenever a developer works autonomously.
Whenever 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.
Whenever a project is expected to diverge significantly along separate development paths. Although the regular branching and merging mechanism 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 ...
Get Version Control with Git now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
