我正在开发一种电子设备，它有两个部分：硬件（Eagle 示意图）和固件（C++ 源代码）。我想跟踪源代码和原理图的变化，但有些地方我不确定如何组织我的工作：
对于源代码，我肯定会使用 Git。但是当它们实际上是二进制文件（新的 Eagle 版本使用一些 XML 格式，但它不是那么人类可读......）时，它们是否值得版本化？
将源代码和原理图放在一个 Git 存储库中是个好主意吗？这是有道理的，但另一方面，我的日志将包含软件和硬件更改。软件也可以有几个分支，但硬件可能没有......
如何处理硬件修订？标记它们或将它们保存在单独的目录中？
硬件版本和固件版本之间也可能存在一些依赖关系。如何对付他们？
你能和我分享你的最佳实践吗？
其中大部分归结为个人喜好。
我在 Git 中跟踪我为一个项目所做的一切。特别是因为 Git 足够有效地处理大多数类型的文件，甚至是二进制文件。（代替内置的Altium SVN废话）
我这样做的主要原因之一是我的客户并不都觉得 Dropbox 足够安全，我需要一个可以在全球范围内访问的备份系统，而且我所做的大部分工作也有一些版本控制上下文。所以我建立了一个私人 Git 服务器和加密备份系统，它很有效。板、原理图、代码、文档、报告、手动修改，一切都被跟踪。
我通常会为硬件创建一个存储库，一个用于软件，一个用于固件，如果它是一个大型的、可能长期运行的项目，但对于小型服务项目、示例或小实验，我经常将它们全部放在一个存储库中，因为结果混乱不会很大。
在 Git 中，您也可以使用子存储库将固件集成到硬件项目中，或者反过来，即使它们是单独管理的存储库。
对于较大的项目，我通常也使用错误跟踪系统来跟踪问题和解决方案，同样对于硬件和软件，Mantis 是一个不错的可以免费使用的项目。
对于硬件修订，我生成 Gerber 或任何你有的，用 Git Hash 标记为该修订，这些 Gerber 是 R01、02 等文件夹中唯一离散的“老式”版本化的东西。因为你不想一直在重新生成它们，但它们是生成的文件，所以不应该在 Git 本身中进行版本控制，真的（因为你的设计软件应该在生成生产内容时是确定性的，否则......）。
如果 R01 中有一些有趣的事情在 R02 中没有发生（或相反），那么您有两个 Git 哈希，您可以使用它们来比较源文件，不用担心。
最后一点，项目的一个概念示例将有一个硬件存储库，该存储库还托管一个“BoardPinout.h”文件。该文件作为远程版本控制文件包含在固件存储库中，其中有一些接口定义文件可以远程包含到软件存储库中。
这意味着每次我在不修改广泛功能的情况下更改一些信号时，硬件项目都会“更新”BoardPinout，然后可以更新并在固件中使用，等等。
1）它绝对值得对原理图/电路板文件进行版本控制。即使您无法如此轻松地跟踪差异，如果您必须使用旧设备修订版，您也有一种干净的方法可以恢复到特定的硬件版本。
2）我们的SVN中有以下结构。
/tag
/branch
/trunk/硬件
/trunk/软件/固件
如果适用于更多子文件夹，例如 /Firmware 和 /ConfigTool 用于软件和 /mainboard 和 /daughterboard 或类似的硬件。
2) 标签是从子文件夹而不是从整个主干创建的，例如 Tag/Mainboard-v1.2.345。硬件（即 PCB）始终包含丝网印刷或铜版中的 SVN 修订版，以便直接参考。
4) 硬件和固件之间的依赖关系可能很复杂。IMO 除了在提交上留下有用的评论外，在存储库级别处理它没有多大意义。
考虑使用备用 I/O 引脚对硬件更改进行编码。就像使用 4 个引脚对 16 个不同的硬件版本进行编码一样。我们还使用具有不同电阻值的单个 ADC 输入来编码版本。这样，软件可以“知道”它运行的硬件并更改/禁用/启用特定功能。