在 Git 中放入什么答案

【问题标题】：What to Put in Git在 Git 中放入什么
【发布时间】：2018-02-02 21:27:07
【问题描述】：

我目前的任务是将我的商店从 Clearcase 转移到美妙的 Git 世界。在执行此操作的过程中，我发现了我的商店在版本控制中保存的各种虚假垃圾，导致存储库的大小膨胀。

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

我已经阅读了一些关于 Git 的文章，建议我们在 Git 存储库中唯一应该保留的就是源文件。不应将大型二进制文件保存在版本控制中。

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

【问题讨论】：

通常您会将它们存储在外部（存储库之外），并且可能在存储库中包含对外部存储实体的引用。一个 URL 可能就足够了，或者你可以存储一些本质上是虚构的 URL 的东西，这就是 Git-LFS 所做的。

标签： git

【解决方案1】：

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

由于完成了ClearCase to Git migration (many times before)，我通常将这些类型的工件放在工件存储库中，Nexus 或 Artifactory。

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

【讨论】：

【解决方案2】：

这里没有严格的“正确答案”，但您可以遵循一些准则。

一般规则：

所有源代码都已签入。
可以从源文件生成的文件不受版本控制。这些是可执行文件或其他构建输出之类的东西。
作为应用程序一部分的图像通常会被检入。因为它们是二进制的，所以不能进行文本比较。但 git 会很好地处理它们，在添加新版本时存储它们。
第三方库是一个灰色区域。大多数人会签入像 package.json、Gemfile 或 pom.xml 这样的构建文件，但不包括库源/二进制文件。有些人喜欢签入第 3 方代码的额外安全/安保方面，例如，会同时签入 package.json 和 node_modules 目录。

签入大型配置映像并非明确错误，但它可能会影响存储库的性能。正如 torek 所提到的，Git LFS 在这里可能是一个很好的解决方案。

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

【讨论】：

【解决方案3】：

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

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

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

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

有时二进制文件是一些其他存储库的派生对象。例如，您有一些嵌入式系统项目，该存储库中包含各种软件。其中之一是系统启动时上传到某个芯片的一些固件。这来自其他一些回购；你不建造它。因此，只签入了该固件的二进制映像。固件是从某些原色派生的对象，但您要么没有它们，要么由于依赖关系而不想拉入这些原色（就像需要的整个工具链构建它们等等）。

【讨论】：