3

在我之前的开发者生涯中，clearcase 是 10 多年的版本控制工具。现在，我工作的组织已经迁移到 git 已有 4 年了。在清晰的情况下，有易于访问的元数据结构，例如所有级别的项目的属性，例如存储库或分支或标签。git notes 存在，但是经过一些网上冲浪后，我没有找到任何有效的好方法以及为什么。例如，UCM ClearCase 基线提升级别是一个很好的概念，我希望它在 git 中也很简单。

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

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

在明确情况下，存在以下元数据结构：

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

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

    • label 属性，可以有任何值，常用用法：告诉一个标签的状态：TEST_RESULT:OK|NOK or 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 清晰的分支 + 属性
4

1 回答 1

5

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

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

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

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

不要忘记，在分布式模型中，您还有其他设计无法使用的元数据：与身份验证或授权相关的任何内容都消失了，正如我在“分布式版本控制系统和企业 - 一个很好的组合？ ”中详述的那样。

  • 标签：这些是用 git tag 完成的（对于所有 repo）
  • 属性：由 git notes 管理，或使用专用分支或专用 repos。
  • UCM 基线：再次标记（如果您想将它们与常规标签区分开来，请使用命名约定）
  • 超链接：在 git 中不需要（标签引用了没有任何中间“超链接”的提交）。合并被记忆为带有两个父提交的“合并提交”，这清楚地表明了合并的意义。
    由于 git 中没有父/子流（只有分支），因此您没有相同的“交付/变基”语义。

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

于 2016-03-30T16:59:50.413 回答