要理解为什么 Git 不提供某种您所说的“继承机制”（不涉及提交），您必须首先了解其中一个核心概念这些 SCM（例如 Git 与 ClearCase）
在线性系统中，配置规范可以指定几个规则来实现您所看到的“继承”（对于给定文件，首先选择某个版本，如果不存在，则选择另一个版本，如果不存在，则选择一个第三，依此类推）。
该分支机构是一个fork in a linear历史记录给定选择规则的给定版本（该规则之前的所有其他选择规则仍然适用，因此具有“继承”效果）
在 DAG 中，一次提交代表您将获得的所有“继承”；没有“累积”版本选择。该图中只有一条路径可以选择您在此时（提交）将看到的所有文件。
分支只是该图中的一条新路径。
要在 Git 中应用某些其他版本，您必须：
- 将一些其他提交合并到您的分支中（例如在 git pull 中提到的）st小队的回答) or
- 重新调整你的分支的基础（如格雷格提到)
但由于 Git 是基于 DAG 的 SCM，因此它总是会产生新的提交。
使用 Git “丢失”的是某种“组合”（当您使用不同的连续选择规则选择不同版本时），但这在DVCS（如“分布式”）：当您使用 Git 创建分支时，您需要从一个起点开始和一个内容定义明确并易于复制到其他存储库。
在纯粹的中央 VCS 中，您可以使用您想要的任何规则来定义您的工作区（在 ClearCase 中，您的“视图”，快照或动态）。
未知的谷歌在评论中添加（以及在上面的问题中）：
因此，一旦我们看到这两个模型可以实现不同的目标（线性与 DAG），我的问题是：在现实生活中哪些场景（特别是对于 OSS 以外的公司）线性可以完成 DAG 无法完成的事情？他们值得吗？
当谈到选择规则的“现实场景”时，您可以在线性模型中做的是several评选规则对于同一组文件.
考虑这个“配置规范”（即使用 ClearCase 的选择规则的“配置规范”）：
element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... aLabel2 -mkbranch myNewBranch
它选择所有标记为 'aLabel2' （并从那里分支），除了那些标记为 'aLabel3' - 并从那里分支 - （因为该规则先于提到 'aLabel2').
这值得么？
No.
实际上，ClearCase 的 UCM 风格（“统一配置管理“ClearCase 产品中包含的方法，代表从基本 ClearCase 使用中推导出来的所有“最佳实践”）不允许这样做，原因是简单性。一组文件称为“组件”，如果您想针对给定标签（称为“基线”）进行分支，则可以像以下配置规范一样进行翻译：
element /aPath/... .../myNewBranch
element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... /main/0 -mkbranch myNewBranch
你必须选择one起点（这里，'aLabel3'）然后从那里开始。
如果您还想要来自 'aLabel2'，您将对所有 ' 进行合并aLabel2' 文件到 'myNewBranch' 中的文件。
这是您不必使用 DAG 进行的“简化”，其中图形的每个节点都代表分支的唯一定义的“起点”，无论涉及的文件集是什么。
合并和变基足以将该起点与给定文件集的其他版本结合起来，以实现所需的“组合”，同时保留特定的历史记录隔离中在一个分支机构。
总体目标是推理“coherent版本控制操作应用于coherent成分”。
一组“一致”的文件是处于明确定义的一致状态的文件：
- 如果有标签，all它的文件被标记
- 如果有分支，all它的文件将从同样独特初始点
这在 DAG 系统中很容易完成；在线性系统中这可能会更加困难（特别是对于“Base ClearCase”，其中“配置规范”可能很棘手），但它是通过同一基于线性的工具的 UCM 方法来强制执行的。
您不是通过“私有选择规则技巧”（使用 ClearCase，一些选择规则顺序）来实现“组合”，而是仅通过 VCS 操作（变基或合并）来实现它，这会留下清晰的痕迹供每个人遵循（与开发人员私有的配置规范，或在一些但不是所有开发人员之间共享的配置规范）。
再次，它强化了一种感觉连贯性, 与“动态灵活性”相反，您以后可能很难重现这种灵活性.
这可以让你离开这个领域VCS（版本控制系统）并进入领域SCM（软件配置管理），主要涉及“再现性”。并且（SCM 功能）可以通过基于线性或基于 DAG 的 VCS 来实现。
