ClearCase 与 Git 版本控制 [关闭]

Question

我们正在使用 multisite ClearCase 存储库，并且我们经常需要合并和构建我们的系统。这种合并和复制需要将近三天的时间才能跨站点可用。因此，为了提高效率，我们计划转向 Git 版本控制。如果我们从 ClearCase 迁移到 Git，您能否告知我们可能遇到的潜在缺陷？

Answer 1

@zzz777：您的问题是以 ClearCase 为中心的观点提出的，以至于以前从未使用过 ClearCase 的人无法理解。事实上，Git 比 ClearCase领先光年，而商业 SCM 需要赶上 OSS 系统。

我有使用 ClearCase 和 Git 的经验，我可以告诉你，ClearCase 的查找合并（错误）功能是其基于版本控制文件的（根本上被破坏的）设计的结果，但在 Git 中你不需要将共享分支合并到您的私有分支的这种原始工具。 ClearCase 是面向文件的，而 checkin-s 是基于文件的，这就是为什么您需要 Find (files) to merge 实用程序，但 Git 是基于提交的，这是正确的模型，因为当您修复问题或实施功能，整个变更集或没有一个是唯一有意义的选项。

Git 有一个非常强大的合并功能，它做正确的事。有两种方法可以满足您的要求（将您的私有分支更新为共享分支 + 您的更改）。

最明显的是进行合并，所以在你的私有分支上你只需这样做：

git merge sharedbranch

然后，如果存在冲突（确实比 ClearCase 中少得多），您可以解决它们并

git commit

就是这样。作为奖励，因为 Git 在本地拥有所有历史记录，所以您不必浪费无数小时，如果您有很多文件，就像您在 ClearCase 中所做的那样，合并速度非常快，当 ClearCase 在动态视图中执行合并 10 个文件，Git 可能会轻松完成 100 个文件的合并。

使用 git merge 意味着您保留历史，如果您的历史在合并之前看起来像这样：

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

合并后会是这样的：

o---1---2---3 (sharedbranch)
 \           \
  a---b---c---m (privatebranch)

这会保留您的更改历史记录，并允许其他人查看您的工作。

请记住，这些不是文件修订历史。这些如果树历史，这是唯一有意义的存储历史，即使分支仅相差一两个文件。您要保留的状态是树，而不是一个文件。

第二个选项是使用 rebase，这意味着你让它看起来好像你的更改是从共享分支上的最新代码开始的。

您使用的命令（同样，在私有分支上）：

git rebase sharedbranch

历史树将从：

o---1---2---3 (sharedbranch)
 \
  a---b---c (privatebranch)

到

o---1---2---3 (sharedbranch)
             \
              a'--b'--c' (privatebranch)

因此，如果您给 Git 一些时间来理解它，并稍微使用它，您就会发现 Git 模型有多好，而 ClearCase 模型有多破碎。

顺便说一句，ClearCase 中的邪恶孪生问题在 Git 中根本不存在，因为 Git 不跟踪目录（相信我，你确实不需要需要那个）。

另外，如果你曾经有一个配置规范，它有几个分支，有点复杂，并且你将文件从一个分支迁移到另一个，你可能知道配置规范中规则的顺序有多重要，并且因为配置规范是“错误的”，所以看到旧版本的文件是多么令人沮丧。由于其基本设计，ClearCase 中会发生这种情况，而且不用说，这种废话在 Git 中不会发生。

因此，总而言之，Git 没有诸如“查找合并”之类的原始工具，因为它不需要它。它具有实际有效的高级模型和高级合并模型。与 ClearCase 相比，它快如闪电（CCRC 静态视图或动态视图，随你便便）。

ClearCase 唯一可能具有优势的地方是动态视图的即时更新，但这也可以通过您可以比更新配置规范更快地键入 git checkout branch 的事实得到缓解.

Answer 2

我在专业的混合能力办公室遇到的问题：

1. 可变历史。 你可以用 Git 做一些非常愚蠢（但功能强大）的事情。这可能会导致源丢失。
2. 自动合并。 这是 Git 的最大特点。 但是，我们不得不关闭开发一周才能找到丢失的源代码。 MSVS 有一个令人高兴的问题，即随机更改行尾，如果您不定期从存储库中提取，它会变得混乱，并且更改会丢失。
3. 推/拉订单。 ClearCase 会为您处理日期排序和历史记录，但 Git 会忽略它。
4. 暂存。 ClearCase（至少是 UCM）为您处理分支推广和其他事情。吉特没有。您必须谨慎处理。
5. $ID$ Git 不存在。必须手动处理来自实际版本的版本跟踪和通过了解源文件的版本来发现问题。 （我不确定您的发布流程是什么。）

对于您的最终代码存储库，我可能会建议一个发布存储库，可以是另一个源代码控制系统或单独的 Git 存储库，它是受管理的并且只接受拉取。

我目前正在将 Git 用于我的个人项目，这很好。但是，在一个拥有各种编辑的混合能力的房子里，我会很小心。你真的可以在不知不觉中使用 Git。

Mercurial 或 Bazaar 我都没有使用过。随着一些问题的消失，这些可能值得关注，并且它们具有缓解上述一些问题的功能。

Answer 3

我曾使用过 Git 和 ClearCase，一旦您学习如何使用 Git 然后进行切换，您将永远不会回头。确保您有时间培训您的开发人员——这应该是您的首要任务。 Git 是一种与 ClearCase 完全不同的 SCM 方法。

需要考虑的一些事情（可能的缺点）：

1. 您将需要一个真正的 存储库管理员，而不仅仅是监视源代码的人，而是了解 SCM 实际工作原理（不仅仅是 GUI 向他们显示的内容）并能够处理您的分支模型（参见 #2）
2. 采用/开发稳健的分支模型。一个很好的例子，我用过的一个例子是 A successful Git branching model
3. 您将不得不投入大量时间来帮助您的开发人员重新学习他们认为了解的有关使用 SCM/与 SCM 交互的所有知识。

如果您能克服上述三个问题，那么就没有什么坏处了（#3 是最难的）。至于@PAntoine，这些问题中的大多数都与培训有关——#1 必须做出一个非常糟糕的决定才能丢失源代码。 git reflog 将为您提供对存储库的每个提交的访问权限。销毁源的唯一方法是通过git reflog expire --expire=whatever refs/heads/master、git fsck --unreachable、git prune 和git gc，它们只能由存储库管理员处理——然后是开发人员不提交其源的普遍问题（天啊！）

Answer 4

正如我在“What are the basic ClearCase concepts every developer should know?”中提到的，ClearCase 的多站点存储库可能具有一些“去中心化”功能，但其核心仍然是 CVCS：

• 它与系统用户 ID 有很强的联系（这在没有唯一用户引用的 DVCS 中不相关）。

• 它有一个独特的 repo 用于管理标签和分支名称 (admin vob)，而您可以毫无问题地在 15 个不同的 Git repos 中定义一个“测试”分支（除非您需要知道 repo1/test 代表什么，相对于repos2/test)。

• 它还通过 (UCM) 流层次结构集中了合并工作流定义（您可以直观地看到应该将作品从一个流合并到另一个流的位置）。

• 它通过 UCM 提出了代码子集（组件）的定义，以及依赖管理。 Git只有子模块，没有覆盖/覆盖检测机制。

• 它管理任何类型的文件，甚至是大型二进制文件，而 DVCS（任何类型的 DVCS）最好只管理源代码。

底线（在我们从 ClearCase 到 Git 的迁移中）是它需要对源代码进行大量重构/重组，以便拥有可管理的 Git 存储库。

Answer 5

您是否需要一种工具来帮助您进行软件配置管理 (SCM) 或版本控制 [系统] (VCS)？

这就是 ClearCase 与 Git 讨论的内容。

可以这么说，您是在将苹果与橙子进行比较。

将 ClearCase 视为另一个 VCS 是对 ClearCase 的狭隘看法；如果您的目标是将正确的产品运出您的商店，请坚持使用 ClearCase。

另一方面，Git 可能是目前市场上最好的 VCS，（尽管它不提供任何 SCM 支持）所以如果你关心的是分支和合并，你可以切换到它......（附注合并冲突是基线设置不当和视图配置不正确的结果）...... VOB 复制很糟糕 - 我给你。

您计划的移动的缺点是您将丢弃您的 SCM 工具支持。而且您将不得不面对无数其他工具和大量手动工作才能实现您使用 ClearCase 开箱即用的功能。

无论如何，一个好的 VCS 是任何 SCM 的支柱，所以从长远来看，您迁移到 Git 可能会有所回报。