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: [email protected] [mailto:[email protected]] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
