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 

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?


> -----Original Message-----
> From: [] 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
More majordomo info at

Reply via email to