Clarifications for merge workflows

Hello,

Some informations are available in the manual about distributed content management workflows. http://kernel.org/pub/software/scm/git/docs/gitworkflows.html#_merge_workflow

I find that a few details are missing to achieve a better understanding for the merging of branches.

Use case:
A contributor pushes an update suggestion from the personal repository "ABC" to
a topic branch in a public repository "SHARE" on a separate server. An
integrator reviews the proposed changes. If they are accepted, the integrator
will choose a repository where the merge should be performed next.
- Log-in to the server and integrate the updates there.
  or
- Fetch the remote topic branch into the integrator's own local repository
"XYZ", merge there and push the result back to the server.

Which ways do you recommend to select the storage location where a merge will be applied first?

Regards, Markus

Markus Elfring <Markus.Elfring@web.de> writes:

Personally, I would find the latter a more natural (and perhaps the only natural) solution to me.

Being distributed is just that. When I do my work, whether it is developing new things myself, reviewing others' patches or reviewing others' pull requests and accepting them (either "am", or "pull"), everything is done "locally" at the most convenient place for "me", and that convenient place happens to be where I primarily do my work. The tools, test procedures, and everything necessary for my work is already there.

And then the procedure to publish the result out, whether it is what I did myself, or what I helped to integrate into my history from others, is the same. I push the result out from that "local" place to the "public" one.

Of course, if you are always working on that "server", the fact that you are always working there makes it the most convenient place to do all of your work for you. But even in that case, you would not want to publish a half-integrated state out to the public only to confuse people, so the actual integration work may happen phisically on the "server" machine, but most likely you would be working in a repository on that machine that is separate from the one you let others to pull from, i.e. your public repository.

Thanks for your explanation.

Does any observable difference exist if the data synchronisation would be performed in the other direction?

I guess that it matters a bit if the published repository "SHARE" is the leading and authoritative storage location.

Regards, Markus