Re: Question re. git remote repository

[Junio C Hamano <gitster@pobox.com>]

David Lang <david@lang.hm> writes:

> On Fri, 18 Jan 2013, Junio C Hamano wrote:
>
>> David Lang <david@lang.hm> writes:
>> ...
>>> 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.

If you are assuming that the "main repository" has a working tree
and somebody goes there, runs "git pull" and manually resolves
conflicts, that may be asking for trouble down the road. It may be
sufficient for two-person group as long as they coordinate among
themselves so that only one of them uses that working tree at the
"main repository" at a time.

But in general, it is more common to have a bare repository without
any working tree as the "main repository", let a push that conflicts
fail, and have the pusher fetch from the "main repository" and fix
up the conflicts in his working repository before he tries to push
the cleaned-up result.  That gives the pusher a chance to re-test
the result of integration with what he did not see while he was
developing what he attempted to push.

"pull" and "pull -rebase" are two ways to do that "fetch from the
'main' and fix up" step.