3、版本控制基础：Git在封装设计中的应用、分支策略选择（Git Flow vs Trunk Based）、代码提交规范
3.1 为什么封装设计离不开Git？
说实话，我见过不少封装工程师还在用「V1.0_final_改3_真的不改了.zip」这种命名方式。嗯，每次看到我都头皮发麻。
封装设计不是一个人闷头画图的事。你要跟芯片设计团队对die尺寸，跟PCB团队对BGA球栅，跟仿真团队对热模型。一个封装项目下来，光叠层结构就要改七八版。没有Git？你想想看，怎么追溯谁改了哪一层？怎么回退到三天前那个「好像还能用」的版本？
我个人习惯，从项目启动第一天就建Git仓库。哪怕只是放了一个空的APD工程文件，也要先commit一次。为什么？因为Git给你的不是「备份」，而是「时间旅行」的能力。
3.2 Git在封装设计中的典型工作流
封装设计文件跟纯代码不太一样。代码是文本，Git可以逐行diff。但封装设计文件——比如.brd、.mcm、.sip——大多是二进制格式。Git没法帮你「看」出这版和上一版在走线上有什么不同。
那怎么办？我的做法是：把设计文件当「黑盒」管理，把配套的文档、脚本、参数文件当「白盒」管理。
一个典型的封装项目Git仓库结构，我建议这样组织：
project_root/
├── design/ # 封装设计源文件（二进制）
│ ├── rev1.brd
│ └── rev2.brd
├── docs/ # 设计文档、评审纪要
│ ├── stackup_v1.md
│ └── pinmap_v2.xlsx
├── scripts/ # 自动化脚本（DRC、LVS、导出Gerber）
│ ├── drc_check.tcl
│ └── export_odb.py
├── params/ # 参数配置文件
│ ├── layer_stack.yaml
│ └── bga_assign.csv
└── README.md # 项目说明
我在项目中遇到过一个问题：有人把二进制设计文件直接push到Git，结果每次打开保存后文件大小都不一样，Git仓库膨胀到几个G。后来我们加了一条规则——二进制设计文件只保留「发布版」，日常迭代用命名区分，只有评审通过、仿真通过的版本才commit进Git。
3.3 分支策略选择：Git Flow vs Trunk Based
分支策略这东西，说白了就是「你们团队怎么协作」。封装设计团队通常不大，三五个人到十几个人。选哪种策略，我建议看两个因素：项目并行度和发布频率。
3.3.1 Git Flow：适合多版本并行、发布周期长的项目
Git Flow有5种分支：master、develop、feature、release、hotfix。听起来复杂，但用熟了其实很清晰。
我参与过一个汽车电子封装项目，客户要求同时维护「当前量产版」和「下一代预研版」。量产版只修bug不改设计，预研版可以大胆试新工艺。这种情况下，Git Flow简直是救星：
- master：永远对应当前量产版本
- develop：下一代版本的开发主线
- feature/：每个新特性（比如换基板材料、改BGA布局）单独开分支
- release/：发布前做最终仿真和评审
- hotfix/：量产版出问题，紧急修
但Git Flow有个坑：分支多了，合并起来很痛苦。尤其是封装设计文件不能自动合并，每次合并都要手动比对。我曾经有一次合并feature分支，因为两个人同时改了同一层的走线，结果merge完叠层结构全乱了。嗯，从那以后我定了一条铁律：同一时间，同一层只能一个人改。
3.3.2 Trunk Based：适合小团队、快速迭代
Trunk Based就简单多了——所有人都在main分支上开发，通过短生命周期的特性分支（feature branch）来控制。分支存活时间不超过一天，改完就合并。
我个人更喜欢Trunk Based，尤其是封装设计团队只有3-5个人的时候。为什么？因为封装设计不像软件开发，可以拆成几十个微服务并行开发。封装设计本质上是一个「串行」工作——你先定叠层，再画走线，最后做仿真。串行工作用Trunk Based，沟通成本最低。
但Trunk Based也有前提：你的CI/CD要够强。每次合并前，自动跑DRC、自动跑LVS、自动跑信号完整性仿真。如果这些自动化没做好，Trunk Based就是灾难——你今天合并的代码，可能三天后才发现把别人的设计搞坏了。
3.4 代码提交规范：让Git历史可读、可追溯
提交信息写「update」或者「fix」？我每次看到这种commit message都想顺着网线爬过去打人。你想想看，三个月后你回来看Git log，看到「update」两个字，你能想起来改了啥？
我建议封装设计团队采用「类型+范围+描述」的提交格式：
<type>(<scope>): <description>
[optional body]
[optional footer]
举个例子：
feat(stackup): 将第3层介质厚度从0.1mm改为0.08mm
原因：仿真发现第3层到第4层的串扰超标，减小介质厚度可以降低耦合。
影响：需要重新跑SI仿真，确认是否满足规范。
常用的type我列一下：
| Type | 含义 | 封装设计中的例子 |
|---|---|---|
| feat | 新功能/新设计 | 新增一层电源平面 |
| fix | 修复问题 | 修正BGA球栅分配错误 |
| docs | 文档变更 | 更新叠层结构说明文档 |
| style | 格式调整 | 调整走线间距（不影响功能） |
| refactor | 重构 | 重新规划扇出走线路径 |
| test | 测试相关 | 新增DRC检查脚本 |
| chore | 杂项 | 更新.gitignore配置 |
3.5 封装设计中的Git协作避坑清单
最后，我把自己踩过的坑整理成一份清单，你直接拿去用：
- 不要commit中间文件——.sav、.log、.bak这些文件，加进.gitignore
- 二进制设计文件只commit「发布版」——日常迭代用文件名区分版本
- 同一时间同一层只能一个人改——避免合并冲突
- 每次合并前跑自动化检查——DRC、LVS、SI仿真，至少跑一个
- commit message写清楚「为什么」——不要只写「改了叠层」
- 分支存活时间不要太长——Git Flow的feature分支建议不超过一周
- 定期清理已合并的分支——不然git branch -a会看得你眼花
嗯，版本控制这件事，说白了就是「让团队协作更顺畅，让历史可追溯」。工具是死的，人是活的。选什么分支策略、怎么写commit message，最终都要回归到一点：你的团队能不能高效地工作。
我见过有人把Git Flow用得飞起，也见过小团队用Trunk Based做得风生水起。没有银弹，只有适合你的才是最好的。
可可精品资料库