Thanks Matt and Dave and everyone else for your feedback on this. Ok, I've done some more reading in the Pro Git manual and I think I have an idea of how to get started. Could I run this by you just in case I'm missing anything? Currently (pre-git status) what we have is two developers both working in Visual Studio, occasionally on the same project (hence the need for git). All the VS projects exist on a server and are accessible to both developers via a network share. Currently, if one of us needs to work on a project we turn around and ask our colleague if he's currently in it...this is how we avoid both being in at the same time. We run VS locally on each of our PC's and load the VS project into Visual Studio from the network share. Easy enough... So to get this all set up with git, here's what I think I have to do... 1. Download and install git for Windows on the 2 networked developer's PC's and the 1 networked server. 2. On the server... a) Initialize the Visual Studio folder for a particular project as a git repository using 'git init' b) Using the git rep just created (above), create a bare repository on the server to act as the remote/master repository using 'git clone --bare' 3. On each of the PC's... a) Clone the remote repository from the network server using 'git clone' (this will automatically create 'origin' as a remote source on the PC's) Couple of questions... 1. Anyone see any problems/issues with the above? 2. Is it sufficient to use the local protocol for transferring files? Seems like the most straightforward. 3. On p.84 of the guide there's a section entitled "Putting the Bare Repository on a Server" but since the first two rep's (original and bare) are already on the server, this is unnecessary, correct? 4. The original Visual Studio project folder essentially remains untouched, correct? The 'git init' and 'git clone' commands just make copies and references of whatever data is in the VS project folder, right? David > -----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. This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. -- 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