分支

软件开发人员通常使用版本控制系统在代码库中协调工作。这使得多个工程师可以安全地对同一代码进行贡献。

在 Foundry 中，我们以软件开发人员对待代码的方式来看待数据：您需要一种方法来允许多人更改和交互同一数据而不干扰他人的工作。我们从软件开发中借鉴最佳实践，并将其应用于编写数据管道，利用版本控制系统的一个常见功能，称为分支。

从高层次来看，分支允许您在自己的分支上对数据进行变换。然后，一旦您对自己的更改感到满意，您可以将更改从自己的分支推送回主干。

分支工作流程

如何在 Foundry 中使用分支工作流程更改数据管道代码：

branching example

创建分支。在 Foundry 中，master 分支指的是主数据管道。当您想要进行自己的更改时，您创建自己的分支，这为您提供了一个环境来实验和测试想法，而不必担心影响 master 分支。
创建提交。在您的分支中，您可以对数据变换进行更改。更改，包括添加和删除，称为提交。您的提交会被跟踪，以便清楚记录您在分支上所做的所有更改的历史。
创建拉取请求。一旦您完成了独立工作，您将希望将更改推回到 master 分支。要开始此过程，您需要创建一个拉取请求。拉取请求向您的团队发出信号，表明您已进行了更改，希望他们审核并验证 master 数据管道。
代码审核。在您创建拉取请求后，您的团队将有机会审核您的提交。每个组织将有不同的流程或团队来审核拉取请求。

Foundry 分支实施了一个行业标准的类似 Git 的版本控制模式。因此，代码库应用程序被设计为每个文件上的一个独立分支有一个活跃的开发者。如果其他用户在您的**personal 分支**上工作，您的更改可能会被覆盖。为避免这种情况，我们强烈建议每个人在一个独立的分支上工作。

本页的其余部分描述了 Foundry 中分支的技术细节。如果您有兴趣学习如何在实践中使用分支，请遵循在管道构建器或代码库中创建简单批处理管道的教程。

分支技术细节

在 Foundry 中，数据的分支通过两个不同级别的功能实现：在单个数据集内的分支，以及在构建数据集时的分支。

数据集分支

如数据集页面所述，数据集的版本历史以一系列事务的形式存在。从概念上讲，数据集分支类似于 Git 中的分支——数据集、分支和事务类似于 Git 的仓库、分支和提交。

与 Git 中的分支类似，数据集分支只是指向该分支上最近事务的指针。因此，分支可以解释为按提交时间排序的事务的线性序列。当通过提交事务更改分支上的数据集时，所有其他分支的事务和视图不受影响。与 Git 不同的是，不支持合并数据集分支。

每个数据集分支都有一个父分支，除非它是一个根分支。在实践中，Foundry 中的大多数数据集都有一个名为 master 的单一根分支，并且从这个单一根分支创建子分支。

以下是与数据集分支相关的所有支持操作：

创建新分支。可以创建没有父分支和事务的根分支。
创建子分支。可以从另一个分支或任何事务创建子分支。新分支指向与父分支相同的事务。随后，可以在父分支和子分支上开始事务，它们的事务指针将独立移动。
在分支上开始新事务。启动事务并将分支指针移动到新事务。
删除分支。删除分支指针，但不删除分支上的任何事务。请参阅下面的关于父分支的保证的说明。

数据集分支保证

Foundry 为数据集分支提供以下保证：

每个分支一个开放事务。每个分支最多可以有一个开放（即打开且未提交或中止）的事务，并且该事务始终是分支上的最新事务。因此，一个只有一个分支的数据集最多可以有一个开放事务。如果一个分支指向一个开放事务，则可以从该分支创建一个新分支，但在事务关闭之前，无法启动新的事务。
在每个分支上，事务按开始和提交时间排序。这种保证是前一个限制的结果。然而，并不保证不同分支上的事务的时间顺序。
每个非根分支都有一个父分支。如果“中间”分支——有子分支的分支——被删除，子分支将被重新指定到已删除分支的父分支（如果它是根分支，则没有父分支）。注意，在此过程中没有事务被重新排列；重新指定仅更改分支祖先记录。

构建中的分支

数据集分支为版本化数据提供了基础语义。Foundry 将数据集分支与 Git 分支相结合，以支持逻辑和数据同时进行分支，使数据工程师能够在将更改引入生产之前安全地对数据管道进行变换。

通过 Foundry 的构建系统将 Git 中的逻辑分支与数据集中的数据分支绑定在一起。每个构建都在用户指定的分支上运行，并且构建内的任务仅修改该分支上的数据集。因此，构建中的分支提供了一种隔离不同用户更改的方法。

Foundry 构建涉及分支的两个主要功能，如下所述：

首先，它们通过从适当的分支收集任务规范或 JobSpecs 来编译构建图。
其次，它们通过用户定义的构建分支和一系列回退分支来解决任务输入和输出。

任务图编译

当您在 Foundry 中的代码库的分支中编写数据变换时，提交代码会将 JobSpecs 发布到构建系统的适当分支。当在该分支上运行构建时，构建会遍历您分支上的 JobSpecs 及其依赖关系，以确定应执行哪些逻辑。

构建通常会指定分支回退，以决定在构建分支上没有设置 JobSpec 的情况下从哪个分支检索 JobSpecs。例如，如果您在 develop 上运行一个构建，并有一个 develop --> master 的回退链，如果没有为给定输出数据集发布 JobSpec，则会从 master 分支读取 JobSpec。

数据集图标颜色提供有关 JobSpecs 和分支的信息。如果数据集的图标是灰色的，这表示 master 分支上没有 JobSpec 存在。如果数据集图标是蓝色的，则表示 master 分支上定义了 JobSpec。

输入和输出解析

对于构建中 JobSpecs 所指定为输出的所有数据集，将在构建分支上打开一个事务。如果此分支在数据集中不存在，则会从回退链中的第一个分支创建，或者如果不存在回退分支，则作为根分支创建。任务输入尽可能从构建分支读取，否则使用回退链中的第一个现有分支。

示例：在分支上构建

为了理解分支在构建中的工作方式，让我们逐步了解一个示例工作流程：

假设数据集 A、B 和 C 存在于 master 分支上。
数据工程师在他们的代码库中创建一个名为 feature 的分支。这会在底层 Git 仓库中创建一个分支。
数据工程师修改生成数据集 B 和 C 的代码。当数据工程师提交他们的代码时，库中的检查将 JobSpecs 发布到 feature 分支上的两个数据集中。
数据工程师在 feature 分支上启动一个构建。由于 feature 分支是在 Git 仓库的 master 分支上创建的，因此此构建的回退链为 feature --> master。步骤 (3) 中发布的 JobSpecs 被读取，并启动两个与用户代码对应的任务。在 feature 分支上的数据集 B 和 C 上打开事务。这两个任务按以下顺序串行执行：
1. 任务 1：由于分支回退，使用数据集 A 的 master 分支作为输入。计算生成新数据，并将其写入当前打开的事务中的数据集 B。事务被提交。
2. 任务 2：接下来开始此任务。使用数据集 B 的 feature 分支作为输入。计算生成新数据，并将其写入当前打开的事务中的数据集 C。事务被提交。
最后，由于构建中的所有任务都成功，构建成功。

在修改代码、提交和运行构建后，数据工程师在数据集 B 和 C 的 feature 分支上生成了新数据。注意，数据集 A 在此过程中完全不受影响，数据集 B 和 C 的 master 分支也未更改。

构建分支保证

Foundry 中的构建为分支提供以下保证：

构建解析仅在指定的分支回退序列与所涉及数据集中的分支祖先兼容时才会成功。
构建不会修改除构建分支以外的任何数据集分支。
构建不会在输入数据集上创建分支。