我正在寻找可以在 git 中工作但会导致 SVN 冲突的具体示例合并。除此之外,您从未在 Git 中尝试过的硬/痛苦的 SVN 合并示例也可以。
关于我的问题,我可以确定主要有四类合并:
我错过了这里的任何场景吗?
寻找 1-3 的样本是微不足道的(在评论中找到 2 的样本,3 作为我答案的一部分,1 几乎是任何变基)。有没有人有一个成功的交叉合并的样本(不看学术) ,这将在 SVN 中失败?
当然值得一提的是octopus
合并策略?
一般来说,很难找到章鱼合并的具体例子,最多有 8 个分支(最少为 3 个)。
但是,为了更准确地回答您的问题,我认为提供一个人为的“这在 Git 但不适用于 SVN”示例不会赢得您与同事/管理层的任何战斗。
我认为很难 - 我是根据我在搬家后从 SVN 过渡到 Git 的经验说的 - 在不充分了解这两种工具的基本“基本要素”的情况下欣赏 Git 的真正力量是很困难的。我不确定 Linus 本人是否可以向不了解 Git 与 SVN 内部工作原理的人(街上的典型人物)提出一个成功的“电梯推销”。
有些人可能不同意这种观点,但我对 Git 的采用来自受人尊敬的人,他们说它是源代码控制的最佳工具。我信任他们,并且他们已被证明是正确的,因为我更多地了解了 Git 内部的工作原理以及其高效的工作流程。
我对使用 SVN 的持久记忆是每天解决合并冲突。我曾经认为这是开发软件的正常部分,但并非必须如此。
找到一篇带有很好样本的文章。创建“team b”分支只是为了显示与在两个分支中创建相同目录的树冲突。这是一个概述:
好吧,在现实世界中捕获并注册的奇怪和错误合并的真实样本
r9 | Badger | 2013-03-06 11:42:34 +0600 (Ср, 06 мар 2013) | 1 line
Changed paths:
M /branches/B2/src/add.txt
B2 changes in add.txt
------------------------------------------------------------------------
r8 | Badger | 2013-03-06 11:35:45 +0600 (Ср, 06 мар 2013) | 2 lines
Changed paths:
M /branches/B2
M /branches/B2/core.txt
A /branches/B2/src/add.txt (from /trunk/src/add.txt:7)
Merge from trunk to B2
------------------------------------------------------------------------
r6 | Badger | 2013-03-06 11:31:36 +0600 (Ср, 06 мар 2013) | 1 line
Changed paths:
M /trunk
M /trunk/core.txt
A /trunk/src/add.txt (from /branches/B1/src/add.txt:5)
Merge from B1 to trunk
------------------------------------------------------------------------
r5 | Badger | 2013-03-06 11:28:58 +0600 (Ср, 06 мар 2013) | 1 line
Changed paths:
M /branches/B1/core.txt
A /branches/B1/src/add.txt
B1 changes
------------------------------------------------------------------------
从 b2 到主干的合并尝试(预期结果 - 将更改合并src/add.txt
到现有文件的主干版本中)
>svn merge --dry-run file:///Z:/Repo/branches/B2
--- Merging r4 through r9 into '.':
C src\add.txt
G .
Summary of conflicts:
Tree conflicts: 1