What I would do is to have each developer have their own local copy that they are working on.

I would then find a machine that is going to be on all the time (which could be a developer's desktop), and create a master repository there. Note that if this is on a developers desktop, this needs to be a different repository (or at the very least a different branch) from what they use to do their work.

developers then do their work locally, and after a change has been reviewed, pull it into the master repository.

This can even be done if you only have one developer (although then you may just use branches instead of a separate repository)

The idea is that when you start working on a new feature, you create a new branch from the master, implement your new feature, and then (after testing) merge the completed feature into the master branch/repository.

If developers are working on multiple things at once, they should have multiple branches. This is a hard habit to get into.

The tendancy is that while you are in changing code, you see something unrelated that needs fixing, so you fix it and go back to what you were doing.

You should try to get into the habit of not fixing unrelated things in one branch (or having a separate branch you use only for trivial fixes)

The idea is that each feature branch should have one set of related changes in it, so that you can merge in a branch when it's ready and not end up with one fix being tied in to another one,

David Lang

On Fri, 18 Jan 2013, Lang, David wrote:

Hi Matt and David,

Your responses have been very helpful for this newbie...thanks very much! I 
have a good sense now of the difference btw a CVCS and a DVCS. Here are two 
more questions...

1. I now get the sense that there's quite a few options in regards to the way that any one group implements their 
"origin"/"master"/<fill in your favourite name> repository. 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? My sense is that would defeat the purpose of the DVCS.

2. Assuming I'm right about question #1, our first hurdle is where to host the 
master repository. Could you provide any suggestions for a setup based on our 
VERY simple department model? I work for a small IT department with a grand 
total of TWO developers (who sit five feet apart from one another)! The reason 
we're looking at a VCS is because I was hired a few months ago and the dept 
never needed one before now. We realize that git will be overkill for what we 
need but frankly anything will be overkill for what we need, and since git 
seems to be so well regarded in the community (and free) it looks like a good 

So the question is, how would either of you recommend we set up our master repository? We 
definitely want to keep everything "in house" so off-site hosting isn't 
something we'd consider. 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. 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. This would simplify the model. What do you think? Or is it 
best to always have the master hosted on a machine with no other local reps?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to