From: David Lang <david@lang.hm>
Date: Fri, 18 Jan 2013 21:27:55 GMT
Subject: Re: Question re. git remote repository
Message-ID: <alpine.DEB.2.02.1301181320070.21503@nftneq.ynat.uz>
In-Reply-To: <7v622uqjch.fsf@alter.siamese.dyndns.org>

On Fri, 18 Jan 2013, Junio C Hamano wrote:

> David Lang <david@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