在日常工作中，很多工程师习惯维护和使用自己的元器件库，这样可以方便的查找和使用元器件。但是，如果元器件库中的元器件数量较多，且元器件的版本较多，那么维护元器件库就会变得非常困难。还有，企业中的研发团队如果工程师各自维护和使用自己的库，就会影响协作效率，甚至给产品质量造成隐患。为了解决这些问题，我们可以使用Git来管理元器件库，统一规范团队使用的库。

这里所说的库，特指ECAD软件中使用的元器件库，主要包括元器件的原理图符号（逻辑符号）、PCB封装图形和3d模型。目前的ECAD软件通常都支持独立库文件的原子操作，也就是可以把元器件的各种属性独立操作，这样就为Git管理库提供了可能。

接下来就以Altium Designer为例，介绍如何使用Git管理元器件库。

关于Git

Git是一个分布式版本控制系统，用于高效地处理任何或小或大的项目。Git是免费、开源的，具有速度快、灵活性强、分布式等特点。Git可以用来管理代码，也可以用来管理其他类型的文件，比如图片、文档等。Git的分布式特点使得每个开发者都可以拥有自己的代码库，这样就可以避免代码冲突，提高协作效率。

Git的基本概念

Git的基本概念包括仓库（Repository）、分支（Branch）、提交（Commit）、标签（Tag）等。

• 仓库：Git的仓库是代码的存储空间，每个仓库都有自己的版本历史和分支。
• 分支：分支是仓库的一个副本，用于开发新的功能或修复bug。每个分支都有自己的版本历史，可以独立进行操作。
• 提交：提交是代码的一个版本，每个提交都有一个唯一的哈希值，用于标识该版本。
• 标签：标签是代码的一个版本，用于标识某个重要的版本，比如发布版本。

使用Git管理元器件库

安装Git

首先需要安装Git，可以从Git官网下载安装包，然后按照提示进行安装。官方文档已经写的非常详细，这里就不在赘述。

创建仓库

其实Altium Designer中对SVN的支持是最好的，但是SVN是集中式的版本控制系统，而Git是分布式的版本控制系统，不用考虑服务端备份的问题，更安全，并且Git的速度更快，就目前趋势来说，Git是更好的选择。

如果自建Git服务的话，可以使用Gitea、GitLab、Gogs等工具，但是需要维护服务器，如果不想维护服务器，可以使用GitHub、GitLab等在线服务。对于国内的企业来说，可以使用Gitee、Coding等国内的在线服务。如果既不想自己维护服务器，又不想使用Gitee等产品，阿里云和腾讯云也有Git托管服务产品，今天就以Codeup为例，其他的Git托管服务也是类似的。

首先登录Codeup，然后创建一个新的仓库，填写仓库名称、描述等信息，然后点击创建仓库。

这里我设置了仓库名称为"ADLib"，描述为"Altium Designer 元器件库"。

如果希望控制企业内多个开发组的权限，可以设置代码组，设置后只有对应代码组内的成员才能看到相应仓库。

注意这里的公开性是指企业内其他成员是否可见，如果是私有，则只有代码库内的成员才能看到。

填完这些信息后，点击确定，仓库就建好了。

开发维护

对于团队库，我们需要建立个流程规范来管理库，确保库的质量和可用性。

分支管理

团队库会有一个主分支（master），用于存放稳定的元器件库。开发人员在开发新的元器件时，可以从主分支上拉一个新的分支，进行开发。开发完成后，可以提交到新的分支上，然后发起一个合并请求（Pull Request），由管理员审核后，合并到主分支上。

在实践中，我们可以保持主分支为默认分支，其他分支可以根据需要创建。可以约定：

1. 主分支：master，默认分支，保护分支，用于存放稳定的元器件库。
2. 开发分支：new/sym-xxxx, new/fp-xxxx, new/3d-xxxx，用于新建元器件库文件。
3. 修复分支：fix/sym-xxxx, fix/fp-xxxx, fix/3d-xxxx，用于修复元器件库文件。

工程师在开发分支和修复分支上编辑元器件库文件，并提交到对应分支上。然后发起合并请求，由管理员审核后，合并到主分支上。

对于新建库文件，工程师在拉取后，应先建分支，新建对应库文件，然后提交推送，这样可以尽量避免其他工程师同时编辑同一个库文件，导致冲突。

目录结构

在仓库下建立如下目录结构：

ADlib
├─3d_models
│  ├─preview
│  └─step
├─footprints
│  ├─figures
│  ├─preview
│  │─report
│  ├─dimension_figure
│  └─package_types
│      └─figures
│          ├─dimension_figure
│          └─package_figure
├─scripts
├─sim_models
├─symbols
│  │─preview
│  └─report
└─templates

其中：

• 3d_models：存放3d模型文件，包括preview和step文件。
• footprints：存放PCB封装文件，包括ad、kicad等不同ECAD软件的封装文件。
• scripts：存放脚本文件，用于批量生成元器件库文件。
• sim_models：存放仿真模型文件，用于仿真分析。
• symbols：存放原理图符号文件，包括ad、kicad等不同ECAD软件的原理图符号文件。
• templates：存放模板文件，用于批量生成元器件库文件。

注意：Altium Designer新版库文件和3d模型库文件在Git中应按照二进制文件处理，建议使用Git LFS进行管理。

文件命名

为确保元器件库的可读性和可维护性，遵循原子操作原则：一个库文件只包含一个原理图符号、一个PCB封装图形和一个3d模型。文件命名应遵循一定的规范，可以约定：

1. 原理图符号文件：sym-xxxx.SchLib，其中xxxx为数字流水号。文件内符号名称与文件名一致。
2. PCB封装图形文件：fp-xxxx.PcbLib，其中xxxx为数字流水号。3d模型变体使用数字尾缀；装配密度变体使用字母l m n尾缀，n表示常规密度，m为低密度，l为高密度，插件可省略；封装方向变体用q1 q2 q3 q4尾缀。例如：fp-0001-1-n-q1.PcbLib，插件可省略。文件内封装图形名称与文件名一致。
3. 3d模型文件：3d-xxxx-x.step，与PCB封装图形一一对应。

注意: 不要在库文件中添加元器件属性等附加信息，避免与CIS中的字段冲突。

提交规范

提交信息应遵循一定的规范，以便于后续的代码审查和问题追踪。可以约定：

1. 提交信息格式：[类型] 描述
2. 类型：add, fix
3. 描述：简短描述，不超过50个字符，描述清楚提交的目的和内容。
4. 提交消息体中应包含具体描述信息。

例如：

add: sym-0001, 通用电阻符号

description: 通用电阻
pin_count: 2
ep_pin_count: 0
type: standard
...

3d模型文件可以与PCB封装图形库文件一起提交，也可以单独提交。建议有3d模型的PCB封装库文件也单独保存一个3d模型库文件，这样可以方便后续的管理。

审核合并

提交并推送到远程仓库后，开发者发起合并请求，由管理员审核后，合并到主分支上。合并请求应包含详细的描述信息。

更新CIS

合并到主分支后，管理员要及时更新CIS数据库，确保团队内的所有成员都使用最新的元器件库。

公众号 | FunIO
微信搜一搜 “funio”，发现更多精彩内容。
个人博客 | blog.boringhex.top