如何同步.NET虚拟单体仓库，实现高效协作？

原文 | Přemek Vysoký 翻译 | 郑子铭 术语 让我们来看看本节剩余部分将用到的一些术语： 源代码/产品存储库– 当前开发存储库之一，例如dotnet/runtime。不是 VMR。 前向流程——将变更从产品存储库移动到虚拟存储库的过程。 回流– 将变更从 VMR 移动到产品存储库的过程。 代码流——指在虚拟存储库 (VMR) 和产品存储库之间传递变更的过程。这是一个通用术语，既可以指正向流，也可以指反向流。 代码流 PR – 指在代码流流程中发起的包含代码变更的拉取请求。它可以是正向流 PR，也可以是反向流 PR。 双向代码流 v1 代码流算法的第一版设计目标是，每次需要提交变更时，都必须能够在目标仓库中创建一个拉取请求。该拉取请求必须包含所需的变更，但可能与目标分支冲突。我们将展示后来我们如何意识到这是一个错误的指导原则，因为它引入了一些有趣的问题。 简而言之，该算法的工作原理是：我们使用上述跟踪元数据来追踪双方之间的最后数据流。然后，我们找到目标仓库中创建 PR 分支的正确位置（提交），将更改物化到该分支之上，并创建一个拉取请求。我们必须向您保证，如果双方之间存在冲突的更改，这些冲突也会出现在 PR 中。这意味着 PR 分支必须基于足够旧的提交，以便将源分支的提交和目标分支中的更改都引入到冲突状态。 代码流算法的第一个版本用于发布大部分 .NET 10 预览版以及 10.0 正式版。该算法会考虑前一个代码流的方向，并据此应用不同的策略。从技术上讲，有四种情况需要考虑（正向-正向、正向-反向、反向-正向、反向-反向），但后两种情况是对称的，因此我们不再单独讨论。 相反方向的流动 让我们先来看一个比前两种情况更复杂的场景——当有两个方向相反的流体流动时。本节中的图表使用以下符号： 🟠 橙色– 文件内容转换。文件以内容开头A，B -> C表示提交将内容从更改B为C。 🟢 绿色– 之前的成功流程。显示正在执行的提交（虚线）以及另一端 PR 分支将形成的样子（实线）。 🔵 蓝色——当前正在讨论的趋势。 🟣 紫色– 正在传递到对应存储库的差异。 ⚫ 灰色– 与被跟踪文件无关的提交。 提交记录按时间顺序编号。标记1和2通常表示之前的同步操作。 代码流程图显示了存储库和 VMR 之间的两个连续流程，每个流程的方向都不同。 图中的变化流程如下： 1并2表示之前的某个同步点。 4VMR 中的提交会将内容更改A为B。 5从这一点开始发生回流。 6仓库中创建了一个回流分支（绿色）。该分支基于上次同步的提交（1）。此流程的创建方式并非本图的重点。这里，我们关注的是以下流程：从该分支发起一个 PR。 7Backflow PR 已合并，有效地将仓库主分支中的更新A从A更新到。B 8仓库中执行了一次提交操作，将内容从更改B为C。 9VMR 中进行了一项无关的提交。 10从这一点开始，正向流动就此开始。 11在代码仓库中创建了一个前向流分支（蓝色）。该分支基于上次同步的（5）基本提交。从该分支打开了一个 PR。在前向流 PR 中进行了一次额外的提交，将的内容更改A为D。 12PR 已合并，有效更新A为。BD 您可以注意到以下几个特点： 没有出现 Git 冲突。这是因为这个具体示例只考虑了一个文件，该文件按时间顺序逐步更改A。D在大部分更改都发生在单个代码仓库的情况下，我们期望代码能够流畅地运行。 整个流程类似于开发人员在单个代码仓库的开发分支上工作。然后，开发人员向主分支（在本例中为主代码仓库）提交一个 PR。在单个代码仓库的情况下如果出现冲突，这里也会出现冲突，这是设计使然。 11接下来需要讨论的是如何创建正向分支的提交（ ）。我们知道，7在上次回流 PR 合并后，我们从仓库收到了作为提交一部分的增量。我们考虑到使用了压缩合并，因此提交可能不再可用。在提交和6之间，回流 PR 分支上也可能存在其他提交。当我们进行正向提交时，需要流出的变更集实际上包括提交、、和。基本上，就是仓库端所有尚未流入 VMR 的变更。它以和之间的紫色差异可视化。此差异正确地表示了增量，因为：6710367810106 它包含了 VMR 的最后一个已知快照（6） 自上次提交以来，VMR 中发生的所有提交——提交3和7。 8自同步以来，VMR 中发生的其他提交10。 正向分支的基础提交是上次回溯分支的基础提交，因为我们将增量更新应用到该回溯分支上。如果提交9与增量更新存在冲突，PR 会显示这些冲突，开发人员需要解决这些冲突。 两股流向相同方向 当有两个连续的、方向相同的流时，情况就简单一些： 代码流程图，展示了从代码库到虚拟存储库的两个连续流程。