git中上游/主题/整合之间的合并方向有意义吗？ [英] Is there a significance in merge directions between upstream/topic/integration in git?

问题描述

我已阅读使用git的包装软件文章，直到我的眼睛疼痛，正如我可以从这张图片看到的，它推荐从上游 - >主题分支 - >本地集成分支合并。

我特别关注上游分支和本地集成分支之间存在冲突的情况。如果我正确地阅读了文章，它说如果我合并上游 - >本地集成分支 - >主题，如果主题已经合并到本地集成分支中，我将遇到麻烦..？

理想情况下，我希望在任何我觉得有用的旧方向上进行合并，但是如果我这样做，似乎我正在为自己设置一些麻烦？当我尝试在不同分支上以不同顺序对可能来自上游的提交交织的主题分支进行可视化时，我的头也开始受到伤害。有人应该告诉我不要在乎。

目前我们正在从上游到我们喜欢的任何地方合并，我不确定这是否是减少冲突方面的最佳解决方案。在我看来，git很难跟踪一个明智的共同祖先，并且我怀疑我们是通过合并这种方式来引入纵横交错的合并情形？我们当然有我们公平分享的冲突，在我看来，像我在git mergetool中看到的共同祖先指出的是（对我而言）看起来是一个非常糟糕的选择（但也许是正确的）。是否有任何我们应该避免的合并顺序，为什么？

我仍然不确定我是否理解他们在文章中描述的陷阱...... 。

解决方案

这是一个经典的合并工作流程问题，并由此DVCS的出版系数复杂化（如在分布式中）：

• 必须在您的本地分支中包含上游演变（并在本地解决冲突）


• 但是为下游用户重写分支的历史记录是一个很大的禁忌

因此，额外的分支（只演变通过meorges，没有rebase）描述在：

alt text http://www.golden-gryphon.com/software/mis c / rebase_merge.png

目前我们正在从上游合并到我们喜欢的任何地方

正如 Git中所述rebase与合并

rebase then merge可以成为一个有效的工作流程，首先解决冲突，然后带回您的工作。

如

合并很不错，因为如果你并行开发，合并将把两个分支联系在一起，并允许您在两种变化的基础上进行测试和开发。

但缺点是合并过于热切地意味着两个不同特征的分支现在连在一起，并且你永远不可能将这两者分开（至少在不重复整个历史的情况下）。

因此，将太多的结果合并在一个非常混乱的历史中，你无法看到实际的不同主题是什么。它会导致一个上游（即 - 我）不能一个接一个地检查和拉取这些特征的树。

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....

解决方案

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:

alt text http://www.golden-gryphon.com/software/misc/rebase_merge.png

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.

这篇关于git中上游/主题/整合之间的合并方向有意义吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！