我想配置git存储库，因此它不会记住一个长文件的历史记录，但仍会保留其最新版本。
有可能吗？
P.S。谢谢你的回答---我现在确信我不想这样做。
答案 0 :(得分：3)
所以......有几个人（评论和Hauleth的回答）推荐像LFS这样的解决方案，它可以有效地管理git repos中的大文件需求。似乎没有人能够确定你为什么会想要你指定的行为，而不是这些给出的行为......而且这是有充分理由的。 git的一个重要目的是能够重现过去版本的代码。如果我们将您期望的行为与LFS进行比较，那么最大的区别在于，在您期望的行为下，再现先前版本的系统变得不可能。所以它真的不清楚为什么你会想要它。
但那很好......让我们回答你的问题。
可以吗？嗯...通过使用git以便它甚至无法正常执行基本的源代码控制功能，你可以伪造它。但它并不容易，git会在每一步都对你不利。听起来不错？
在你去询问之前＆＃34; RsrchBoy的解决方案＆＃34;那个涉及让git能够使用你的回购的能力。他们在哪里看到您的问题＆＃34; [暗示您已经编辑了提交历史记录＆＃34;}，我发现它显示您不了解不断编辑提交历史记录的后果。
很难正确完成，特别是作为日常工作流程的一部分。
它变得更难，因为根据定义，您的用例需要编辑历史记录（a）进行暂挂更改等待提交，或（b）提交您不想编辑的更改后。
一旦你正确地工作，每次你这样做时，refs将以非快进的方式移动，让所有共享repo的人处于不良状态。如果他们做错了从该状态恢复，则该文件的额外副本可以弹回到历史记录中。即使每个人都参与其中，保持远程控制不要囤积文件的所有过时副本仍然可能非常困难（取决于您的远程主机的托管方式）。
也许那些最后的担忧并不会让你担心，因为也许你是你的回购的唯一用户，也许你不能保留遥控器。如果是这种情况 - 如果您不使用git作为分布式版本控制系统的关键优势，并且您正在尝试针对其历史跟踪模型进行某些操作 - 那么git可能不是您用例的最佳工具。
或者，正如其他人暗示的那样，也许它是需要重新评估的用例。你和你的团队之间可能存在的任何事情。
答案 1 :(得分：1)
你不能在不使整个历史失效的情况下改变过去的提交，这只是Git的工作方式。因此，如果这是需要版本化的大文件，但它的版本控制是不可行的，那么你有以下形式的替代品：
允许您使用单独的树来存储＆＃34;标准＆＃34;之外的blob。 Git的树。
答案 2 :(得分：-1)
您的问题意味着您可以编辑提交历史记录，因为这是您提出要求的唯一方法。
git filter-branch
命令，因为它会按照您的要求进行操作。保留有问题的文件的最新版本对于读者来说是一种练习（虽然我只是在filter-branch完成它之后再将其提交回来）。
请注意，根据存储库的历史记录和使用模式，这将产生重大影响。 （OTOH，如果它只是你使用的回购，那么这些影响可能会更少。）
如果您只是希望减少克隆/ repo大小，执行浅克隆（或使您的克隆变浅）可能会做您想要的事情而对其他消费者没有全局影响存储库。 （有关浅层的更多信息，请参阅git-fetch和git-clone。）