与ClearCase相比，如何使用git元数据策略？ [英] How to use git metadata strategies compared to ClearCase ones?

问题描述

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

我为这个特定问题表示的开发社区统计信息：< / p> 100位开发者， 5个主要释放分支， 100个客户补丁分支，代码基础大小：< 1000000行代码。

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

明确地说下列元数据结构存在：

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

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

  
  
  • 标签属性，可以有任何值，常用用法：告诉标签状态：TEST_RESULT：OK | NOK或CUSTOMER_AVAILABILITY：GENERAL | LIMITED | INTERNAL_ONLY
  
  
  • 分支属性，常用用途：BRANCH_STATUS：ACTIVE | OBSOLETE
    
    

  • UCM基线304.ibm.com/support/docview.wss?uid=swg21135893rel =nofollow> https://www-304.ibm.com/support/docview.wss?uid=swg21135893 ）
    

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

  特别是：
  
  

  
  
  • 可用于TEST_RESULT的标签+属性构造
  
  
  • 可以带来BRANCH_STATUS清晰度的分支+属性
  
  
  
  

  解决方案

  +年，git 7年以上，git是关于简单的元数据：标签，分支，blob，提交，日期，作者，执行位，...几乎是它。
  
  任何附加属性将被git notes管理。
  
  

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

  
  
  

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

  
  
  • 合并工作流（和分支策略）。 git-flow 是最着名的一个，但肯定不是唯一的一个。
  
  
  • 发布工作流程，您管理同一个回购的多个实例（在git使用的分布式模型中，回购可以并应该克隆）。
    您可以推送到质量保证回购，其中进行测试触发，然后推到只有接受有效提交（这意味着你知道代码编译并通过测试）的祝福回购。
    
    这是一个防护提交方法，使用进行持续集成，或代码复审。 设计：任何与authenti相关的东西正如我在分布式版本控制系统和企业 - 一个好的组合？中所详述的那样， / p>
    
    

    ---

    
    
    
    
    
    • 标签：这些都是用git标签完成的所有回购）
    
    
    • 属性：由git笔记管理，或者专用分支机构或专用回购。 > UCM基线：再次标记（如果您想将它们与常规标签区分，则使用命名约定）
    
    
    • 超链接：git中不需要该标签引用没有任何中间超链接的提交）。合并记忆为合并提交，其中包含两个父提交，它们清楚地表明合并的敏感。
      
      由于git中没有父/子流（仅限分支），因此您没有b / b
      $ b

      请记住：在git中，回购与UCM组件类似。

      b $ b

      In my previous developer life, clearcase was the tool, during 10+ years, for version control. Now the organisation I work for have moved over to git since 4 years. In clearcase there are easy accessible metadata constructions such as attributes on all levels of items such as repositories OR branches OR labels. git notes exists, but after some web surfing I have not come across any clear good way of doing this efficiently and why. For example UCM ClearCase baseline promotion level is a good concept that I wish would be as simple in git.

      The development community stats I represent for this particular problem: < 100 developers, < 5 major release branches, < 100 customer patch branches, code base size: < 1000000 lines of code.

      Hence the need for some appropriate metadata strategy and tooling.

      In clearcase the following metadata constructs exist:

      • labels (common usage: pointing out all file revisions included in a external SW delivery)

      • attributes, can be applied to labels or branches:

        • label attribute, can have any values, common usage: telling the status of a label: TEST_RESULT:OK|NOK or CUSTOMER_AVAILABILITY:GENERAL|LIMITED|INTERNAL_ONLY
        • branch attribute, common usage: BRANCH_STATUS:ACTIVE|OBSOLETE

      • UCM baselines which is a form of label with a status attribute (see for example: https://www-304.ibm.com/support/docview.wss?uid=swg21135893)

      • hyperlinks (used to point merge directions for instance)

      In particular:

      • the label + attribute construction which can be used for TEST_RESULT
      • branch + attribute that can bring clarity on BRANCH_STATUS

      解决方案

      I confirm, after using ClearCase for 10+ years, and git for 7+ years that git is about simple metadata: tag, branch, blob, commit, date, author, execution bits, ... that is pretty much it.
      Any additional property would be managed by git notes.

      You can see Git compared to ClearCase in my old answer "What are the basic ClearCase concepts every developer should know?".

      Any release-management kind of metadata is either managed through:

      • merge workflow (and a branch strategy). git-flow is the most famous one, but certainly not the only one.
      • publication workflow, where you managed multiple instances of the same repo (in a distributed model used by git, a repo can and should be cloned around).
        You can push to a QA repo where tests are triggered, before pushing to the blessed repo, which only accepted "valid" commits (meaning you know the code compile and pass the test).
        This is a "guarded commits" approach, used for continuous integration, or code review.

      Don't forget that, in a distributed model, you have other metadata not available by design: anything related to authentication or authorization is gone, as I detail in "Distributed Version Control Systems and the Enterprise - a Good mix?".

      ---

      • labels: those are done with git tag (for the all repo)
      • attributes: managed by git notes, or with dedicated branches or with dedicated repos.
      • UCM baselines: again tags (with a naming convention if you want to distinguish them from regular labels)
      • hyperlinks: not needed in git (the tag reference the commit without any intermediate "hyperlink"). The merges are memorized as "merge commit" with tow parent commits, which clearly indicate the sens of the merge.
        Since there are no parent/children stream in git (only branches), you do not have the same "deliver/rebase" semantic.

      Remember: in git, a repo is similar to an UCM component.

      这篇关于与ClearCase相比，如何使用git元数据策略？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！