git的具体示例合并在SVN中不起作用

Question

我正在寻找可以在git中工作的具体示例合并,但会导致SVN中的冲突.除此之外,您在Git中从未尝试过的艰难/痛苦的SVN合并样本也没问题.

我可以识别出与我的问题相关的四类合并:

1. 大爆炸合并
2. 重命名/移动相关合并
3. 在两个分支中创建目录/相同文件
4. 纵横交错

我在这里错过了任何场景吗？

找到1-3的样本是微不足道的(在评论中找到2的样本,3作为我的答案的一部分,1几乎是任何rebase).有没有人为一个成功的纵横交叉合并提供样本(看起来不是学术上的),这会在SVN中失败？

Answer 1

当然值得一提的是octopus合并策略？

一般来说,很难找到章鱼与最多8个分支合并的具体例子(最小值为3).

然而,或许更准确地回答你的问题我不认为提供一个人为的'这个在Git中工作但在SVN中没有'的例子将赢得你与你的同事/管理层的任何战斗.

我认为这很困难 - 而且我说的是根据我自己的经验,在搬迁公司之后从SVN过渡到Git,以便在不了解两种工具的潜在"螺栓和螺栓"的情况下欣赏Git的真正力量.我不确定Linus本人是否可以向某人(街上一个典型的人)展示一个获胜的"电梯间距",而不知道Git与SVN的内部运作方式.

有些人可能不同意这种观点,但我对Git的采用来自备受尊敬的人,称这是源控制的最佳工具; 我相信他们并且他们已被证明是正确的,因为我已经了解了更多关于Git如何在内部工作以及从高效工作流程中学到的知识.

使用SVN的持久记忆每天都在解决合并冲突.我曾经认为这是开发软件的正常部分,但并非必须如此.

Answer 2

找到一篇带有很好示例的文章。创建“team b”分支只是为了显示在两个分支中创建相同目录的树冲突。以下是概述：