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

在我以前的开发人员生涯中，clearcase是10多年来版本控制的工具。现在，我工作的组织已经从4年前转移到git。在clearcase中，有易于访问的元数据结构，例如所有级别的项目（如存储库、分支或标签）上的属性。git notes是存在的，但在一些网上冲浪之后，我还没有找到任何明确的好方法来有效地实现这一点，以及为什么。例如，UCM ClearCase基线提升级别是一个很好的概念，我希望在git中也能如此简单

我代表的开发社区统计数据针对这个特定问题：<100个开发人员，<5个主要发布分支，<100个客户补丁分支，代码基本大小：<1000000行代码

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

在clearcase中，存在以下元数据构造：

• 标签（常见用法：指出外部软件交付中包含的所有文件修订）
• 属性，可应用于标签或分支：
  • 标签属性，可以有任何值，常用用法：告知标签状态：测试结果：OK | NOK或客户可用性：GENERAL | LIMITED | INTERNAL |
  • 分支属性，常用用法：分支|状态：活动|过时
• UCM基线是带有状态属性的标签形式 （参见示例：）

• 超链接（例如用于指向合并方向）

特别是：

• 可用于测试结果的标签+属性结构
• branch+属性，可清晰显示分支机构的状态

---

在使用ClearCase 10多年，使用git 7年以上之后，我确认git是关于简单元数据的：标记、分支、blob、提交、日期、作者、执行位。。。差不多就是这样。
任何附加属性都将由git notes管理

您可以在我的旧答案“”中看到Git与ClearCase的比较

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

• 合并工作流（和a）。是最有名的，但是
• 发布工作流，您可以在其中管理同一repo的多个实例（在git使用的分布式模型中，repo可以也应该被克隆）。
  您可以推送到触发测试的QA repo，然后再推送到受祝福的repo，该repo只接受“有效”提交（意味着您知道代码编译并通过测试）。
  这是一种“受保护的提交”“方法，用于或

不要忘记，在分布式模型中，您还有其他设计上不可用的元数据：与身份验证或授权相关的任何内容都消失了，如我在“”中详细介绍的

---

• 标签：使用git标签完成（用于所有回购）
• 属性：由git notes管理，或通过专用分支机构或专用回购进行管理
• UCM基线：再次标记（如果要将其与常规标签区分开来，请使用命名约定）
• 超链接：git中不需要（标记引用提交，但没有任何中间“超链接”）。合并被记忆为“合并提交”，有两个父提交，这清楚地表明了合并的意义。
  由于git中没有父流/子流（只有分支），因此您没有相同的“交付/重基”语义

---

记住：在git中，repo类似于UCM组件。

对于我们这些不熟悉clearcase的人，你能举个例子说明你想要维护哪种元数据吗？这可能有助于我们提供更好的答案。我已经编辑了您的标题，因为上一个标题会立即要求关闭该问题。@VonC感谢您。这是一个很晚的主题，但无论如何。你能不能就“属性：由git notes管理，或使用专用分支或专用回购”这一主题展开讨论，谈谈如何实现这些机制。高效可持续设置的重要细节是什么？@Mike基本上：分支可以代表开发生命周期的不同状态。感谢更广泛的视角。在上面描述的文章中，我发现“标记标签”一节在标记问题上有点触及问题…@Mike git repo中的标记相当于UCM基线（完整的，不是增量的），除非您没有与之关联的状态，也没有超链接。