> For the complete documentation index, see [llms.txt](https://handbook.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.bsdcn.org/di-27-zhang-freebsd-geng-xin-yu-sheng-ji/27.5.-zhui-zong-kai-fa-fen-zhi.md). # 27.5.追踪开发分支 FreeBSD 有两个开发分支：FreeBSD-CURRENT 和 FreeBSD-STABLE。 本节介绍每个分支及其目标用户群，并说明如何保持系统与各分支同步。 ## 27.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 社区中积极的测试者，他们愿意花时间解决问题，提出关于变更和 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”](/fu-lu-a.-huo-qu-freebsd/a.2.-shi-yong-git.md)）。 3. 由于存储库的大小，有些用户选择仅同步他们感兴趣的部分源代码或他们正在贡献补丁的部分。但计划从源代码编译操作系统的用户必须下载 *所有* 的 FreeBSD-CURRENT，而不仅仅是选定的部分。 在编译 FreeBSD-CURRENT 之前，请仔细阅读 **/usr/src/Makefile** 并按照 [从源代码更新 FreeBSD](/di-27-zhang-freebsd-geng-xin-yu-sheng-ji/27.6.-cong-yuan-dai-ma-geng-xin-freebsd.md) 中的说明操作。阅读 [FreeBSD-CURRENT 邮件列表](https://lists.freebsd.org/subscription/freebsd-current) 和 **/usr/src/UPDATING** 以保持更新，了解在通往下一个版本的过程中有时必需的其他引导过程。 4. 积极参与！建议 FreeBSD-CURRENT 用户提交增强功能或 bug 修复建议。始终欢迎附带代码的建议。 ## 27.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 镜像站](/fu-lu-a.-huo-qu-freebsd/a.1.-jing-xiang-zhan.md) 安装最新的 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](/di-27-zhang-freebsd-geng-xin-yu-sheng-ji/27.6.-cong-yuan-dai-ma-geng-xin-freebsd.md) 中的说明。阅读 [FreeBSD-STABLE 邮件列表](https://lists.freebsd.org/subscription/freebsd-stable) 和 **/usr/src/UPDATING** 以保持更新，了解有时在向下一个发布版本过渡过程中所需的其他引导过程。 ## 27.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 编号则不那么显眼。安全通告和勘误通知也会提到 n 编号，可以直接与你的系统进行比较。在使用浅克隆 Git 时，无法可靠地比较 n 编号，因为 `git rev-list` 命令会计算所有的版本，而浅克隆省略了部分提交。