相关疑难解决方法(0)

我正在寻找如何处理我的源代码(Web应用程序)所依赖的大型二进制文件的意见.我们目前正在讨论几种选择:

1. 手动复制二进制文件.
   • 亲:不确定.
   • Contra:我强烈反对这一点,因为它增加了在设置新站点/迁移旧站点时出错的可能性.建立另一个障碍.
2. 用Git管理所有这些.
   • 专业:删除'忘记'复制重要文件的可能性
   • 反对:膨胀存储库并降低管理代码库和检出,克隆等的灵活性将需要相当长的时间.
3. 单独的存储库.
   • Pro:检查/克隆源代码的速度很快,图像可以在自己的存储库中正确存档.
   • Contra:删除了在项目中拥有唯一的 Git存储库的简单性.它肯定会介绍一些我没有想过的其他事情.

您对此有何体验/想法？

另外:有没有人有多个Git存储库的经验并在一个项目中管理它们？

这些文件是程序的图像,该程序生成包含这些文件的PDF.文件不会经常更改(如年份),但它们与程序非常相关.没有文件,程序将无法运行.

有谁知道文件数量和文件大小的Git限制是什么？

情况

我有两台服务器,生产和开发.在生产服务器上,有两个应用程序和多个(6)数据库(MySQL),我需要将它们分发给开发人员进行测试.所有源代码都存储在开发服务器上的GitLab中,开发人员只能使用此服务器,并且无权访问生产服务器.当我们发布一个应用程序时,master会登录到生产环境并从Git中提取新版本.数据库很大(每个超过500M并且数不胜数),我需要尽可能简单地将它们分发给开发人员进行测试.

可能的解决方案

• 在将数据库(每个数据库)转储到单个文件的备份脚本之后,执行将每个数据库推送到其自己的分支的脚本.如果开发人员想要更新他的本地副本,则会拉出其中一个分支.

  发现这个不起作用.

• 生产服务器上的Cron每天都会保存二进制日志,并将它们推送到该数据库的分支中.因此,在分支中,有每日更改的文件,开发人员会提取他没有的文件.当前的SQL转储将以另一种方式发送给开发人员.当存储库的大小变得太大时,我们将向开发人员发送完全转储并刷新存储库中的所有数据并从头开始.

问题

• 解决方案可行吗？
• 如果git正在推送/拉出存储库,它是上传/下载整个文件,还是只更改它们(即添加新行或编辑当前的行)？
• Git可以管理如此大的文件吗？没有.
• 如何设置存储库中保留的修订数量？与新解决方案无关.
• 有没有更好的解决方案？我不想强迫开发人员通过FTP或类似的东西下载这么大的文件.

我已经使用git一段时间来进行源代码控制了,我真的很喜欢它.所以我开始调查使用git来存储大量的二进制文件,我发现这不是git的一杯茶.那么大文本文件呢？似乎git应该处理那些就好了,但我也遇到了问题.

我正在使用550mb大小的mbox样式文本文件测试它.我git init'ed新的回购做这件事.这是我的结果:

• git add和git commit - 总回购大小为306mb - repo包含一个大小为306mb的对象
• 添加一封电子邮件到邮箱文件和git commit - 总回购大小为611mb - repo包含两个对象,每个对象大小为306mb
• 再添加一封电子邮件到邮箱文件和git commit - 总回购大小为917mb - repo包含三个对象,每个对象大小为306mb

因此,每次提交都会将邮箱文件的新副本添加到repo中.现在我想尝试将回购的大小降低到易于管理的程度.这是我的结果:

• git repack -adf - 总回购大小为877mb - repo包含一个大小为876mb的包文件
• git gc --aggressive - 总回购大小是877mb - repo包含一个大小为876mb的包文件

我希望能够将回购的大小缩小到306mb左右,但我无法弄清楚如何.任何更大的东西似乎都存储了很多重复的数据.

我希望回购只会增加收到的新电子邮件的大小,而不是整个邮箱的大小.我不是试图在这里控制电子邮件的版本,但这似乎是我使用夜间脚本逐步备份用户主目录的重大阻碍.

有关如何在将大量文本插入到非常大的文本文件末尾时保持repo大小不被破坏的任何建议？

我看过bup和git附件,但是如果可能的话,我真的很想坚持使用普通的git.

谢谢您的帮助!

我目前正在使用git作为一个大型存储库(大约12 GB,每个分支的大小为3 GB).此存储库包含许多二进制文件(音频和图像).

问题是克隆和拉取可能需要很多时间.特别是"解决增量"步骤可能非常长.

解决这类问题的最佳方法是什么？

我尝试删除增量压缩,因为它在此处使用.gitattributes中的delta选项进行了解释,但它似乎没有改善克隆持续时间.

提前致谢

凯文

在SO和其他地方以各种形式提出了这个问题，但是我找不到能使我满意的答案，因为没有人列出有问题/没有问题的动作/命令，也没有对速度下降的技术原因进行透彻的解释。 。

例如：

• 为什么Git无法处理大型文件和大型存储库
• 为什么在repo变大时git操作会变慢
• 对于100,000个对象，Git确实很慢。有任何解决办法吗？

因此，我不得不再次问：

1. 基本的git操作（commit，push，pull，add，fetch，branch，merge，checkout）中，当存储库变大时，这些操作会变慢（注意：存储库，不是此问题的文件）

和，

2. 为什么每个动作都取决于回购规模（或不取决于回购规模）？

我现在不在乎如何解决这个问题。我只关心哪个动作的性能受到影响，以及根据当前git架构的推理。

编辑以澄清：

很明显，git clone例如，将是回购规模的o（n）。

但是我不清楚这是git pull一样的，因为从理论上讲只看差异是可能的。

Git在幕后做了一些非常琐碎的事情，我不确定何时何地。

编辑2：

我发现这篇文章，说

如果您的存储库中有大型不可分散的文件（例如二进制文件），则每次对文件进行更改时，都将在该存储库中保留该文件的完整副本。如果您的存储库中存在这些文件的许多版本，则它们将大大增加签出，分支， 获取和克隆代码的时间。

我不明白为什么分支需要花费超过O（1）的时间，而且我也不确定列表是否已满。（例如，拉动怎么样？）