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

Question

我的问题是关于Git处理分支的方式:无论何时从提交分支,此分支都不会从父分支接收更改,除非您通过合并强制它.

但是在其他系统如Clearcase或Accurev中,您可以指定分支如何填充某种继承机制:我的意思是,使用Clearcase,使用config_spec,您可以说"获取在分支/ main/issue001上修改的所有文件"然后继续使用/ main或具有此特定基线的那些".

在Accurev中,您还有一个类似的机制,让流可以从上层分支(流如何调用它们)接收更改,而无需在分支上合并或创建新的提交.

使用Git时不要错过这个吗？你能枚举这种继承是必须的场景吗？

谢谢

更新请阅读下面的VonC答案,以实际关注我的问题.一旦我们同意"线性存储"和基于DAG的SCM具有不同的功能,我的问题是:哪些是真实生活场景(特别是对于OSS以外的公司),线性可以做DAG无法做到的事情？他们值得吗？

Answer 1

要理解为什么Git不提供某种你所称的"继承机制"(不涉及提交),你必须先了解这些SCM 的核心概念之一(例如Git vs. ClearCase)

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

• Git使用DAG - Directed Acyclic Graph:文件的每个"版本"实际上是树的全局变更集的一部分,树本身就是提交的一部分.必须在先前的提交中找到其先前版本,可通过单个有向非循环图路径访问.

在线性系统中,配置规范可以指定几个规则来实现您看到的"继承"(对于给定文件,首先选择某个版本,如果不存在,则选择另一个版本,如果不存在,则选择一个第三,等等).

该分支是一个叉的线性历史给定的选择规则的特定版本(所有其他选择规则之前一个仍然适用,因而有"继承"效果)

在DAG中,提交代表了您将获得的所有"继承"; 没有"累积"的版本选择.此图中只有一个路径可以选择您将在此确切位置(提交)看到的所有文件.
分支只是此图中的新路径.

要在Git中应用其他一些版本,您必须:

• 合并到你的分支一些其他提交(如在stsquad的回答中提到的git pull )或
• 改变你的分支(格雷格提到)

但由于Git是基于DAG的SCM,因此它总是会导致新的提交.

你在Git中"丢失"的是某种"组合"(当你选择具有不同连续选择规则的不同版本时),但这在D VCS 中是不实际的(如"分布式"):当你是使用Git创建分支,您需要使用起点和明确定义的内容并轻松复制到其他存储库.

在纯粹的中央VCS中,您可以使用您想要的任何规则定义工作区(在ClearCase中,您的"视图",快照或动态).

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

所以,一旦我们看到这两个模型可以实现不同的东西(线性与DAG),我的问题是:哪些是真实生活场景(特别是对于OSS以外的公司),线性可以做DAG不可能的事情？他们值得吗？

当谈到选择规则方面的"真实场景"时,你可以在线性模型中做的是为同一组文件设置几个选择规则.

考虑这个"配置规范"(即使用ClearCase选择规则的"配置规范"):

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

它选择标记为' aLabel2'(并从那里开始分支)的所有文件,除了那些标记为' aLabel3' - 并从那里分支的文件 - (因为该规则在提及' aLabel2' 之前).

这值得么？

没有.

实际上,出于简化的原因,ClearCase的UCM风格(ClearCase产品中包含的" 统一配置管理 "方法,并代表从ClearCase基础使用中推断出的所有"最佳实践")不允许它.一组文件称为"组件",如果要为给定标签(称为"基线")进行分支,则将按照以下配置规范进行转换:

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

你必须选择一个起点(这里,' aLabel3')并从那里开始.如果你还需要来自' aLabel2' 的文件,你将从所有' aLabel2'文件合并到'myNewBranch'中的文件.

这是您不必使用DAG进行的"简化",其中图表的每个节点代表分支的唯一定义的"起点",无论涉及哪个文件集.

合并和重订够到起点与一组给定文件的其他版本相结合,以达到理想的"成分",同时保持特定的历史孤立的一个分支.

总体目标是在" 应用于连贯组件的相干版本控制操作"中进行推理."连贯"的文件集是一个处于明确定义的相干状态的文件:

• 如果标记,则标记其所有文件
• 如果分支,它的所有文件将从相同的唯一起点分支

这很容易在DAG系统中完成; 在线性系统中可能更难(特别是"Base ClearCase",其中"配置规范"可能很棘手),但它是使用相同的基于线性的工具的UCM方法强制执行的.

不是通过"私有选择规则技巧"(使用ClearCase,一些选择规则顺序)实现"组合",而是仅通过VCS操作(rebase或merge)实现它,这为每个人留下了明确的痕迹(相反)一个配置规范专用于开发人员,或在一些但不是所有开发人员之间共享).同样,它强制执行一致性感,而不是"动态灵活性",以后您可能很难再现.

这允许您离开VCS(版本控制系统)领域并进入SCM(软件配置管理)领域,主要关注" 再现性 ".并且(SCM特征)可以通过基于线性或基于DAG的VCS实现.