Zynq 开发（Vivado、PetaLinux、Linux、U-Boot、驱动等），基本都会遇到的一个问题：
工程文件越来越多，但真正需要长期保存的东西其实没那么多。如果不把边界划清楚，
Git 仓库很容易变成"源码 + 编译产物 + 工具缓存"的大杂烩，体积越来越大，存的都是垃圾。
而且一旦换机器、或者硬盘坏了，仍然要花费大量时间恢复工程。所以最关键的问题是：
Git 里到底应该放什么，才能保证工程丢了也能快速重新搭起来。
一、工程里的三类文件
在 Zynq 工程里，文件基本可以分三类：
1. 外部来的东西
比如：
- Linux Kernel
- U-Boot
- Yocto / PetaLinux layer
- 第三方驱动
- 官方 BSP / IP
特点很简单：
- 不是你写的
- 能重新下载
- 能换版本
所以重点不是"存下来"，而是：
记清楚版本 + 有需要能找回来
2. 自己写的东西（核心）
这一类是最重要的，包括：
- 应用代码
- 驱动代码
- Device Tree（dts）
- kernel / uboot 配置
- Vivado HDL（verilog）
- block design 的 tcl 脚本
- 各种 build / 脚本工具
3. 工具生成的东西（最占空间）
这些东西丢了没事，重新编一次就有了
比如：
- Vivado 的 .xpr / .runs / .cache
- PetaLinux 的 build / tmp / images
- 编译出来的 Image / dtb / elf / bit
- node_modules / venv
- 各种 log / dump
特点：
- 很大
- 机器相关
- 可以重新生成
二、一个容易踩的坑
很多"自己写的文件"，其实已经不纯了，比如：
- 在 dts 基础上改了一堆
- Vivado GUI 改完没导 tcl
- kernel config 改来改去
- 临时 patch 没整理
- 生成文件上直接手改
时间久了就变成：
"看起来是源码，其实是半生成 + 半手改 + 半历史遗留"
这种东西最危险，因为：
- 你以为能复现
- 实际上复现不了
三、Git 在这里真正该干什么
Git 不是用来备份整个工程的,在 Zynq 这种工程里，Git 不是存结果的，是存"怎么把系统搭起来的"。简单说就是： 不管你换电脑还是硬盘坏了，只要 Git 还在，能重新把系统搭出来。
四、"恢复现场"的意思
这里要说清楚一点，"恢复现场"不是指：
- 恢复 Vivado 界面
- 恢复 build 目录
- 恢复你当时的临时状态
这些做不到，也没必要。
真正的"恢复现场"是：
- Linux 能重新编出来
- dtb 能重新生成
- bitstream 能重新做出来
- 应用能跑起来
- 系统行为是对的
五、类似现象
- Node.js：靠 package.json 重装依赖
- Python：靠 requirements.txt 重建环境
- Vivado：靠 TCL / BD 重建工程
- Linux / U-Boot：靠 defconfig +.config + patch 重建
- Yocto：靠 layer + recipe 重建整个系统
共同点是：
不存结果，只存规则
六、工程实践
在 Zynq（Vivado + PetaLinux + Linux + U-Boot）开发中，Git 的核心不是"存文件"，而是"存可重建系统所需的信息"。
| 模块 / 类型 | 应该纳入 Git | 不建议纳入 Git | 本质理解 / 恢复方式 |
|---|---|---|---|
| 应用源码 | C / C++ / Python 业务代码 | 编译产物（.o / .elf / 可执行文件） | 直接重新编译即可 |
| 自定义驱动 | Linux driver 源码 | .ko 模块文件 | kernel 重新编译生成 |
| 通信协议 / 业务逻辑 | 协议实现代码 | runtime log / dump | 可通过源码复现 |
| Device Tree | .dts / .dtsi | .dtb（二进制） | dtc 重新编译生成 |
| Linux Kernel | patch / defconfig / config | Image / vmlinux / build目录 | kernel 源码 + config 重建 |
| U-Boot | patch / defconfig | u-boot.bin / build输出 | 源码重新编译 |
| Vivado HDL | Verilog / VHDL 源码 | synth / impl 输出文件 | 重新综合生成 |
| Vivado 约束 (XDC) | .xdc 时序 / 引脚约束文件 | --- | FPGA 核心设计约束，必须版本管理 |
| Vivado Block Design | bd.tcl | .xpr / .runs / .cache | TCL 重建整个工程 |
| Vivado 工程文件 | --- | .xpr（不能作为唯一来源） | 必须可用脚本重建 |
| IP 配置 | TCL / 参数脚本 | GUI配置工程文件 | 通过脚本恢复 |
| PetaLinux 工程 | project-spec / config | build / tmp / images | petalinux-build 重新生成 |
| Yocto layer | recipe / bb 文件 | sstate-cache | bitbake 重建 |
| 构建脚本 | build.sh / env.sh / Makefile / CMakeLists | 临时脚本 / 手动命令记录 | 一键化重建流程 |
| 工具链环境 | 版本说明 / 安装脚本 | gcc / vivado 安装目录 | 外部安装 + 版本锁定 |
| Node.js 依赖 | package.json / package-lock.json | node_modules | npm install 重建 |
| Python 依赖 | pyproject.toml / requirements.txt | .venv / site-packages | uv sync / pip install 重建 |
| 调试相关 | 调试脚本 / 测试用例 | log / dump / core 文件 | 仅用于分析，不进版本库 |
| 临时数据 | 小规模测试输入 | 大规模输出 / 中间结果 | 可删除或本地保留 |
七、总结
- 能写脚本的，就不手点 GUI
- 能生成的东西，就不手改
- 改动一定要留下规则（patch / tcl）
- build 目录和源码分开
- 维护一份恢复现场的md
- 仓库尽量干净