如何使用Git元数据策略与ClearCase相比？

Question

如何使用Git元数据策略与ClearCase相比？

gitperformancemetadataclearcase-ucmgit-notes

3

在我之前的开发生涯中，ClearCase是版本控制工具，在10多年里一直使用。现在我所在的组织已经转移到Git上已经有4年了。在ClearCase中，有易于访问的元数据结构，例如存储库、分支或标签等各个级别上的属性。Git笔记存在，但在浏览了一些网页后，我并没有找到任何明确的好方法来高效地实现这一点，也不知道为什么。例如，UCM ClearCase基线推广级别是一个好的概念，我希望在Git中能够像这样简单。

我代表特定问题的开发社区统计数据如下：小于100个开发人员，小于5个主要发布分支，小于100个客户补丁分支，代码库大小小于1000000行。

因此需要一些适当的元数据策略和工具。

在ClearCase中存在以下元数据结构：

标签（通常用于指出包含在外部软件交付中的所有文件修订版本）
属性，可应用于标签或分支：
- 标签属性可以有任何值，通常用于说明标签的状态：TEST_RESULT:OK|NOK或CUSTOMER_AVAILABILITY:GENERAL|LIMITED|INTERNAL_ONLY
- 分支属性通常用于说明分支的状态：BRANCH_STATUS:ACTIVE|OBSOLETE
UCM基线是一种带有状态属性的标签形式（例如，请参阅https://www-304.ibm.com/support/docview.wss?uid=swg21135893）
超链接（用于指向合并方向等）

特别地：

标签+属性结构可用于TEST_RESULT。
分支+属性可在BRANCH_STATUS方面提供清晰度。

- Mike

2

对于那些不熟悉ClearCase的人，你能举个例子说明你想要维护哪种元数据吗？这可能有助于我们提供更好的答案。 - larsks

1

我已经修改了你的标题，因为之前的标题会立即引起问题被关闭的问题。 - VonC

@VonC 谢谢你。虽然有点晚了，但无论如何。 - Mike

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

我确认，在使用ClearCase十多年和Git七多年后，Git只涉及简单的元数据：标签、分支、blob、提交、日期、作者、执行位等等。这基本上就是全部。
任何其他属性都将由Git notes进行管理。

您可以在我的旧回答 "What are the basic ClearCase concepts every developer should know?" 中看到Git与ClearCase的比较。

任何类似于发布管理的元数据都通过以下方式进行管理：

合并工作流程（以及分支策略）。Git Flow 是最著名的一种，但绝不是唯一的一种。
发布工作流程，您可以管理同一代码库的多个实例（在 Git 使用的分布式模型中，应克隆代码库）。
您可以将代码推送到 QA 代码库，触发测试，然后再将其推送到受信任的代码库，只接受“有效”提交（这意味着您知道代码编译并通过了测试）。
这是一种“保护提交”方法，用于持续集成或代码审查。

不要忘记，在分布式模型中，您有其他设计上不可用的元数据：与身份验证或授权相关的任何内容都已消失，如我在“分布式版本控制系统和企业-良好的组合？”中详细说明。

标签：使用git tag进行操作（适用于整个仓库）
属性：通过git notes进行管理，或使用专门的分支或专门的仓库。
UCM基线：同样是标签（如果您想将它们与常规标签区分开来，则需要使用命名约定）
超链接：在git中不需要（标签引用提交而没有任何中间“超链接”）。合并被记为“合并提交”，具有两个父提交，清楚地指示合并的方向。
由于git中没有父/子流（只有分支），因此您没有相同的“交付/变基”语义。

请记住：在git中，存储库类似于UCM组件。