git中上游/主题/整合之间的合并方向是否有意义？

Question

我已阅读Packaging Software using git文章，直到我的眼睛疼痛，我从this image可以看到，它建议从上游 - >主题分支 - >本地集成分支合并。

我特别感兴趣的是上游分支和本地整合分支之间存在冲突的情况。如果我完全正确地阅读文章，它说如果我合并上游 - >本地集成分支 - >主题，如果该主题已经合并到本地集成分支中，我将陷入困境。

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

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

我仍然不知道我的理解，他们正试图文章无论是在描述陷阱....

Answer 1

这是一个典型问题，本DVCS的publication factor复杂（如“分布式“）：

• 变基是强制性的包括上游变阵在当地的分支机构（本地和解决冲突）
• 但重写一个分支的历史下游用户来说是一个很大的禁忌

因此，额外的分支（演进thrugh meorges只，无底垫）中所描述：

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

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

作为在Git rebase vs. merge中提到

“rebase然后合并”可以是一个有效的工作流程，首先解决冲突的孤立，然后恢复您的工作。

由于Linus said in his comment：

合并是不错的，因为如果你有并行开发，合并将两个分支联系在一起，并允许您测试和两个变化的，顶级的开发。

但缺点是合并太急切意味着两个不同功能的独立分支现在被连接在一起，并且您永远无法将这两个分开（至少在不重新完成整个历史记录的情况下）。

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