Question

我们正在使用多站点 clearcase 存储库，通常我们需要合并和构建我们的系统，这种合并和复制需要将近3天的时间才能在各个站点上使用。因此，为了提高效率，我们计划转向 Git 版本控制。如果我们从Clearcase转到Git，你能否告诉我们可能遇到的潜在缺点？

Answer 1

@ zzz777：您的问题在这样一个以ClearCase为中心的观点中被问到，以前从未使用过ClearCase的人无法理解。实际上，Git是ClearCase的光年，它是需要赶上OSS系统的商用SCM。

我有使用ClearCase和git的经验，我可以告诉你，ClearCase的Find merges（mis）功能是基于版本控制文件的（根本上是破坏的）设计的结果，但是在git中你不需要这样的一个基本工具，用于将共享分支合并到您的私有分支。 ClearCase是面向文件的，checkin-s是基于文件的，这就是你需要Find（文件）合并实用程序的原因，但是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)

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

请记住，这些不是文件修订历史记录，如果树历史记录是唯一有意义存储的历史记录，即使分支只有1或2个文件不同，您要保留的状态是树，而不是一个文件。

第二个选项是使用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没有诸如“find merge”之类的原始工具，因为它不需要它。它具有卓越的模型和卓越的合并模型，实际上是有效的。与ClearCase（CCRC静态视图或动态视图，您可以命名）相比，它闪电般快速。

ClearCase可以有优势的唯一地方是动态视图的即时更新，但是你可以输入比你更新配置规范更快 git checkout branch 的事实也可以减轻这一点。

Answer 2

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

可变历史。
你可以用GIT做一些非常愚蠢（和强大）的事情。这可能会导致源丢失。
自动合并。
这是git的最佳功能。但是，我们不得不关闭开发一周，以找到丢失的源代码。 MSVS有一个很好的问题，随机改变行结尾，如果你不经常从存储库中拉出来，就会感到困惑，变化就会丢失。
推/拉顺序。
Clearcase为您处理日期排序和历史记录，但git忽略它。
分段。
Clearcase（至少UCM）为您处理分支促销和其他事情。 Git没有。你必须仔细管理这个。
$ $ ID
git不存在。从实际版本跟踪版本，并通过手动处理知道源文件版本的问题查找。（我不确定你的发布过程是什么）。

对于最终的代码存储库，我可能会建议一个发布存储库，或者是另一个源控制系统或一个单独的git存储库，它是受管理的，只接受pull。

我目前正在使用git进行我的个人项目并且很好。但是，在一个混合能力的房子里有各种各样的编辑，我会小心的。在不知道Git的情况下，你真的可以把脚踢掉。

我没有使用过，hg或bzr。可能值得一看这些问题，因为一些问题消失了，它们具有缓解上述一些问题的功能。

我希望这会有所帮助。

Answer 3

正如我在“What are the basic ClearCase concepts every developer should know?”中所提到的，ClearCase可能在其多站点回购中具有一些“分散”功能，但它仍然是CVCS的核心：

它与系统用户ID有很强的联系（在DVCS中没有相关性，没有唯一的用户参考）。
它有一个独特的repo来管理标签和分支名称（管理vob），而你可以在15个不同的Git repos中定义一个'test'分支而没有问题（除了你需要知道repo1/test代表，相对于repos2/test）。
它还通过（UCM）Stream层次结构集中了一个合并工作流定义（您可以看到您应该将作品从一个Stream合并到另一个Stream的位置）。
它通过UCM提出了代码子集（组件）的定义，具有依赖关系管理。 Git只有子模块，没有覆盖/覆盖检测机制。
它管理任何类型的文件，甚至是大型二进制文件，而DVCS（任何类型的DVCS）最好只管理源代码。

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

Answer 4

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

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

你需要一个真正的 repo master，而不仅仅是有人监视源，而是了解SCM实际工作原理的人（不仅仅是GUI显示给他们）并且可以处理你的分支模型（见＃2）
采用/开发健全的分支模型。一个很好的例子，我用过的是http://nvie.com/posts/a-successful-git-branching-model/
你将不得不投入大量时间帮助你的开发人员重新学习他们认为你使用/与SCM交互的一切。

如果你能克服上面的三个，那么就会有很少的缺点（＃3是最难的。）至于@PAntoine，大多数问题都与训练有关 - ＃1需要一个真正糟糕的决定丢失源代码。 git reflog将为您提供对repo的每次提交的访问权限。销毁源代码的唯一方法是通过git reflog expire --expire=whatever refs/heads/master，git fsck --unreachable，git prune和git gc，这只应由repo master处理 - 然后是通用的开发商没有提交来源的问题（D'哦！）

Answer 5

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

这是ClearCase与Git讨论归结为什么。

可以这么说，你正在把苹果与橙子进行比较。

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

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

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

无论如何，一个好的VCS是任何SCM的支柱，因此从长远来看，你转向Git可能会有所收获。

Clearcase与Git版本控制

5 个答案: