On Fri, 18 Jan 2013, Junio C Hamano wrote:
David Lang <da...@lang.hm> writes:
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 ... 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.
s/pull it into/push it into/; I think.
fair enough, I always think in terms of pulling from feature branches into the
main repository so that any merge conflicts get resolved. I didn't describe this
clearly enough.
Junio, is there a really good place we should be pointing David where the
different workflows are described and explained?
for David
After the work is completed in the feature branches, you now have the problem of
how to combine this work in with whatever other work has taken place in the
meantime.
One common way to do this is to pull from the feature branch into the main tree.
If there are conflicts, git will help you identify them and resolve them (note
that some changes will not produce conflicts that git detects, but can still
result in non-working code)
developers can (and should) do a dry run on this if significant changes have
happened in the master. Create a new throw-away branch of the master tree and
merge your feature branch into that tree and see what happens. If everything
works, you are good to go. If you have massive conflicts, it may be worth doing
work to avoid the conflicts and then submit the result of that to the master
(also known as upstream)
With only two developers, you can have each of them do the merge work on a
temporary branch and then push the results upstream to the master, or you can
have one of them 'change hats' to be the release manager and work from the point
of view of the master to pull the changes in)
David Lang
--
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
