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

Question

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

我代表这个特定问题的开发社区统计数据:<100个开发人员,<5个主要发布分支,<100个客户补丁分支,代码库大小:<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管理.

您可以在我的旧答案" 每个开发人员应该知道的基本ClearCase概念是什么？ "中看到Git与ClearCase相比.

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

• 合并工作流程(和分支策略).git-flow是最着名的,但肯定不是唯一的.
• 发布工作流,您管理同一个repo的多个实例(在git使用的分布式模型中,可以并且应该克隆repo).
  您可以推送到触发测试的QA仓库,然后再推送到受祝福的仓库,该仓库只接受"有效"提交(意味着您知道代码编译并通过测试).
  这是一种" 保护提交 "方法,用于持续集成或代码审查.

不要忘记,在分布式模型中,您有其他元数据无法通过设计获得:与身份验证或授权相关的任何内容都已消失,我详细介绍了" 分布式版本控制系统和企业 - 一个好的组合？ ".

• 标签:那些是用git标签完成的(对于所有的repo)
• 属性:由git notes管理,或由专用分支或专用r​​epos管理.
• UCM基线:再次标记(如果要将它们与常规标签区分开,则使用命名约定)
• 超链接:git中不需要(标记引用提交而没有任何中间"超链接").合并被记忆为具有两个父提交的"合并提交",这清楚地表明合并的敏感性.
  由于git中没有父/子流(只有分支),因此您没有相同的"传递/重新定义"语义.

请记住:在git中,repo类似于UCM组件.