从零构建 Linux|12 用 Git 管理自定义配置

系列第 12 篇｜把 meta-demo 与 TEMPLATECONF 推上 GitHub，别人也能复现你的系统前提：已完成第 8 篇的 layer 与双机型模板

跑通虚机 / 真机之后，下一步往往是：把「我改过的东西」存进版本库，而不是只躺在本机 ~/yocto 里。本篇回答两件事：

1. 哪些该提交、哪些绝对不要提交；
2. 怎样用一个小仓库 + TEMPLATECONF，在另一台机器或同事环境里重建同样的构建配置。

原则：只托管「你的定制」，不托管「整棵构建树」

Yocto 工程体积很大。若把整个 poky、downloads、tmp 都推进 GitHub：

1. 仓库会膨胀到难以克隆；
2. 二进制与缓存无版本意义；
3. 还容易泄露本机路径、私有下载地址等。

正确边界：

build-*/conf/local.conf 是模板生成的本机副本，常含机器相关调参。默认以 *.sample 为唯一真相；已有 build 目录里的 conf 不必进仓库。

推荐仓库形态：只托管 meta-demo

最简单、也最适合本系列读者的做法：

GitHub 仓库（例如 my-yocto-demo）  └── meta-demo/     # 或仓库根目录就是 layer 内容        conf/...        recipes-...  README.md  .gitignore

工作区在本机仍可以是：

~/yocto/poky/              # 官方 scarthgap，不推你的 GitHub  meta/ ...  meta-demo/               # 用 git clone / submodule 放进来  build-qemux86-64/        # 本地生成，gitignore  build-genericx86-64/

.gitignore 示例

若你在 meta-demo 仓库根目录管理（仓库内容即 layer）：

# 编辑器与系统垃圾*~*.swp.DS_Store# 切勿把构建树误加进来build*/downloads/sstate-cache/*.wic*.hddimg*.iso

若误把整个 ~/yocto 当成一个大仓库，.gitignore 至少应忽略：

poky/build-*/poky/build/**/tmp/**/cache/**/downloads/**/sstate-cache/**/*.wic**/*.hddimg**/*.tar.bz2

并明确：上游 poky 用单独 clone，不要和自定义 layer 糊成一个「巨型提交」。

从本机初始化仓库并推到 GitHub

在 WSL2 中（路径按你的实际调整）：

cd ~/yocto/poky/meta-demogit initgit add conf recipes-example recipes-core recipes-bsp recipes-kernel README.md .gitignore# 若有第 9 篇的 psplash / GRUB Logo / 内核 bbappend，一并纳入对应 recipes-* 目录git status   # 确认没有 tmp、镜像、绝对路径机密git commit -m "$(cat <<'EOF'Add meta-demo with hello and dual MACHINE templates.EOF)"

在 GitHub 上新建空仓库（不要勾选自动生成 README，以免首次推送冲突），然后：

git remote add origin \  git@github.com:<你的用户名>/my-yocto-demo.git# 或 HTTPS：https://github.com/<你的用户名>/my-yocto-demo.gitgit branch -M maingit push -u origin main

SSH 密钥或 GitHub CLI（gh auth login）按你平时习惯配置即可。

README 里写清「别人怎么复现」

仓库 README 建议包含固定步骤，避免口头传授：

# my-yocto-demo## 环境- WSL2 Ubuntu- poky 分支：scarthgap## 获取git clone https://git.yoctoproject.org/poky.git \  -b scarthgap --depth=1cd pokygit clone https://github.com/<你>/my-yocto-demo.git meta-demo## 初始化双 buildTEMPLATECONF=meta-demo/conf/templates/qemux86-64 \  source oe-init-build-env build-qemux86-64# 另开终端cd ~/yocto/pokyTEMPLATECONF=meta-demo/conf/templates/genericx86-64 \  source oe-init-build-env build-genericx86-64## 构建bitbake core-image-base

这样，同事或未来的你，都能从 GitHub 拉到与第 8 篇一致的模板，而不必手抄 local.conf。

日常改配置：改模板，再同步到 build

以后增减包、改时区（第 9 篇）时：

1. 先改 meta-demo/conf/templates/*/local.conf.sample（以及 recipe / bbappend）；
2. git commit / git push；
3. 把同样改动合并进已有的 build-*/conf/local.conf（模板不会自动覆盖已存在的 conf）。

若某个 build 目录还是空的、可以重建：

# 仅当该目录没有需要保留的长编译产物时rm -rf build-qemux86-64TEMPLATECONF=meta-demo/conf/templates/qemux86-64 \source oe-init-build-env build-qemux86-64

有完整 tmp 时不要随便删；改 local.conf 后重新 bitbake 即可。

可选进阶：poky 用 submodule 钉死版本

只托管 meta-demo 时，README 写明 scarthgap 通常够用。若团队要求「某一天的 poky 提交也不能漂」，可以把 poky 加成 submodule，或在 README 写死 commit id：

cd ~/yocto/pokygit rev-parse HEAD# 把输出写进 meta-demo 的 README：请使用该 commit

更重的方案（多 layer、CI 一键构建）会用到 Kas、repo 清单等工具；入门阶段不必上。先把「layer + TEMPLATECONF + GitHub」做稳即可。

和本系列目录的对应关系

本篇小结

1. Git 只托管自定义 layer 与 *.sample 模板，不托管 build 树与镜像。
2. 推荐独立 GitHub 仓库存放 meta-demo，poky 仍从官方克隆。
3. 用 TEMPLATECONF 在新环境生成 build-qemux86-64 / build-genericx86-64。
4. 日常以模板为真相，再同步到已有 conf/local.conf，然后 git push。

至此，你不仅能构建并运行自定义 Linux，还能把「系统长什么样」用 Git 说清楚、交给别人复现。

系列文章列表：