git - 灵活与静态分支(Git与Clearcase/Accurev)

Question

我的问题是有关Git处理分支的方式:无论何时从提交分支开始，除非您通过合并强制执行，否则该分支永远不会收到父分支的更改。

但是在其他诸如Clearcase或Accurev这样的系统中，您可以指定如何用某种继承机制填充分支:我的意思是，对于Clearcase，您可以使用config_spec来说“获取在分支/ main / issue001上修改的所有文件，然后然后继续使用/ main或此特定基准上的那些”。

在Accurev中，您还可以使用类似的机制，使流从上级分支接收更改(流如何称呼它们)，而无需在分支上合并或创建新的提交。

您在使用Git时不会错过吗？您能否列举必须继承的场景？

谢谢

更新请阅读下面的VonC答案以真正解决我的问题。一旦我们同意“线性存储”和基于DAG的SCM具有不同的功能，我的问题就是:哪些是现实生活中的场景(尤其是对于OSS以外的公司而言)，线性可以为DAG做些不可能的事情？他们值得吗？

Answer 1

要了解Git为什么不提供某种您所谓的“继承机制”(不涉及提交)，您必须首先了解这些SCM的 core concepts 之一(例如，Git与ClearCase)

ClearCase使用线性版本存储:元素(文件或目录)的每个版本都与该元素的先前版本以直接线性关系链接。

Git使用 DAG-Directed Acyclic Graph :文件的每个“版本”实际上都是树中全局更改集的一部分，而树本身就是提交的一部分。必须在先前的提交中找到它的先前版本，可以通过单个有向无环图路径访问该先前提交。

在线性系统中，配置规范可以指定一些规则来实现您看到的“继承性”(对于给定的文件，请首先选择某个版本，如果不存在，则选择另一个版本，如果不存在，则选择一个版本。第三，依此类推)。

分支在给定选择规则的给定版本的线性历史记录中为fork(该选择规则之前的所有其他选择规则仍然适用，因此具有“继承性”效果)

在DAG中，提交代表您将获得的所有“继承”。没有“累积”版本选择。在此图中只有一个路径可以选择您将在此确切点(提交)看到的所有文件。
分支只是该图中的新路径。

要在Git中应用其他版本，您必须:

合并到您的分支中(例如stsquad's answer提到的git pull中的其他提交)或

重新设置分支(作为Greg mentions)

但是由于Git是基于DAG的SCM，它将始终导致新的提交。

使用Git所“失去”的是某种“组成”(当您选择具有不同连续选择规则的不同版本时)，但是在 D VCS中(如“分布式”中)，这是不实际的:您在使用Git进行分支时，需要以一个起点和明确定义的内容以及可以轻松复制到其他存储库的方式进行。

在纯中央VCS中，您可以使用所需的任何规则定义工作区(在ClearCase中，快照或动态的“ View ”)。

unknown-google在注释中(以及上面的问题中)添加:

So, once we see the two models can achieve different things (linear vs DAG), my question is: which are the real life scenarios (especially for companies more than OSS) where linear can do things not possible for DAG? Are they worth it?

对于选择规则而言的“真实场景”，您可以在线性模型中为同一组文件设置多个选择规则。

考虑以下“配置规范”(即使用ClearCase的选择规则的“配置规范”):

element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... aLabel2 -mkbranch myNewBranch

它选择所有标记为“aLabel2”的文件(并从那里分支)，除了那些标记为“aLabel3”的文件-然后从那里分支(因为该规则在提到“aLabel2”的文件之前)。

这值得么？

没有。

实际上，出于简化的原因，UCM风格的ClearCase(ClearCase产品随附的“ Unified Configuration Management ”方法论，代表了从基本ClearCase使用中得出的所有“最佳实践”)不允许这样做。一组文件称为“组件”，如果要分支给定标签(称为“基准”)，则将按照以下配置说明进行翻译:

element /aPath/... .../myNewBranch
element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... /main/0 -mkbranch myNewBranch

您必须选择一个起点(此处为“aLabel3”)，然后从那里开始。
如果您还想要来自aLabel2的文件，则将所有aLabel2的文件合并到myNewBranch中的文件。

这是您不必使用DAG进行的“简化”，在DAG中，图的每个节点代表分支的唯一定义的“起点”，而与所涉及的文件集无关。

合并和变基足以将起点与给定文件集的其他版本组合在一起，以实现所需的“组成”，同时将特定历史记录隔离在分支中。

总体目标是推断“应用于一致性组件的一致性版本控制操作”。
一个“连贯”的文件集是处于定义良好的连贯状态的文件:

(如果已标记)，，所有，其文件都标记为

(如果分支)，所有，其文件将从相同的唯一起始点

分支

在DAG系统中很容易做到；在线性系统中(尤其是使用“Base ClearCase”，其中的“config spec”可能很棘手)，这可能会更加困难，但是它是使用同一线性工具的UCM方法实现的。

而不是通过“专用选择规则技巧”(使用ClearCase，某些选择规则顺序)来实现该“组合”，而是仅通过VCS操作(变基或合并)来实现它，从而使每个人都可以清楚地追踪(相对)开发人员专用的配置规范，或在某些但不是所有开发人员之间共享的规范)。
再次，它增强了一致性感觉，而不是“动态灵活性”，因此稍后可能很难在上进行再现。

这样，您就可以离开VCS (Version Control System) Realm 并进入SCM (Software Configuration Management) Realm ，该 Realm 主要与“可复制性”有关。而且(SCM功能)可以使用基于线性或基于DAG的VCS来实现。