我可以阻止 Git 压缩我的音频文件吗
我正在做的项目存储在 GitHub 中。它是一个桌面应用程序，有一些音频资产，我和我的团队需要将其保留在存储库中。
我很快发现，一旦文件被推送到存储库，它们就会受到严重压缩并变得完全无用。
我无法在这里共享存储库，因为它是私有的，但音频文件是 .wav 格式的简单音效，不超过 2MB。我们甚至决定转向 .mp3，以便获得更小的文件。尽管我不确定 git 是否做了一些进一步的压缩，但效果很好。
问题是我们只有一个更大的 .mp3，大约一分钟长，大约 3MB。当然，一旦推送到远程存储库并再次拉取，由于压缩，它会出现一些裂缝。
我找不到任何关于此的文档。我不知道这是 git 特有的问题还是 GitHub 特有的问题。
我可以选择配置压缩阈值吗？或者还有其他方法可以解决这个问题吗？我认为我没有存储一些非常大的二进制文件，这似乎是一个非常常见的情况。
感谢您花时间在这上面！
The project I'm working on is stored in GitHub. It is a desktop app and has a few audio assets, that me and my team need to keep in the repository.
I quickly discovered that as soon as the files are pushed to the repository, they undergo a severe compression and become totally useless.
I cannot share the repository here, because it is private, but the audio files are simple sound effects in .wav format, that are no bigger than 2MB. We even decided to move to .mp3, in order to have smaller files. This worked fine, even though I'm not sure if git has done some further compression.
The problem is that we have only one bigger .mp3, about a minute long, that is a around 3MB. Of course, once pushed to the remote repository and pulled again, it has some cracks, due to compression.
I could not find any documentation about this. I don't know if it is a git-specific or a GitHub-specific problem.
Is there an option for me to configure the compression threshold? Or is there any other approach to solve this issue? I would argue that I'm not storing some insanely big binaries and it seems like a very common scenario.
Thank you for spending time on this!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
感谢所有评论和分享见解的人，问题已解决。我将根据所有评论和我的一些发现尝试总结解决方案：
.gitattributes文件可以提供行结尾行为的配置。事实证明，在我的存储库中存在这样的文件，并且它有一个一般规则，我认为这是罪魁祸首：* text eol=lf由于 git 将音频文件视为文本，所以可以理解为什么他们会经历这种格式化。这解释了为什么他们事后听起来“破碎”。
*.mp3 binary添加到.gitattributes文件足以解决我的问题。所有.mp3文件现在都被视为二进制文件，并且不进行格式化。The problem is solved, thanks to everyone that commented and shared insights. I will try to summarize the solution, based on all the comments and some of my findings:
.gitattributesfile can provide configuration for the behaviour of line endings. It turned out that in my repository such file existed and it had a general rule, which I believe was the main culprit:* text eol=lfSince git treats the audio files as text, it is understandable why they go through this formatting. And this explains why they sound "broken" afterwards.
*.mp3 binaryto the.gitattributesfile was enough to solve my issue. All.mp3files are now treated as binaries and don't go through formatting.