原理图和源代码的版本控制

我正在开发一种电子设备，该设备分为两部分：硬件（Eagle原理图）和固件（C ++源代码）。我想跟踪源代码和原理图的变化，但是有些地方我不确定如何组织我的工作：

对于源代码，我肯定会使用Git。但是，当原理图实际上是二进制文件时，它们是否值得进行版本控制（新的Eagle版本使用某种XML格式，但人类可读性不高...）？
将源代码和原理图放入一个Git存储库是个好主意吗？这是有道理的，但另一方面，我的日志将包含软件和硬件更改。此外，软件可以具有多个分支，但是硬件可能没有分支。
如何处理硬件修订版？标记它们还是将它们保存在单独的目录中？
硬件版本和固件版本之间也可能存在某些依赖关系。如何处理？

您能和我分享您的最佳做法吗？

eagle hardware c++

— 克拉西克
source

商业解决方案会起作用吗？

— 尤金（Eugene Sh）。

我不会再碰到商业版本控制系统了。我对它们的经验是糟糕的工作流程，这些工作流程比svn甚至git更难使用。

— pjc50 '17

无论使用哪种版本控制软件，在处理原理图而不查看文本时，请确保它正在替换整个文件。过去我一直是个问题。您永远都不想对大多数原理图文件进行比较。

— 电压峰值

Answers:

大部分归结为个人喜好。

我跟踪在Git中为项目所做的所有工作。尤其是因为Git可以高效地处理大多数类型的文件（甚至二进制文件）。（代替内置的Altium SVN废话）

我这样做的主要原因之一是，我的客户并不都对Dropbox感到足够安全，并且我需要一个可以在世界范围内访问的备份系统，并且在大多数操作中还需要一些版本控制上下文。因此，我建立了一个私有的Git服务器和加密的备份系统，它可以正常工作。电路板，原理图，代码，文档，报告，手动修改，所有内容均得到跟踪。

我通常会创建一个硬件存储库，一个软件存储库，以及一个固件存储库，如果它是一个大型的，可能长期运行的项目，但是对于小型服务项目，示例或小实验，我通常将它们全部放在一个存储库中，因为这样会导致混乱不会很大。

在Git中，即使子仓库是单独管理的仓库，您也可以使用子仓库将固件集成到硬件项目中。

对于大型项目，我通常也使用错误跟踪系统来跟踪问题和解决方案，对于硬件和软件，Mantis也是一个不错的免费软件。

对于硬件修订版，我生成Gerber或任何带有Git Hash标记的版本，那么这些Gerber就是R01、02等文件夹中唯一离散的“老式”版本化的东西。因为您不想一直都在重新生成它们，但是它们都是生成的文件，因此实际上不应该在Git中进行版本控制（因为您的设计软件应具有确定性，可以生成生产内容，否则...）。

如果R01中没有发生有趣的事情，或者R02中没有发生（或者相反），则您有两个Git哈希可以与它们比较源文件，不用担心。

最后，项目的一个概念示例将包含一个硬件存储库，该存储库还托管一个“ BoardPinout.h”文件。该文件作为远程版本控制文件包含在固件存储库中，该库具有一些接口定义文件，这些接口定义文件被远程包含在软件存储库中。

这意味着每次我在不修改广泛功能的情况下更改一些信号时，硬件项目都会“更新” BoardPinout，然后可以对其进行更新并在固件中使用，等等。

— Asmyldof
source

它是否真的曾经是有意义的把硬件和固件不同的回购？将它们合而为一怎么会有问题？如果您需要跟踪组成在一起的组件的更改，我希望它会成为一个问题（例如，交换的IO引脚需要反映在不同的固件分配中，而检查无法兼容的版本会导致混乱）。

— 左右约

@leftaroundabout首先，用复杂的CAD设计来充实快速变化的固件仓库并不总是您想要的，但是您可能还想重新阅读有关子仓库及其之间链接的信息。使用Git一点也不难，并且可以在不引起设计领域之间各种不适当亲密关系的情况下，准确地解决该问题。

— Asmyldof

“我的客户并不都认为Dropbox足够安全”对于版本文件，他们100％正确。如果多个用户可以同时修改文件，则尤其危险，如果您有多个文件实际上包含一个资源，则更危险。我已经看到二进制“文件集”以这种方式损坏（ESRI文件地理数据库，如果您好奇的话）。

— jpmc26

@ jpmc26这是一个仓促的评论，最初从安全性的角度出发，对所有内容进行版本控制。现在，有了一些聪明的GitIgnore模板，版本控制就可以轻松地将所有内容轻松地包裹起来，并带来所有优点。我实际上完全同意您在共享Dropbox上的观点。在一个客户站点上，它会导致无尽的问题。正在开发的文件在计算机上产生了无穷无尽的冲突副本，而在部分开发过程中，这些副本是最烦人的文件之一。

— Asmyldof

@leftaroundabout：这取决于硬件和固件之间的关系。让我们与正常的软件项目进行类比。您会与网站一起提交gif和jpg文件吗？在这种情况下，即使图片不经常更改，二进制文件和源文件也会彼此更改。但是..您会在项目中提交Apache还是Nginx源代码。因此，您是否会提交Linux内核的源代码？在这种情况下，Apache或Nginx和Linux内核与硬件更相似-它们会发生变化，但独立于您在它们上运行的代码编写

— slebetman

1）它绝对值得对原理图/电路板文件进行版本控制。即使您无法轻松地跟踪差异，如果必须使用旧的设备修订版，也可以采用一种干净的方法来还原到特定的硬件版本。

2）我们的SVN具有以下结构。
/ tag
/分支机构
/ trunk /硬件
/ trunk /软件/固件

如果适用的话，还有更多子文件夹，例如软件的/ Firmware和/ ConfigTool以及软件的/ mainboard和/ daughterboard或类似的子文件夹。

2）标签是从子文件夹而不是整个主干创建的，例如Tag / Mainboard-v1.2.345。硬件（即PCB）始终在丝网印刷或铜制中包含SVN版本，以提供直接参考。

4）硬件和固件之间的依赖关系可能很复杂。IMO除了在提交时留下有用的注释之外，在存储库级别处理它没有多大意义。
考虑使用备用I / O引脚对硬件更改进行编码。例如使用4针来编码16种不同的硬件版本。我们还使用具有不同电阻值的单个ADC输入来编码版本。这样，软件可以“知道”它运行的硬件并更改/禁用/启用特定功能。

— 修订版1.0
source

我同意。我还看到了在每次正式发布时都构建“发布包”（示意图，BOM，gerber以及全部）的良好实践。您将它们称为A，B，C等，然后将它们存档在团队可以参考的位置。另外，不要忘记一些跟踪您在哪些原型板上完成的线模的方法。

— pjc50 '17

@ pjc50：实际上，我们也可以“构建”发行包，但不受源代码控制（但带有修订参考）。本质上，它将是制造商获得的所有产品的精确副本。如果您要大量生产而专业地进行硬件开发，那么在出现问题时随时提供所有信息非常重要。如果您不记得是否向董事会寄送了“这一重要文件”，其中可能指定了定制PCB铜的厚度，那么您可能会遇到麻烦。

— Rev1.0