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

Question

在我之前的开发人员生活中，clearcase是10年以上用于版本控制的工具。现在，我工作的组织已经转移到git 4年了。在clearcase中，有易于访问的元数据结构，例如所有级别的项目上的属性，例如存储库或分支OR标签。 git笔记存在，但经过一些网上冲浪，我没有遇到任何明确的有效方法，以及为什么这样做。例如，UCM ClearCase基线升级级别是一个很好的概念，我希望在git中这么简单。

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

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

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

• 标签（常用用法：指出外部SW交付中包含的所有文件修订版）

• 属性，可以应用于标签或分支：

  • label属性，可以有任何值，常用用法：告诉标签的状态：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

Answer 1

我确认，使用ClearCase 10年以上，git已经7年多了，git是关于简单的元数据：标签，分支，blob，提交，日期，作者，执行位，......这几乎就是它。
任何其他财产都将由git notes管理。

你可以在我的旧答案“What are the basic ClearCase concepts every developer should know?”中看到Git与ClearCase相比。

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

• 合并工作流程（以及branch strategy）。 git-flow是最着名的，但certainly not the only one。
• 发布工作流，您管理同一个仓库的多个实例（在git使用的分布式模型中，可以并且应该克隆回购）。
  您可以推送到触发测试的QA仓库，然后再推送到受祝福的仓库，该仓库只接受“有效”提交（意味着您知道代码编译并通过测试）。
  这是一种“保护提交”方法，使用for continuous integration或code review。

不要忘记，在分布式模型中，您有其他元数据无法通过设计获得：与身份验证或授权相关的任何内容都已消失，我详细介绍了“Distributed Version Control Systems and the Enterprise - a Good mix?”。

• 标签：这些是使用git标签完成的（适用于所有代表）
• 属性：由git notes管理，或由专门的分支机构或专用的repos管理。
• UCM基线：再次标记（如果您想将它们与常规标签区分开来，则使用命名约定）
• 超链接：git中不需要（标签引用没有任何中间“超链接”的提交）。合并被记忆为“合并提交”，其中包含两个父提交，这清楚地表明了合并的敏感性 由于git中没有父/子流（只有分支），因此您没有相同的“传递/重新定义”语义。

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