我有一个190 MB纯文本文件,我想在github上跟踪.
文本文件是我们的文本到语音引擎的代词词典文件.我们经常在文本文件中添加和修改行,并且差异相当小,因此在这个意义上它非常适合git.
但是,GitHub具有严格的100 MB文件大小限制.我已经尝试过GitHub大文件存储服务,但每次更改时都会上传整个190 MB文件的新版本 - 因此,如果我沿着这条路走下去,那么它将迅速增长到几千兆字节.
我想将文件保存为一个文件而不是拆分它,因为这是我们的工作流程当前的方式,并且需要一些编码才能允许多个文本文件作为我们工具中的输入/输出(并且我们没有太多的开发资源) .
我有一个想法是,也许可以设置一些预提交和提交后挂钩来自动拆分和连接大文件？这可能吗？
其他想法？
编辑:我知道StackOverflow上类似问题中描述的100 MB文件大小限制,但我不认为我的问题是重复的,因为我要求的是差异很小且频繁的特定情况(我'我没有尝试上传大型ZIP文件或任何东西).但是,我的理解是git-lfs仅适用于很少更改的文件,而普通的git非常适合我所描述的那种文件; 除了GitHub有文件大小限制.
更新:我昨天花了一些时间尝试创建一个小型跨平台程序,该程序使用git hooks将文件拆分并连接成较小的文件.它有点工作但不太令人满意.您需要将.gitignore排除大文本文件,这使得git不知道它是否已更改.拆分文件最初没有检测到git status或git commit导致与此SO问题中描述的相同问题,这非常烦人:预提交脚本创建mysqldump文件,但"没有提交(工作目录清理)"？
设置一个cron作业(linux)和计划任务(windows)以定期自动重新生成拆分文件可能会解决这个问题,但是自动设置并不容易,可能会导致用户计算机出现性能问题,而且不是很优雅解.可能还需要一些像动态修改.gitignore这样的hacky解决方案,并且绝不会得到实际文本文件的差异,只有分割文件(尽管这可能是可接受的,因为它们非常相似).
所以,睡着了,今天我觉得git hook方法毕竟不是一个好选择,因为它有太多的怪癖.正如@PyRulez所建议的那样,我想我不得不看看除GitHub之外的其他服务(不幸的是,因为我喜欢github).托管解决方案更可取,以避免必须管理我们自己的服务器.我也希望它能公开上市......
更新2:我已经看了一些GitHub的替代品,目前我倾向于使用GitLab.我已经联系了GitHub关于提高100MB限制的可能性的支持,但如果他们不这样做,我将只为这个特定项目切换到GitLab.