3、源码下载：从官方Git仓库下载Buildroot源码、切换到稳定版本分支、验证源码完整性

好，上一节我们把环境搭好了。这一节，咱们来干一件实实在在的事——把Buildroot的源码拿到手。

你可能觉得，下载源码嘛，不就是 git clone 一下？嗯，没那么简单。我在项目里见过太多人因为源码版本不对，折腾好几天最后发现是分支搞错了。所以这一节，我带你走一遍我自己的标准流程。

3.1 从官方Git仓库拉取源码

Buildroot的官方仓库在GitHub上，地址是：

https://github.com/buildroot/buildroot.git

我个人习惯用HTTPS方式克隆，因为公司网络有时候对SSH端口有限制。命令很简单：

git clone https://github.com/buildroot/buildroot.git

执行完这条命令，你会看到类似这样的输出：

Cloning into 'buildroot'...
remote: Enumerating objects: 654321, done.
remote: Counting objects: 100% (654321/654321), done.
remote: Compressing objects: 100% (123456/123456), done.
Receiving objects: 100% (654321/654321), 256.78 MiB | 2.34 MiB/s, done.
Resolving deltas: 100% (456789/456789), done.

嗯，这里要注意。整个仓库大概250MB左右，取决于你的网速，可能需要几分钟到十几分钟。我建议你泡杯咖啡等着，别干等。

小技巧： 如果你只想下载最新版本，不想拉取全部历史，可以加 --depth=1 参数。这样只拉取最近一次提交，速度快很多。不过我个人建议第一次还是完整克隆，方便以后切换分支。

3.2 切换到稳定版本分支

源码下载完了，接下来就是选版本。Buildroot的发布节奏是每三个月一个稳定版本，每年一个LTS版本。你想想看，如果你随便选个master分支，那上面的代码可能还在开发中，说不定就有bug。

我建议的做法是：

  1. 先看看有哪些稳定版本
  2. 选一个最新的LTS版本
  3. 基于这个版本做开发

查看所有标签：

cd buildroot
git tag -l | grep -E '^20[0-9]{2}\.[0-9]{2}$'

输出大概是这样：

2023.02
2023.05
2023.08
2023.11
2024.02
2024.05
2024.08
2024.11

其中，年份后面是 .02 的版本就是LTS版本。比如 2024.02 就是2024年的LTS版本。我个人习惯用LTS版本，因为它在两年内都会持续收到安全更新和bug修复。

切换到指定版本：

git checkout 2024.02

执行后你会看到：

HEAD is now at a1b2c3d... Release 2024.02
注意： 千万不要直接基于master分支做产品开发。我曾经有个同事，图省事直接用master分支做项目，结果编译到一半发现某个包依赖的库版本不兼容，折腾了两天才定位到问题。后来切回稳定版本，一切顺利。

3.3 验证源码完整性

源码下载完了，版本也切好了。但你怎么保证你下载的代码就是官方发布的原版，没有被篡改过？

Buildroot官方对每个发布版本都做了GPG签名。验证流程分三步：

3.3.1 导入官方公钥

首先，你需要导入Buildroot维护者的公钥。这些公钥可以在Buildroot官网或者GitHub仓库的 gpg-keys 目录下找到。

gpg --keyserver keyserver.ubuntu.com --recv-keys 0x????????

具体公钥ID，我建议你直接从Buildroot官网的下载页面获取，确保来源可靠。

3.3.2 验证标签签名

导入公钥后，验证当前标签的签名：

git tag -v 2024.02

如果一切正常，你会看到类似这样的输出：

object a1b2c3d4e5f6...
type commit
tag 2024.02
tagger Peter Korsgaard <peter@korsgaard.com> 1700000000 +0100

Release 2024.02
gpg: Signature made Mon 01 Jan 2024 12:00:00 PM CST
gpg:                using RSA key ABCD1234...
gpg: Good signature from "Peter Korsgaard <peter@korsgaard.com>"

看到 Good signature 就说明签名验证通过，源码是完整的、未被篡改的。

3.3.3 检查提交哈希

最后一步，确认你当前所在的提交就是官方发布的那个提交：

git log --oneline -1

输出应该和官方发布公告里的哈希值一致。

重要： 验证源码完整性不是走形式。我在2019年参与过一个安全审计项目，发现有人通过中间人攻击替换了下载的源码包，植入了后门。从那以后，我每次下载开源软件都会做签名验证，多花一分钟，省心一整年。

3.4 本章核心流程总结

为了让你更直观地理解整个流程，我画了一张图：

Buildroot源码下载与验证流程 步骤1：克隆仓库 git clone 官方仓库 步骤2：切换分支 git checkout 稳定版本 步骤3：验证完整性 GPG签名验证 分支选择建议： LTS版本（如2024.02） → 稳定可靠，适合产品开发 master分支 → 仅用于尝鲜 验证完整性三步走： ① 导入官方GPG公钥 ② git tag -v 验证标签签名 → 确认 Good signature ③ 核对提交哈希值与官方公告一致

3.5 常见问题与避坑

最后，分享几个我实际踩过的坑：

  • 网络超时： 如果克隆过程中断，可以加 --depth=1 先拉取最新代码，后续再用 git fetch --unshallow 补全历史。
  • GPG签名验证失败： 检查一下公钥是否导入正确，或者公钥是否已过期。Buildroot维护者的公钥会定期更新。
  • 切换分支后编译报错： 记得先执行 make clean 清理之前的编译产物，避免旧文件干扰。

好了，源码已经稳稳当当地躺在你的硬盘上了。下一节，咱们就正式开始配置和编译，看看Buildroot到底能变出什么花样来。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →