> -----Original Message----- > From: git-owner@xxxxxxxxxxxxxxx [mailto:git-owner@xxxxxxxxxxxxxxx] On > > But ultimately, there shouldn't be a question of "if" you > have a master repository but "where" you have the master repository, correct? > Or in other words, it doesn't seem like you'd want to designate any one > developer's local repository as also being the master repository, right? You have two options: 1. Central model: a. each developer has their own private repository b. each developer uses "git commit" to commit changes into their own private repository c. in addition, you also have a shared master repository d. each developer uses "git push" to push their changes from their private repository to the shared master repository e. each developer uses "git pull" to pull other developers' changes from the shared master repository 2. Peer-to-peer model: a. each developer has their own private repository b. each developer uses "git commit" to commit changes into their own private repository c. each developer uses "git pull" to pull other developers' changes from other developers' private repositories You can even mix these models. Say you have a 5 member team, and 2 members are working on a feature together. The 2 people working on the feature may use "git pull" to pull changes from each other's private repositories. Then, when the feature is ready, one of them can use "git push" to push the final version from their private repository into the team's shared repository. What you don't want to do is this: Single repository, multiple developers: just one repository, and every developer uses "git commit" to commit their changes into the same repository. > My sense is that would defeat the purpose of the DVCS. Not at all. The purpose of the DVCS is to allow each developer to have their own private repository where they can commit changes, while still allowing people to share changes from one repository to another. That's true whether you use the central model or the peer-to-peer model. The traditional VCS has just one repository, and everyone has to commit their changes into that one central repository. > We have access to many servers on our > company's network, some of which we have full rights to, so there's no issue in > regards to storage space. That will work fine. > I suppose another idea would be to have the master > simply reside on one of the two developers local machines, so one of us would > have both a local rep and the master rep and the other of us would have just a > local rep. That will also work. You could even omit the master rep. and just have each developer have a local repository. Each developer could then commit changes to their own local repository, and pull the other developer's changes from the other developer's local repository (the peer-to-peer model mentioned above). > Or is it best to > always have the master hosted on a machine with no other local reps? There's no requirement to have the master hosted on a machine with no other local reps. The only issue is that the machine with the master rep. must be turned on for the other developers to push changes from their private repositories to the master repository. Having the master repository on a 24x7 server ensures it is always available to all developers. It also gives you another backup copy of your code, in case the developer's machine's storage fails or gets corrupted. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html