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

Question

我的问题是关于 Git 处理分支的方式：每当您从提交分支时，该分支都不会收到来自父分支的更改，除非您强制进行合并。

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

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

使用 Git 的时候你不会错过这一点吗？ 您能否列举出必须继承的场景？

谢谢

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

Answer 1

要理解为什么 Git 不提供某种您所说的“继承机制”（不涉及提交），您必须首先了解 这些 SCM 的核心概念（例如 Git 与 ClearCase） )

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

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

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

该分支是分叉，位于线性历史记录中给定选择规则的给定版本（该规则之前的所有其他选择规则仍然适用，因此具有“继承”效果）

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

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

• 将一些其他提交合并到您的分支中（例如 stsquad 的答案）或
• 重新调整您的分支（如 Greg 提到）

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

你正在“失去什么” ”与 Git 是某种“组合”（当您使用不同的连续选择规则选择不同版本时），但这在 DVCS 中不切实际（如“分布式”）：如果您使用 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 操作（变基或合并）来实现它，这会留下清晰的痕迹供每个人遵循（与开发人员私有的配置规范，或在一些但不是所有开发人员之间共享的配置规范）。
它再次强调了一种连贯性，而不是“动态灵活性”，您以后可能很难重现这种感觉。

这允许您离开 VCS（版本控制系统） 领域并进入 < a href="http://en.wikipedia.org/wiki/Software_Configuration_Management" rel="nofollow noreferrer">SCM（软件配置管理），主要关注“再现性” ”。 而这一点（SCM 功能）可以通过基于线性或基于 DAG 的 VCS 来实现。

Answer 2

听起来您要找的可能是 git rebase。 变基分支在概念上将其从原始分支点分离，并在其他点重新连接。 （实际上，变基是通过将分支的每个补丁按顺序应用到新分支点，创建一组新的补丁来实现的。）在您的示例中，您可以将分支变基到上分支的当前尖端，这本质上会“继承”对另一个分支所做的所有更改。

Answer 3

我不太清楚你的要求，但这听起来像是 git 的
跟踪语义就是你想要的。 当你从 am 原点分支时
你可以这样做：

git -t -b my_branch origin/master

然后未来的“git pull”将自动将 origin/master 合并到你的
工作分支机构。 然后你可以使用“gitcherry-vorigin/master”来查看
有什么区别。 您可以在发布之前使用“git rebase”
进行更改以清理历史记录，但不应使用一次 rebase
您的历史记录是公开的（即其他人正在关注该分支）。

Answer 4

至于 Accurev 使用的继承方案：当查看 git-flow 时，GIT 用户可能会“了解”整个内容 （另请参阅：http://github.com/nvie/gitflow 和 http://jeffkreeftmeijer.com/2010/why-arent-you-using -git-flow/）

这个 GIT 分支模型或多或少（手动/在 git-flow 工具的帮助下）实现了 Accurev 自动开箱即用的功能，并且很棒 GUI 支持。

所以看起来 GIT 可以做 Accurev 所做的事情。 由于我从未真正日常使用过 git/git-flow ，所以我不能真正说出它是如何工作的，但它看起来确实很有希望。 （减去适当的 GUI 支持:-)

Answer 5

我会尽力回答你的问题。 （这里我必须说，我没有使用过GIT，只是读过它，所以如果我下面提到的内容有误，请纠正我）

“你能列举出必须继承的场景吗？”

我不会说这是必须的，因为您可以使用现有的工具解决问题，并且可能是适合您的环境的有效解决方案。 我想这更多的是流程的问题，而不是工具本身的问题。 确保您的流程是连贯的，并且还允许您及时返回以重现任何中间步骤/状态是我们的目标，而且该工具的优点是该工具可以让您尽可能轻松地运行您的流程和 SCMP

我可以的一个场景当您希望将一组更改“隔离”映射到任务（ devtask、CR、SR 或任何定义更改集的目的/范围的内容）

使用此组合可以让您的开发分支变得干净，并且仍然使用其余代码的不同组合（使用组合），并且仍然具有 在任务的整个生命周期中，仅将与任务相关的内容隔离在分支中，直到集成阶段。

作为纯粹主义者，必须提交/合并/变基只是为了有一个“定义的起点”，我想这会“污染”你的分支，你最终会得到你的更改+你的分支中的其他更改/更改设置。

这种隔离何时/何地有用？
以下几点可能仅在追求 CMM 和某些 ISO 认证的公司的背景下才有意义，对于其他类型的公司或 OSS 可能没有兴趣

• 由于非常挑剔，您可能需要准确计算代码行数 (添加/修改/删除）对应于单个开发人员的更改集，稍后用作代码和工作量估计的一个输入。

• 仅将您的代码放在单个分支中（不与其他更改粘合），可以更轻松地在不同阶段审查代码

  仅将

在由多个团队和超过 500 名开发人员积极同时处理相同基本代码的大型项目中（其中图形化的单个元素版本树看起来像一个杂乱的网络，有多个负载线，每个负载线一个）大客户，或每种技术一个）使用多个深度组合的大型配置规范使得这么多人无缝地工作以将相同的产品/系统（基本代码）适应不同的目的。 使用此配置规范，动态地为每个团队或子团队提供他们需要的内容和需要分支的不同视图（在几种情况下级联），无需创建中间集成分支，或不断合并和重新建立所有分支您需要开始的部分。 来自同一任务/目的的代码是不同标签的分支，但有意义。 （您可以在这里争论“已知基线”作为 SCM 的原则，但书面 SCM 计划中设想的简单标签就完成了工作）
一定可以用 GIT 解决这个问题（我猜是以非动态方式），但我发现如果没有这种“继承”行为，我真的很难想象。
我猜 VonC 提到的“如果分支，它的所有文件将从相同的唯一起点分支”在这里被打破了，但除了 SCMP 上有详细记录之外，我记得这样做有很强的商业理由。

是的，构建我上面提到的这些配置规范并不是免费的，一开始有 4-5 个高薪人员在 SCM 后面，但后来通过自动脚本减少了数量，这些脚本会询问您想要什么标签/分支/功能，并将为你写CS。

这里的可重复性是通过将配置规范与任务一起保存在 devTask 系统中来实现的，因此每个任务上游映射到需求，下游映射到配置规范，一组更改（代码文件、设计文档、测试文档）等等）

因此，到目前为止，这里的一个结论可能是，只有当您的项目足够大/复杂时（并且您可以在项目的整个生命周期中负担得起 SC 经理的费用:)），那么您才会开始考虑是否需要“继承”行为或真正多功能的工具，否则你将直接使用免费的工具，并且已经照顾了你的 SCM 的一致性
...但是 SCM 工具上可能还有其他因素，可能会让您坚持使用一个或另一个...继续阅读...

一些旁注，这可能超出主题，但我想在某些情况下，比如我的需要予以考虑。

我必须在这里补充一点，我们使用“good-ol CC”而不是UCM。 完全同意 VonC 的观点，良好的方法可以“引导”灵活性，实现更一致的配置。 好处是 CC 非常灵活，您可以找到（不费吹灰之力）一种使事物保持一致的好方法，而在其他 SCM 中您可能可以免费获得它。
但例如在这里（以及我使用 CC 的其他地方），对于 C/C++ 项目，我们无法承担没有 winkin 功能（重用 Derive 对象）的代价，这会减少几个 X次编译时间。 可以说，拥有更好的设计、更加解耦的代码和优化 Makefile 可以减少编译整个东西的需要，但有些情况下，您需要每天多次编译整个野兽，并共享 DO 保存大量的时间/金钱。
我现在的情况是，我们尝试尽可能多地使用免费工具，并且我认为，如果我们能找到一个更便宜或免费的工具来实现 winkin 功能，我们就会摆脱 CC。

我将以 Paul 提到的一些内容作为结尾，对于不同的目的，不同的工具比其他工具更好，但我要补充的是，您可以通过具有连贯的过程且不牺牲可重复性来摆脱工具的某些限制、SCM关键点
最后我猜这个问题的答案值得吗？取决于你的“问题”、你正在运行的SDLC、你的SCM流程，以及是否有任何额外的功能（比如winkin）在您的环境中有用。

我的 2 美分

Answer 6

撇开理论不谈，从我多年来在商业生产环境中使用 AccuRev 的角度来看，这里有一种明显的实际做法：只要子流与祖先流没有太大分歧，继承模型就可以很好地工作。仍在开发中。 当继承流差异太大时，它就会崩溃。

继承（更高版本作为早期版本的子版本）允许祖先流中的更改在子流中处于活动状态，而无需任何人执行任何操作（除非需要合并，在这种情况下它显示为深度重叠，这很高兴能够看到）。

这听起来很棒，而且在实践中也确实如此，因为涉及的所有流都相对相似。 我们将该模型用于给定生产版本以下的修补程序和服务包级别流。 （对于我们来说，这实际上比这更复杂，但这是总体思路。）

生产版本是并行的，没有继承，每个修补程序和服务包子版本都在它们下面。 启动新版本意味着创建新的版本级别流，并手动将先前版本的最新维护流中的所有内容推送到其中。 此后，对早期版本的更改适用于以后的版本，必须手动推送到每个版本中，这需要更多的工作，但允许更大的控制。

我们最初在所有版本中使用继承模型，其中后来的版本是早期版本的子版本。 这在一段时间内运作良好，但随着时间的推移变得难以管理。 各个版本之间的主要架构差异使得继承更改不可避免地成为一个坏主意。 是的，您可以在中间放置快照来阻止继承，但是所有更改都必须手动推送，并且父快照子流和并行非继承流之间的唯一真正区别在于整个图形流视图不断下推右边是 PITA。

AccuRev 的一大好处是您始终拥有这种选择。 它不是 SCM 程序架构的固有约束。

Answer 7

您是否注意到您也可以使用 GIT 查看特定文件版本？

只需使用这个：

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

就像每个配置规范一样，文件（路径）的任何现有版本都可以加载到工作树中。 引自 git-checkout 文档：

以下序列检查 master 分支，将 Makefile 恢复到两个修订版，错误地删除 hello.c ，然后从索引中取回它：

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

Answer 8

ClearCase 没有 MultiSite，是一个单一存储库，但 Git 是分布式的。 ClearCase 在文件级别提交，而 Git 在存储库级别提交。 （最后一个区别意味着最初的问题是基于误解，正如其他帖子中指出的那样。）

如果这些是我们正在讨论的差异，那么我认为“线性”与“DAG”是一种令人困惑的区分方式这些单片机系统。 在 ClearCase 中，文件的所有版本都称为文件的版本“树”，但实际上它是一个有向无环图！ 与 Git 的真正区别在于 ClearCase 的 DAG 存在于每个文件中。 因此，我认为将 ClearCase 称为非 DAG 而将 Git 称为 DAG 是一种误导。

（顺便说一句，ClearCase 的目录版本与文件版本类似 - 但那是另一个故事了。）

Answer 9

我不确定您是否在问什么，但您正在证明 Accurev 流是与 Git（或 SVN）分支不同的工具。 （我不知道 Clearcase。）

例如，正如您所说，使用 Accurev，您被迫使用某些工作流程，这为您提供了 Git 不支持的可审计的更改历史记录。 Accurev 的继承使某些工作流程更加高效，而另一些则不可能。

使用 Git，您可以将探索性编码隔离在本地存储库或功能分支中，而 Accurev 不能很好地支持这一点。

不同的工具有不同的用途； 询问每一个的优点是很有用的。