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 适用于三个主要的利益群体：

正在积极研究某些部分的源代码的 FreeBSD 社区成员。
FreeBSD 社区的成员是积极的测试者。他们愿意花时间解决问题，对 FreeBSD 的变化和总体方向提出专题建议，并提交补丁。
希望关注事物的用户，使用当前的源码作为参考，或偶尔发表评论或贡献代码。

FreeBSD-CURRENT 不应该被认为是在下一个版本之前获得新功能的快速通道，因为预发布的功能还没有经过充分的测试，而且很可能包含有错误。它不是一个快速获得错误修正的方法，因为任何给定的提交都有可能修正现有错误并引入新的错误。FreeBSD-CURRENT 没有任何“官方支持”。

要追踪 FreeBSD-CURRENT：

加入 FreeBSD-CURRENT 邮件列表以及 src 仓库主分支的提交信息列表。这对于看到人们对系统现状的评论以及收到有关 FreeBSD-CURRENT 现状的重要公告是 必不可少 的。

src 仓库列表的主分支的提交信息记录了每个改动的提交日志条目，以及任何可能的副作用的相关信息。

要加入这些列表，请到 FreeBSD 列表服务器，点击要订阅的列表，并按照说明操作。为了跟踪整个源码的变化，而不仅仅是 FreeBSD-CURRENT 的变化，请订阅 src 仓库中所有分支的 Commit 信息。
与 FreeBSD-CURRENT 源码同步。通常情况下，用 git 来从 FreeBSD Git 仓库的 main 分支检出 -CURRENT 代码 (详见使用 Git)。
出于仓库的大小，一些用户选择只同步他们感兴趣的部分或他们正在贡献补丁的部分的源代码。然而，计划从源代码编译操作系统的用户必须下载全部的 FreeBSD-CURRENT，而不能只选择部分。

在编译 FreeBSD-CURRENT 之前，请仔细阅读 /usr/src/Makefile，并遵循从源代码更新 FreeBSD 中的说明。阅读 FreeBSD-CURRENT 邮件列表和 /usr/src/UPDATING 来了解其他引导程序的最新情况，这些程序在通往下一个版本的过程中有时是必须的。
动起手来! 我们鼓励 FreeBSD-CURRENT 用户提交他们的改进或错误修正建议。我们随时欢迎附有代码的建议。

26.5.2.使用 FreeBSD-STABLE¶

FreeBSD-STABLE 是开发分支，主要的版本都是从它开始的。进入这个分支的修改速度较慢，而且一般认为这些修改已经在 FreeBSD-CURRENT 中进行了测试。这仍然是一个开发分支，而且在任何时候，FreeBSD-STABLE 的源代码可能都不适合用于一般的用途。它只是另一个工程开发轨道，而不是终端用户可依赖的。没有设备进行测试的用户应该运行最新的 FreeBSD release。

那些对追踪或贡献于 FreeBSD 开发过程感兴趣的人，特别是与 FreeBSD 下一版本有关的人，应该考虑关注 FreeBSD-STABLE。

尽管 FreeBSD-STABLE 分支应该在任何时候都能编译和运行，但这并不能保证。由于运行 FreeBSD-STABLE 的人比运行 FreeBSD-CURRENT 的人多，有时不可避免地会在 FreeBSD-STABLE 中发现一些在 FreeBSD-CURRENT 中不明显的 bug 和角落案例。由于这个原因，人们不应盲目地追踪 FreeBSD-STABLE。尤其重要的是，在没有在开发或测试环境中彻底测试代码之前，不要把任何生产服务器更新到 FreeBSD-STABLE。

要追踪 FreeBSD-STABLE：

加入 FreeBSD-STABLE 邮件列表，以便随时了解 FreeBSD-STABLE 中可能出现的联编依赖关系或其他需要特别注意的问题。开发人员在考虑进行一些有争议的修复或更新时，也会在这个邮件列表中发布公告，如果用户对提议的修改有任何问题要提出，可以给他们一个回应的机会。

加入被追踪的分支的相关 git 列表。例如，追踪 13-STABLE 分支的用户应该加入 src 仓库的稳定分支的提交信息。这个列表记录了每个改动的提交日志条目，以及任何可能产生的副作用的相关信息。

要加入这些列表，请到 FreeBSD 列表服务器，点击要订阅的列表，并按照说明操作。为了跟踪整个源代码的变化，请订阅 src 仓库所有分支的提交信息。
要安装一个新的 FreeBSD-STABLE 系统，需要从 FreeBSD 镜像站点安装最新的 FreeBSD-STABLE 版本，或者使用由 FreeBSD-STABLE 编译的每月快照。关于快照的更多信息，请参考 www.freebsd.org/snapshots。

要将现有的 FreeBSD 系统编译或升级到 FreeBSD-STABLE，可以使用 git 来检查所需分支的源代码。分支名称，例如 stable/9，会在 www.freebsd.org/releng 列出。
在编译或升级到 FreeBSD-STABLE 之前，请仔细阅读 /usr/src/Makefile 并遵循从源代码更新 FreeBSD 中的说明。阅读 FreeBSD-STABLE 邮件列表和 /usr/src/UPDATING 来了解在通往下一版本的道路上有时需要的其他引导程序的最新情况。

26.5.3.数值 N¶

当追踪 bug 时，知道被用来创建出现问题的系统来自哪些版本的源代码是很重要的。FreeBSD 提供了编译在内核中的版本信息，例如 uname(1) 可以检索到这些信息：

% 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

最后一个字段给出了关于内核名称、构建它的人以及它被编译的位置的信息。看一下第四列，它是由几个部分组成的：

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。比如说：

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

① 用来转换的 git 的哈希值（上面例子中的哈希值是重复使用的）。

② 数值 n。

通常情况下，这个数字并不那么重要。然而，当错误修复被提交时，这个数字可以让我们很容易地确定该修复是否存在于当前运行的系统中。开发者通常会提到提交的哈希值（或提供一个有该哈希值的链接），但不会提到数值 n，因为哈希值是一个变化的易见标识，而数值 n 则不是。安全公告和勘误通知也会注明数值 n，可以直接与你的系统进行比较。当你需要使用浅层 Git 克隆时，你不能可靠地比较数值 n，因为 git rev-list 命令会计算仓库中的所有修订，而浅层克隆会省略这些修订。