git-友好的图像格式？
git-friendly image format?
对于repositories每天更新的数据图（包括稍微改变背景颜色渐变），我问自己是否有一些首选格式（或压缩算法）可以使用，这样git可以更有效地存储它们，而不必一直重写其中的大约 90%。
有没有比其他格式更'git-friendly'的图像格式？
由于 git 不是为（尽管它可以）处理二进制文件而设计的，我向您推荐优秀的 git-lfs extension（最初由 github 支持）：
因为 git，问题不在于版本控制的内容，而在于如何操作。
随着时间的推移，每日更新的数据图将生成 巨大的 数据量，这将在几年内成为克隆和获取的问题。
使用方法：
Download and install the Git command line extension. Once downloaded
and installed, set up Git LFS for your user account by running:
git lfs install You only need to run this once per user account.
In each Git repository where you want to use Git LFS, select the file
types you'd like Git LFS to manage (or directly edit your
.gitattributes). You can configure additional file extensions at
anytime.
git lfs track "*.psd" Now make sure .gitattributes is tracked:
git add .gitattributes Note that defining the file types Git LFS
should track will not, by itself, convert any pre-existing files to
Git LFS, such as files on other branches or in your prior commit
history. To do that, use the git lfs migrate1 command, which has a
range of options designed to suit various potential use cases.
There is no step three. Just commit and push to GitHub as you normally
would; for instance, if your current branch is named main:
git add file.psd git
commit -m "Add design file"
git push origin main
它的作用：
Git LFS stores a pointer file in the git repo in lieu of the real
large file. The pointer is swapped out for the real file at checkout
(using smudge and clean). The smudge and clean filters are part of
core Git and are designed to allow changing a file on checkout
(smudge) and on commit (clean). Git LFS uses these techniques to
replace the pointer files with the actual large files that are in use.
编辑
正如我在你的问题下评论的那样，你可以考虑使用像 PNG 这样的未压缩图像类型，这样 git 可以随着时间的推移优化增量，因为这种格式的两张相对接近的图片将有一个接近的二进制表示，这对于压缩格式（例如 JPEG ）不一定相同（这取决于您的图片及其每天的变化，但由于这是一个情节，png 应该明确地做到这一点）。
另一个建议是在子模块内处理图片（除非它是专用的 image-only 存储库），因此版本化图像的超重不会影响整个存储库的克隆和获取。
理论
“Git 友好”的格式将是共享相同长字节序列的格式，无论它们是二进制还是文本。
现在，即使只更改背景颜色渐变，有损二进制格式也可能会更改大部分字节，而更具描述性的 text-based 格式可能不会。
使用您自己的文件进行测试
我推荐这个测试来计算您实际用例中不同文件格式的压缩大小。
- 在开始之前，获取沙盒或克隆，并积极压缩它，以便我们知道后续步骤中的进一步压缩不是由于添加了图像：运行
git gc --aggressive 几次, 直到 du .git 两次产生相同的答案。
现在，对于您要测试的每种文件格式，将该沙箱复制到一个新目录中并执行以下步骤：
添加一组图像并通过 运行 多次 git gc --aggressive 再次积极压缩 repo，直到 du .git 两次产生相同的答案。
写下 du .git 告诉你的：那是你的基准尺码。
添加并提交一组新文件，您在问题中描述的方式略有变化。
现在 du .git 告诉您将这些文件添加到存储库中的大小。在提交时，Git 不会（通常）尝试应用增量压缩或打包，它只是为每个提交的文件添加一个新的 blob，除非已经存在相同的 blob。
再次运行git gc --aggressive直到大小稳定。
现在 du .git 告诉您 Git 能够通过它找到的任何方式压缩这些文件，可能是增量压缩。这里的大小减去第 2 步的大小就是添加一组新文件的 space 成本。
通过运行针对图像的不同文件格式执行上述过程，您将获得针对您的用例的答案。
Git LFS 可能是你的朋友
PS：综上所述，我支持@Nicolas Voron 的回答：除非上述大小成本对于您最终选择的文件格式来说实际上很小，否则请使用 Git LFS 以避免当你的回购变得太大而无法克隆时，将来会产生问题。
好的，所以似乎没有通用的答案，相应的 SOF 社区的答案似乎是：
- 盲目尝试
- 不要像你想的那样存储图像
…没关系，遇到一个对压缩类型有真正专业知识的人一起玩真是太幸运了。尽管如此，还是感谢您的尝试。
对于repositories每天更新的数据图（包括稍微改变背景颜色渐变），我问自己是否有一些首选格式（或压缩算法）可以使用，这样git可以更有效地存储它们，而不必一直重写其中的大约 90%。
有没有比其他格式更'git-friendly'的图像格式？
由于 git 不是为（尽管它可以）处理二进制文件而设计的，我向您推荐优秀的 git-lfs extension（最初由 github 支持）：
因为 git，问题不在于版本控制的内容，而在于如何操作。 随着时间的推移，每日更新的数据图将生成 巨大的 数据量，这将在几年内成为克隆和获取的问题。
使用方法：
Download and install the Git command line extension. Once downloaded and installed, set up Git LFS for your user account by running:
git lfs installYou only need to run this once per user account.In each Git repository where you want to use Git LFS, select the file types you'd like Git LFS to manage (or directly edit your .gitattributes). You can configure additional file extensions at anytime.
git lfs track"*.psd" Now make sure .gitattributes is tracked:
git add .gitattributesNote that defining the file types Git LFS should track will not, by itself, convert any pre-existing files to Git LFS, such as files on other branches or in your prior commit history. To do that, use the git lfs migrate1 command, which has a range of options designed to suit various potential use cases.There is no step three. Just commit and push to GitHub as you normally would; for instance, if your current branch is named main:
git add file.psd git
commit -m "Add design file"
git push origin main
它的作用：
Git LFS stores a pointer file in the git repo in lieu of the real large file. The pointer is swapped out for the real file at checkout (using smudge and clean). The smudge and clean filters are part of core Git and are designed to allow changing a file on checkout (smudge) and on commit (clean). Git LFS uses these techniques to replace the pointer files with the actual large files that are in use.
编辑
正如我在你的问题下评论的那样，你可以考虑使用像 PNG 这样的未压缩图像类型，这样 git 可以随着时间的推移优化增量，因为这种格式的两张相对接近的图片将有一个接近的二进制表示，这对于压缩格式（例如 JPEG ）不一定相同（这取决于您的图片及其每天的变化，但由于这是一个情节，png 应该明确地做到这一点）。
另一个建议是在子模块内处理图片（除非它是专用的 image-only 存储库），因此版本化图像的超重不会影响整个存储库的克隆和获取。
理论
“Git 友好”的格式将是共享相同长字节序列的格式，无论它们是二进制还是文本。
现在，即使只更改背景颜色渐变，有损二进制格式也可能会更改大部分字节，而更具描述性的 text-based 格式可能不会。
使用您自己的文件进行测试
我推荐这个测试来计算您实际用例中不同文件格式的压缩大小。
- 在开始之前，获取沙盒或克隆，并积极压缩它，以便我们知道后续步骤中的进一步压缩不是由于添加了图像：运行
git gc --aggressive几次, 直到du .git两次产生相同的答案。
现在，对于您要测试的每种文件格式，将该沙箱复制到一个新目录中并执行以下步骤：
添加一组图像并通过 运行 多次
git gc --aggressive再次积极压缩 repo，直到du .git两次产生相同的答案。写下
du .git告诉你的：那是你的基准尺码。添加并提交一组新文件，您在问题中描述的方式略有变化。
现在
du .git告诉您将这些文件添加到存储库中的大小。在提交时，Git 不会（通常）尝试应用增量压缩或打包，它只是为每个提交的文件添加一个新的 blob，除非已经存在相同的 blob。再次运行
git gc --aggressive直到大小稳定。现在
du .git告诉您 Git 能够通过它找到的任何方式压缩这些文件，可能是增量压缩。这里的大小减去第 2 步的大小就是添加一组新文件的 space 成本。
通过运行针对图像的不同文件格式执行上述过程，您将获得针对您的用例的答案。
Git LFS 可能是你的朋友
PS：综上所述，我支持@Nicolas Voron 的回答：除非上述大小成本对于您最终选择的文件格式来说实际上很小，否则请使用 Git LFS 以避免当你的回购变得太大而无法克隆时，将来会产生问题。
好的，所以似乎没有通用的答案，相应的 SOF 社区的答案似乎是：
- 盲目尝试
- 不要像你想的那样存储图像
…没关系，遇到一个对压缩类型有真正专业知识的人一起玩真是太幸运了。尽管如此，还是感谢您的尝试。