Is there a significance in merge directions between upstream/topic/integration in git ?

Question

I have read the Packaging Software using git article until my eyes are sore, as I can see from this image, it recommends merging from upstream->topic branch->local integration branch.

I am specifically interested in the scenario where there are conflicts between upstream branch and local integration branch. If I am at all reading the article correctly it says that If I merge upstream->local integration branch->topic, I will be in for trouble if the topic is already merged into local integration branch..?

Ideally I would like to merge in any old direction I would find useful, but it seems like I'm setting myself up for some trouble if I do that? My head also starts hurting when I try to visualize commits on topic branches intertwined with commits from upstream, in different order on different branches. Someone should tell me not to care.

Currently we are merging from upstream to anywhere we like, and I am unsure if this is an optimal solution in terms of reducing conflicts. It seems to me like git is having a hard time keeping track of a sensible common ancestor, and I suspect we are introducing criss-cross merge situations by merging this way? We are certainly having our fair share of conflicts, and it seems to me like the common ancestor I see in git mergetool is pointing at what (to me) looks like a very bad choice (but maybe correct). Is there any order of merging we should avoid, and why ?

I'm still not sure I understand the pitfalls they are trying to describe in the article either....

Answer 1

It is a classic merge workflow issue, complicated by the publication factor of this DVCS ( as in "Distributed"):

• rebase is mandatory to include upstream evolutions in your local branch (and solve conflict locally)
• but rewriting history of a branch for downstream users is a big no-no

Hence the extra branches (evolving thrugh meorges only, no rebase) described in:

Currently we are merging from upstream to anywhere we like

As mentioned in Git rebase vs. merge

"rebase then merge" can be a valid workflow to first resolve conflict in isolation, then bring back your work.

As Linus said in his comment:

Merging is nice, because if you have concurrent development, a merge will tie the two branches together and allows you to test and develop on top of both changes.

But the downside is that merging too eagerly means that two separate branches that are for two different features are now tied together, and you can never separate the two (at least without re-doing the whole history).

So merging too much results in a very messy history, where you can't see what the actual different "topics" were. And it results in a tree where upstream (that is - me) can't review and pull the features one by one.