灵活分支与静态分支（Git与Clearcase/Accurev）

我的问题是关于Git处理分支的方式：无论何时从提交分支，该分支都不会从父分支接收更改，除非您使用合并强制它

但在其他系统中，如us Clearcase或Accurev，您可以指定如何使用某种继承机制填充分支：我的意思是，使用Clearcase，使用配置规范，您可以说“在branch/main/issue001上修改所有文件，然后继续使用/main上的文件或此特定基线”

在Accurev中，您还有一个类似的机制，让流接收来自上层分支的更改（流如何调用它们），而无需在分支上合并或创建新的提交

在使用Git时，您不会错过这个吗？你能列举一些必须继承的场景吗

谢谢

---

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

听起来像是你要找的东西。从概念上讲，重定分支的基址会将其与原始分支点分离，并在其他某个点重新附着。（实际上，通过将分支的每个面片按顺序应用于新分支点，创建一组新面片来实现重基。）在您的示例中，您可以将分支重基到上部分支的当前尖端，这基本上是“继承”的对另一个分支所做的所有更改。

我不完全清楚您的要求，但听起来像是git的要求 跟踪语义是您想要的。当您从am原点分支时 您可以执行以下操作：

git-t-b我的分支机构来源/主

然后，未来的“git pull”将自动将源代码/主代码合并到您的 工作部门。然后可以使用“git cherry-v origin/master”查看 区别是什么。您可以在发布应用程序之前使用“git rebase” 更改以清理历史记录，但不应使用一次重新基

---

您的历史记录是公开的（即其他人正在关注该分支）。

我不确定您是否提出了任何问题，但您正在证明Accurev streams与Git（或SVN）分支是不同的工具。（我不知道Clearcase。）

例如，如您所说，使用Accurev时，您被迫使用某些工作流，这将为您提供Git不支持的可审核的更改历史记录。Accurev的继承使某些工作流更高效，而其他工作流则不可能

有了Git，您可以在本地repo或功能分支中分离探索性编码，Accurev不太支持这一点

---

不同的工具适用于不同的目的；询问每一个都有什么好处是很有用的。

要理解为什么Git不提供某种您称之为“继承机制”（不涉及提交），您必须首先了解这些SCM中的一个（例如Git与ClearCase）

• ClearCase使用线性版本存储：元素的每个版本（文件或目录）都和同一元素的前一个版本以直接线性关系链接

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

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

分支是线性历史中给定选择规则的给定版本中的一个分支（在此之前的所有其他选择规则仍然适用，因此“继承”效应）

在DAG中，提交代表您将获得的所有“继承”；没有“累积”版本选择。此图中只有一条路径可选择此时（提交）将看到的所有文件。
分支只是此图中的一条新路径

要在Git中应用某些其他版本，您必须：

• 合并到您的分支中一些其他提交（如所提到的git pull）或
• 重新设置分支机构的基础（如图所示）

但由于Git是一个基于DAG的SCM，它总是会导致新的提交

使用Git“丢失”的是某种“组合”（当您使用不同的连续选择规则选择不同的版本时），但这在DVCS（如“分布式”）中并不实用：当您使用Git创建分支时，您需要有一个清晰定义并易于复制到其他存储库的起点和内容

在一个纯粹的中央VCS中，您可以使用您想要的任何规则定义您的工作区（在ClearCase中，您的“视图”，快照或动态）

---

在评论中（以及在他上面的问题中）补充道：

因此，一旦我们看到这两个模型可以实现不同的事情（线性与DAG），我的问题是：在现实生活中，哪些场景（尤其是对于公司而不是OSS）线性可以实现DAG不可能实现的事情？它们值得吗

当涉及到选择规则方面的“现实场景”时，您可以在线性模型中为同一组文件使用多个选择规则

考虑这个“配置规范”（即ClearCase选择规则的“配置规范”）：

它选择所有标记为“

aLabel2

”的文件（并从那里分支），但标记为“

aLabel3

”的文件除外，并从那里分支

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

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

git checkout [< tree-ish >] [--] < paths >

$ git checkout master             
$ git checkout master~2 Makefile             
$ rm -f hello.c            
$ git checkout hello.c