在使用git控制硬件项目固件的源代码时，将KiCAD原理图/PCB放在同一个repo中是一个好主意吗？

我已经使用VCS来控制我开发的软件和固件。最近在硬件方面做了一些工作，并得出结论，在git中控制KiCAD原理图和PCB文件也是可行的（请查看），我想知道在同一个git repo中有固件和硬件原理图——可能被同一个项目和问题跟踪者引用——可能会非常有趣和高效，因为硬件和固件是如此密切相关

很多时候，固件中的新功能需要您修改电路板，反之亦然，因此最初我认为这两个功能可以在同一个git存储库中一起控制，可能有如下子目录方案：

project (in git)
   - kicad
   - firmware

其中，subdir

kicad

将包含所有原理图和PCB文件，

固件

将包含固件的源代码，固件应在kicad中设计的硬件上运行

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

你有没有试过或想过？你能预见到任何“showtopper”或强烈建议不要这样做的事情吗？

从你的链接：

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

如果原理图和

PCB

文件是文本文件，这可能是一个好主意，而且几乎没有什么缺点

二进制文件 然而，如果它们是二进制文件，那就要看情况了。在我看来，git的“最坏情况”文件都是：

• 大的
• 高熵（小的逻辑更改会导致文件发生大的更改，例如压缩/加密）
• 频繁变化

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

团队工作流程 您链接的文章还讨论了一些处理粗糙边缘的附加功能：

• 配置gitignore

• clean

  /

  smudge

  忽略非逻辑项目文件

  在

  日期保存
• 图解扩散

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

现在投入这项工作意味着自动化工作流程和防止未来的麻烦——你必须权衡收益/成本