Re: Question re. git remote repository

From: David Lang <david@lang.hm>
Date: Jan 18, 2013, 21:27 UTC
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:

Show 15 quoted lines

> 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