Version Control with Git

Publishing Repositories

Whether you are setting up an open source development environment, in which many people across the Internet might develop a project, or establishing a project for internal development within a private group, the mechanics of collaboration are essentially the same. The main difference between the two scenarios is the location of the repository and access to it.

Note

The phrase “commit rights” is really sort of a misnomer in Git. Git doesn’t try to manage access rights, leaving that issue to other tools, such as SSH, more suited to the task. You can always commit in any repository to which you have (Unix) access either via SSH and “cding” to that repository, or through which you have read, write, and execute access.

The concept might better be paraphrased as “Can I update the published repository?” In that expression, you can see the issue is really the question, “Can I push changes to the published repository?”

Earlier, in Referring to Remote Repositories, I cautioned you about using the remote repository URL form /path/to/repo.git because it might display problems inherent in repositories using shared files. On the other hand, setting up a common depot from which several repositories that are very similar are offered is a common situation where you would want to use a shared, underlying object store. In this case, you expect the repositories to be monotonically increasing in size without objects and refs being removed from them. This situation can benefit from ...