# 26.5.追踪开发分支

FreeBSD 有两个开发分支：FreeBSD-CURRENT 和 FreeBSD-STABLE。

本节解释了每个分支及其目标用户群，并提供了如何保持系统与每个分支同步的相关信息。

## 26.5.1. 使用 FreeBSD-CURRENT

FreeBSD-CURRENT 是 FreeBSD 开发的“前沿”，使用 FreeBSD-CURRENT 的用户需要具备较高的技术水平。对于技术水平较低的用户，建议跟踪 FreeBSD-STABLE 分支。

FreeBSD-CURRENT 是 FreeBSD 最前沿的源代码，包含正在进行的工作、实验性变更和可能出现在下一个正式版本中的过渡机制。虽然许多 FreeBSD 开发人员每天都会编译 FreeBSD-CURRENT 的源代码，但有时会出现源代码无法编译的短暂时期。这些问题会尽快得到解决，但 FreeBSD-CURRENT 是带来灾难还是新功能，取决于同步的源代码版本。

FreeBSD-CURRENT 主要面向三个兴趣群体：

1. 积极参与某部分源代码树的 FreeBSD 社区成员。
2. 积极的测试者，他们愿意花时间解决问题，提出关于变更和 FreeBSD 整体方向的建议，并提交补丁。
3. 想要关注 FreeBSD 状态，使用当前源代码作为参考，或偶尔发表评论或贡献代码的用户。

FreeBSD-CURRENT 不应被视为提前获取新功能的捷径，因为预发布功能尚未经过充分测试，且很可能存在 bug。它也不是获取 bug 修复的快速途径，因为任何提交同样有可能引入新 bug，而不是修复现有 bug。FreeBSD-CURRENT 并未得到“正式支持”。

要跟踪 FreeBSD-CURRENT：

1. 加入 [FreeBSD-CURRENT 邮件列表](https://lists.freebsd.org/subscription/freebsd-current) 和 [源代码仓库主分支提交信息列表](https://lists.freebsd.org/subscription/dev-commits-src-main)。这是*必需*的，以便了解人们对系统当前状态的评论，并接收有关 FreeBSD-CURRENT 当前状态的重要公告。[源代码仓库主分支提交信息列表](https://lists.freebsd.org/subscription/dev-commits-src-main) 会记录每个变更的提交日志条目，以及关于可能副作用的相关信息。

   要加入这些列表，请访问 [FreeBSD 列表服务器](https://lists.freebsd.org/)，点击要订阅的列表，并按照说明进行操作。如果要跟踪整个源代码树的变更，而不仅仅是 FreeBSD-CURRENT 的变更，订阅 [所有分支的源代码仓库提交信息列表](https://lists.freebsd.org/subscription/dev-commits-src-all)。
2. 与 FreeBSD-CURRENT 源代码同步。通常使用 `git` 从 FreeBSD Git 仓库的 `main` 分支检出 -CURRENT 代码（详细信息请参见 [“使用 Git”](https://docs.freebsd.org/en/books/handbook/mirrors/#git)）。
3. 由于仓库的大小，有些用户选择仅同步他们感兴趣的部分源代码或他们正在贡献补丁的部分。但计划从源代码编译操作系统的用户必须下载 *所有* 的 FreeBSD-CURRENT，而不仅仅是选定的部分。\
   在编译 FreeBSD-CURRENT 之前，请仔细阅读 **/usr/src/Makefile** 并按照 [从源代码更新 FreeBSD](https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld) 中的说明操作。阅读 [FreeBSD-CURRENT 邮件列表](https://lists.freebsd.org/subscription/freebsd-current) 和 **/usr/src/UPDATING** 以保持更新，了解有时会成为必要的启动过程。
4. 积极参与！建议 FreeBSD-CURRENT 用户提交增强功能或 bug 修复建议。附带代码的建议始终受到欢迎。

## 26.5.2. 使用 FreeBSD-STABLE

FreeBSD-STABLE 是用于发布主要版本的开发分支。此分支的更新速度较慢，且通常假设所有变更已在 FreeBSD-CURRENT 中经过测试。尽管如此，它仍然是一个开发分支，任何时候，FreeBSD-STABLE 的源代码可能并不适合普遍使用。它只是另一个工程开发轨道，并非终端用户的资源。没有足够资源进行测试的用户应使用 FreeBSD 的最新正式版本。

那些希望跟踪或参与 FreeBSD 开发过程，特别是与下一个 FreeBSD 发布相关的开发者，应该考虑跟踪 FreeBSD-STABLE。

尽管 FreeBSD-STABLE 分支应该始终能够编译并运行，但这不能得到保证。由于更多用户运行 FreeBSD-STABLE 而非 FreeBSD-CURRENT，某些在 FreeBSD-CURRENT 中未发现的 bug 和边缘情况会在 FreeBSD-STABLE 中暴露。因此，不能盲目地跟踪 FreeBSD-STABLE。特别需要注意的是，在没有充分测试的开发或测试环境中，不应将任何生产服务器更新到 FreeBSD-STABLE。

要跟踪 FreeBSD-STABLE：

1. 加入 [FreeBSD-STABLE 邮件列表](https://lists.freebsd.org/subscription/freebsd-stable)，以便及时了解 FreeBSD-STABLE 中可能出现的构建依赖或其他需要特别注意的问题。开发人员在此邮件列表中也会宣布他们正在考虑的有争议的修复或更新，用户可以在此期间回应并提出他们的意见。\
   加入相关的 git 列表以跟踪所选分支。例如，跟踪 14-STABLE 分支的用户应该加入 [稳定分支提交信息列表](https://lists.freebsd.org/subscription/dev-commits-src-branches)。该列表记录每个变更的提交日志条目，以及任何可能副作用的相关信息。

   要加入这些列表，请访问 [FreeBSD 列表服务器](https://lists.freebsd.org/)，点击要订阅的列表并按照说明进行操作。如果要跟踪整个源代码树的变更，订阅 [所有分支的源代码仓库提交信息列表](https://lists.freebsd.org/subscription/dev-commits-src-all)。
2. 安装新的 FreeBSD-STABLE 系统，可以从 [FreeBSD 镜像站](https://docs.freebsd.org/en/books/handbook/mirrors/#mirrors) 安装最新的 FreeBSD-STABLE 发布版本，或使用基于 FreeBSD-STABLE 的月度快照。有关快照的更多信息，请参见 [www.freebsd.org/snapshots](https://www.freebsd.org/snapshots/)。\
   若要编译或升级现有的 FreeBSD 系统到 FreeBSD-STABLE，请使用 `git` 检出所需分支的源代码。分支名称（如 `stable/13`）列出在 [www.freebsd.org/releng](https://www.freebsd.org/releng/)。
3. 在编译或升级到 FreeBSD-STABLE 之前，请仔细阅读 **/usr/src/Makefile** 并遵循 [从源代码更新 FreeBSD](https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld) 中的说明。阅读 [FreeBSD-STABLE 邮件列表](https://lists.freebsd.org/subscription/freebsd-stable) 和 **/usr/src/UPDATING** 以保持更新，了解有时在向下一个发布版本过渡过程中所需的其他启动过程。

## 26.5.3. 编号 N

在追踪 bug 时，知道用于创建存在问题的系统的源代码版本非常重要。FreeBSD 提供了编译到内核中的版本信息。使用 [uname(1)](https://man.freebsd.org/cgi/man.cgi?query=uname\&sektion=1\&format=html) 可以获取这些信息，例如：

```sh
% uname -v
FreeBSD 14.0-CURRENT #112 main-n247514-031260d64c18: Tue Jun 22 20:43:19 MDT 2021     fred@machine:/usr/home/fred/obj/usr/home/fred/git/head/amd64.amd64/sys/FRED
```

最后一个字段提供了关于内核名称、构建者和编译位置的信息。查看第四个字段，它由几个部分组成：

```sh
main-n247514-031260d64c18

main	      ①	
n247514	      ②	
031260d64c18  ③
              ④
```

* ① Git 分支名称。注意：n 编号的比较仅在项目发布的分支（如 `main`、`stable/XX` 和 `releng/XX`）之间有效。局部分支将具有与其父分支重叠的 n 编号。
* ② 编号 n 是从 Git 仓库起点开始的线性提交计数，包含在该行中包括的 Git 哈希值。
* ③ 检出的树的 Git 哈希
* ④ 有时会在内核构建时，出现 `-dirty` 后缀，表示该内核是从一个有未提交更改的树中构建的。在这个例子中，由于 FRED 内核是从一个干净的检出目录构建的，所以没有这个后缀。

`git rev-list` 命令用于查找与 Git 哈希相对应的 n 编号。例如：

```sh
% git rev-list --first-parent --count 031260d64c18 ①
247514 ②
```

* ① 要翻译的 git 哈希（上面例子中的哈希值被重用）
* ② 编号 n

通常，这个编号并不重要。然而，在 bug 修复提交时，这个编号使得快速确定当前运行的系统中是否包含该修复变得简单。开发人员通常会提到提交的哈希值（或提供一个包含该哈希的 URL），而不是 n 编号，因为哈希是一个容易看到的变更标识符，而 n 编号则不那么显眼。安全通告和 errata 通知也会提到 n 编号，可以直接与你的系统进行比较。在使用浅克隆 Git 时，无法可靠地比较 n 编号，因为 `git rev-list` 命令会计算所有的版本，而浅克隆省略了部分提交。