你需要在多大程度上控制版本？

"磁盘"便宜的理论最近有点失控.版本控制的一些强大功能使我们能够使用一些引导文件和一个简单的命令来为新开发人员提供工具链.

最近对系统的升级促使了存储构建的二进制文件的请求.接下来是对整个虚拟化构建系统进行版本化的请求.添加到顶层的每个层都会在存储库之间创建重要的关系,并且需要良好的基础设计来管理它.

工具链的存储带来了即时的好处,同时通过即时负债存储构建的二进制文件.遗憾的是,在处理大型二进制文件时,Git存在一些基本问题.

您在哪里以正确的方式使用VC绘制线条,何时开始研究更合适的解决方案？

您可能不应该将"整个虚拟化构建系统"存储为巨型二进制文件.如果要对应用程序进行版本控制,则需要对源代码进行版本控制,而不是编译二进制文

许多商店所做的是在版本控制中存储重建构建服务器的步骤.然后你需要一个固定的图像(库存,开箱即用的OS安装),以及少量文件(在其上安装什么,以及如何安装).有些地方甚至让他们的服务器在干净的OS安装上从源代码重建应用程序,以进行每次部署/重启.

将操作系统映像本身版本化为巨型二进制文件并不是那么有用.你不能分支.你无法合并.你不能差异.重点是什么？你可以节省空间,如果你的VCS可以做二进制差异,但这可能需要大量的CPU和内存,如果他们在"磁盘是便宜的"狂欢,那么没有理由让生活变得痛苦只是为了节省磁盘空间.

将您的安装脚本/库存储在VC中并根据需要重建VM映像,或者只将VM映像存储在普通文件中.我没有看到将图像放入VCS中的任何意义.

我会说这里有一个操作顺序:

如果他们需要存储文件,请使用文件系统.

如果他们需要跟踪更改,请使用版本控制.

如果他们需要跟踪与数据的关系,请使用数据库.

要求越复杂,解决方案就越复杂.但对于那些想要更复杂的解决方案的人来说,纪律是有道理的; 在这些不确定的时期,必须避免浪费时间.

我总是把它放在版本控制中:

源代码和makefile:构建二进制文件所需的最小值.

测试套件

我从未在版本控制中添加的内容:

内置二进制文件:它们可以从源代码控制中重新创建,如果我知道我可能需要立即发布特定版本,我会以类似于Linux内核的方式将它们存储在文件系统中.

根据项目我在版本控制中放置的内容:

构建链:当我信任提供者或者我可以重新创建环境时,我不会将其置于版本控制中(Apple的Xcode,开源工具,如gcc或doxygen,......).我把它放在版本控制中,当它专门用于项目时(例如,自制的交叉编译链),当我需要重新创建一个二进制文件时,就像它为交付而构建时(用于在任何组件可能涉及时找到heisenbugs,来自操作系统或编译器的代码).