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
choice.
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?
David
--
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
