把什么放在Git中

Question

我目前的任务是将我的商店从Clearcase搬到Git的精彩世界。在这样做的过程中，我发现了我的商店在版本控制中保留的各种各样的垃圾垃圾，这种垃圾已经膨胀了存储库的大小。

我发现的主要罪魁祸首是我们在Clearcase存储库中保留了路由器iOS配置映像。这些是巨大的二进制映像，数百兆字节。

我已经对Git做了一些阅读，并且建议我们应该保留在Git仓库中的唯一内容是源文件。大型二进制文件不应保留在版本控制中。

所以，我的问题是：处理路由器配置映像（或类似的东西）等文件的“标准”方法是什么？这些是我们的商店自己不维护的大型二进制文件，我们不能自己重新生成这些图像，但我们需要它们用于我们生产系统的部署基线。

Answer 1

  

处理路由器配置映像（或类似内容）等文件的“标准”方法是什么？

为了完成ClearCase to Git migration（many times before），我通常会将这些类型的工件放在工件存储库中，Nexus或Artifactory。< / p>

这样，这些二进制文件可以通过项目设置引用，并按需下载 项目设置是“声明性方法”的一部分，它非常适合Git：一个简单的文本文件，由构建工具处理，并相应地更新工作区。

Answer 2

没有严格的＃34;正确答案＆＃34;在这里，但您可以遵循一些指导原则。

一般规则：

• 所有源代码都已签入。
• 可以从源文件生成的文件不在版本控制中。这些是可执行文件或其他构建输出。
• 作为应用程序一部分的图像通常会被签入。因为它们是二进制文件，所以您无法进行文本差异。但git会很好地处理它们，并在添加新版本时存储它们。
• 第三方图书馆是一个灰色区域。大多数人会检查一个构建文件，如package.json，Gemfile或pom.xml，但排除库源/二进制文件。有些人喜欢检查第三方代码的额外安全/安全方面，例如，检查package.json和node_modules目录。

检查大型配置映像并不明确错误，但它可能会影响存储库的性能。正如 torek 所述，Git LFS可能是一个很好的解决方案。

另一个解决方案是简单地将大型配置映像放在所有开发人员可以访问它们的地方（http或ftp服务器等）。然后检查一个小脚本（可能是构建脚本的一部分），它获取正确的图像（如果尚未缓存）并将其放在本地文件系统所需的位置。在这种情况下，您需要签入Git的所有内容都是脚本。

Answer 3

版本控制应主要保留“主要对象”。主对象是不是从其他文件自动派生的文件。如果某个工具从A生成B，那么只有A应该在版本控制中，至少理想。某些情况可以证明B在版本控制中也是合理的。例如，程序必须在不存在A到B工具的环境中构建。

编译器引导中出现一个例子。假设项目实现了一种名为L的语言，其编译器输出C.大部分L都是用L本身实现的！糟糕，许多目标用户没有L编译器来构建L源;他们只有一个C编译器。除非存储库包含L源文件的C版本（否则它们以某种方式获得它们），那些用户无法拉回存储库并构建L编译器。

大型二进制文件可以是主要对象。例如，视频游戏的图像数据等。肯定需要处理大型二进制文件的版本控制。

在版本控制系统中处理不能很好地处理这些文件的大型二进制文件的一种方法是将二进制文件保存在某些服务器上（在版本化路径下），并将这些路径存储在repo中（以某种参数化方式）因此，如果路径必须更改，则repo的用户只需更改一些环境变量。

有时候二进制文件是其他一些repo的派生对象。例如，你有一些嵌入式系统项目在repo中有各种各样的软件。其中一个部分是系统启动时上传到某个芯片的某些固件。这来自其他一些回购;你不建立它。因此，只检查该固件的二进制图像。固件是来自某些原色的派生对象，但您要么没有它们，要么因为依赖性而不想引入这些原色（如需要整个工具链）建立它们等等。