2、获取Buildroot源码：从官方Git仓库克隆Buildroot，切换至稳定版本分支，验证源码完整性。
好，咱们正式开始动手了。第一步，先把Buildroot的源码请到你的电脑上来。
你可能觉得这有啥好讲的，不就是 git clone 一下嘛？嗯，确实不复杂，但这里头有几个小细节，我当年踩过坑，今天一并告诉你。
2.1 从官方Git仓库克隆
Buildroot 的官方仓库在 GitLab 上，地址是：
https://gitlab.com/buildroot.org/buildroot.git我个人习惯用 --depth 1 参数来克隆。为什么呢？因为Buildroot的提交历史非常长，全量克隆下来可能得几百兆，而大部分历史你根本用不上。
git clone --depth 1 https://gitlab.com/buildroot.org/buildroot.git但注意，如果你后面需要查看历史提交、做版本对比，那还是老老实实全量克隆吧：
git clone https://gitlab.com/buildroot.org/buildroot.git克隆完成后，你会看到一个 buildroot 目录。进去看看：
cd buildroot
ls -l你会看到一堆文件和目录，比如 Makefile、Config.in、package/、board/ 等等。嗯，这就是Buildroot的家当了。
git clone --depth 1 --branch 2024.02.x 直接指定分支，省得后面再切。
2.2 切换至稳定版本分支
Buildroot 的发布策略是：每年2月、5月、8月、11月各出一个稳定版本。版本号格式是 2024.02、2024.05 这样。
我个人建议，不要用最新的版本，也不要太老的。选一个当前时间点往前推半年左右的版本，最稳妥。比如现在是2025年，那 2024.02.x 或者 2024.05.x 就很合适。
先看看有哪些分支：
git branch -a | grep "stable\|2024"你会看到类似这样的输出：
remotes/origin/2024.02.x
remotes/origin/2024.05.x
remotes/origin/2024.08.x
remotes/origin/2024.11.x然后切换到目标分支：
git checkout -b my-2024.02.x origin/2024.02.x这里我习惯创建一个本地分支，名字自己起，比如 my-2024.02.x。这样万一后面想切回主线，也方便。
master 分支！master 是开发分支，可能随时有编译问题。我在项目中遇到过，用master编译到一半报错，查了半天发现是某个新提交的bug。稳定版本分支才是经过测试的。
2.3 验证源码完整性
源码下载完了，怎么知道它有没有被篡改？或者下载过程中有没有损坏？
Buildroot 官方对每个发布版本都做了 GPG 签名。你可以用这个来验证。
首先，导入Buildroot的官方公钥：
gpg --keyserver keyserver.ubuntu.com --recv-keys 0xDA7B7B7B然后，验证标签签名：
git tag -v 2024.02.1如果输出类似 gpg: Good signature from "Buildroot ..."，那就说明源码是完整的、可信的。
不过说实话，我在实际项目中很少每次都做GPG验证。为什么呢？因为Buildroot的Git仓库本身就在官方GitLab上，HTTPS传输有校验，被篡改的概率极低。但如果你对安全性要求很高，比如做军工、金融类的产品，那这一步不能省。
还有一个更简单的验证方法：计算源码目录的MD5或SHA256值，和官方发布的checksum文件对比。不过这个方法需要你提前下载checksum文件，稍微麻烦一点。
git clone + 切到稳定分支 就足够了。GPG验证更多是锦上添花。但如果你是从第三方镜像站下载的Buildroot，那一定要做完整性校验！
2.4 确认当前状态
最后，确认一下你当前的状态：
git status
git log --oneline -3你应该看到类似这样的输出：
HEAD detached at 2024.02.1
或者
On branch my-2024.02.x嗯，到这里，Buildroot源码就准备好了。下一章，我们会配置交叉编译工具链，那才是真正开始动手的地方。
你想想看，整个流程其实不复杂，但每一步都做扎实了，后面才能顺风顺水。我曾经见过有人跳过这一步，直接从网上下载了个压缩包就开始搞，结果编译到一半发现版本不对，又得重来。何必呢？