当使用git控制来自硬件项目的固件源代码时，将KiCAD原理图/印刷电路板放在同一存储库中是不是一个好主意？

Question

我已经使用git作为一个虚拟控制器来控制我开发的软件和固件。最近在硬件方面做了一些工作，得出的结论是，它是可行的控制KiCAD原理图和印刷电路板文件也在git (请看看https://jnavila.github.io/plotkicadsch)，我想知道有固件和硬件原理图在同一个git代码库-并可能被相同的github项目和问题跟踪器引用-可能是非常有趣和富有成效的，因为硬件和固件是如此密切相关。

很多时候，固件中的新功能需要你修改电路板，相反的情况也是非常正确的，所以最初对我来说，这两个功能可以在同一个git库中一起控制，可能有一个子目录方案，比如：

project (in git)
   - kicad
   - firmware

其中，子目录kicad将包含所有原理图和印刷电路板文件，而firmware将保存固件的源代码，该固件应在以KiCAD设计的硬件上运行。

这将利用项目的问题跟踪器来解决错误或设置里程碑，这通常需要在固件和硬件上执行操作，从而使开发和维护具有一致修改的产品变得更容易，使用不同的分支来测试新功能等。

你有没有试过或想过这一点？你能预见到任何“停止表演”或强烈建议不要这样做的东西吗？

Answer 1

从您的链接：

据我所知，

Kicad是唯一一个使用漂亮的文本格式来管理所有数据的电子CAD。

如果原理图和PCB文件是文本文件，这可能是一个好主意，而且几乎没有缺点。

二进制文件

然而，如果它们是二进制文件，那么这在某种程度上取决于。在我的脑海中，git的“最坏情况”文件都是：

更改size

• high-entropy中的大文件(小的逻辑更改会导致文件的大更改，例如compression/encryption)

• frequently

如果您的文件类型都是这三种类型，那么git将失去大量的效率。除此之外，git通常可以很好地处理二进制文件。

团队工作流

你链接的文章还谈到了一些额外的处理粗糙边缘的方法：

diffability

• configuring gitignore

• clean/smudge to ignore non-logical project file save_at dates

• schematic diffability

(将差异配置为忽略非逻辑项目文件)

所有这些事情都涉及到您希望在整个团队中同步的各种配置/定制。Git有很多强大的内置方式来定制行为(例如，提交/推送钩子)。也许您可以提交一个共享脚本，该脚本可以初始化存储库的这些自定义配置。

现在花费这一努力意味着自动化工作流程和防止未来令人头疼的问题--您必须权衡收益/成本。