ClearCase中分支和流之间的区别？

ClearCase中的分支和流之间有什么区别？

分支是一种经典的版本控制方法，用于并行化给定文件的版本历史：请参阅“”

A：它只是一个元数据，能够记住引用该流的任何视图将看到的基线。
创建流时，不会发生任何事情（不会创建分支）。
但是签出文件时将使用流名称：任何视图都将设置其配置规范，以便创建以流命名的分支，以便隔离流。
（见“”）

这就是为什么适当命名流很重要的原因：如果我创建一个名为“

VonC

”的流，您最终会看到（在任何修改文件的版本树中）一个名为“

VonC

”的分支：分支的目的是什么？
如果我创建一个名为“

REL2.2_-FIX

”的流，您将看到名为“

REL2.2_-FIX

”的分支，并将推断引用该流的任何视图都会在2.2版上生成补丁：这是一个更有用的名称。（这就是我不喜欢“”的原因）

因此，如果您有任何可写组件，可以将流视为分支的模板：

• 声明流中需要的内容（希望看到的基线）
• 您可以在该流上创建一个视图
• 任何签出都将创建一个以流命名的分支

（这就是为什么这么多UCM用户将“流”与“分支”混为一谈或等同起来的原因）

但是，如果您的项目中只有不可写组件，那么流就是您希望在所述流上创建的任何视图中看到的基线（组件上的标签）列表。
这将成为一种可视化机制，对于测试环境非常有用，您只需访问一组组件的精确版本即可测试系统。
在这种情况下，不会创建分支，因为不会对任何文件进行签出：组件在UCM项目中声明为不可写

---

流和分支之间的另一个主要区别是流在层次结构（父流/子流）中的组织
分支根本不存在这种层次结构：当您有3个分支

A

，

B

，

C

：

• 一旦完成分支

  A

  的工作，您就不知道从何处合并
• 您所做的任何合并都具有相同的含义：

  A->B

  ，或

  C->A

  ，或

  B->C

  ，或

使用Stream，您将有：

MyProject_Int
 |
 --MyProject_Dev
    |
    -- MyProject_Feature1

流的层次结构用于：

• 介绍一个可能的合并工作流（您知道从一个流合并到另一个流的位置：即其父流。这不是强制性的，但至少您有一种直观的方式知道：

  • Feature1

    一旦完全开发，将返回（合并到）

    MyProject\u Dev

    （其父流），并且：

  • MyProject\u Dev

    一旦达到稳定状态，就可以将其合并到父流

    MyProject\u Int

    ，在父流中，可以在

    MyProject\u Dev

    中不间断地进行开发的同时进行集成测试
• 为这些合并添加含义：
  • 从子流合并到其父流或任何其他父流（例如，如果必须，您可以直接从

    MyProject\u Feature1

    合并到

    MyProject\u Int

    ）被称为

    交付

  • 从父流（如

    MyProject\u Dev

    ）合并到直接子流（如（

    MyProject\u Feature1

    ）被称为

    rebase

    
    其目的是确保

    Feature1

    是根据

    Dev

    的最新变化开发的，以使最终交付尽可能轻松：有了常规的回退，公共代码集不会在从这两个流派生的这两个分支的两个并行历史之间出现太多分歧

请记住，这两个UCM操作

deliver

和

rebase

的核心只是两个分支

A

和

B

之间的简单合并
但是，由于它们的名称，您知道您不仅仅在任何两个分支之间合并，而是在子流和父流（

deliver

）之间合并，或者在父流和子流（

rebase

）之间合并