如何看待 GitHub 新推出的 Large File Storage (LFS)?
GitHub 新推出的 Large File Storage (LFS) 绝对是件大事，尤其是对于我们这些经常和大型文件打交道的人来说。我早就盼着 GitHub 能在处理这类问题上有所突破了，LFS 的到来，简直就像给 Git 装备上了“重型武器”。
LFS 究竟是个啥？
简单来说，LFS 就是 GitHub 针对 Git 在处理大型二进制文件（比如设计图、视频、音频、数据集、游戏资产等等）时效率低下的问题，提供的一个解决方案。
咱们都知道，Git 的设计初衷是管理文本代码，它在跟踪文本文件的每一次细微变化上做得非常出色。但当面对动辄几兆、几十兆甚至几百兆的二进制文件时，Git 的工作方式就会显得力不从心：
仓库体积爆炸式增长： 每次修改一个大文件，Git 都会把整个文件的新版本都存下来。即使你只改了其中很小一部分，仓库的体积也会像吹气球一样迅速膨胀。这不仅占用大量的磁盘空间，下载和克隆仓库也变得异常缓慢。
操作卡顿、效率低下： 像 `git checkout`、`git pull` 这样本来很快速的操作，在遇到大文件时会变得异常痛苦，可能需要等待很长时间。
历史记录混乱： 每次修改大文件都会产生一个新的完整版本，历史记录里充斥着大量的大文件，查找和管理起来非常不方便。
LFS 怎么解决这些问题的？
LFS 的核心思路是：“不要把大文件直接塞进 Git 仓库里，而是用一个指针代替，真正的文件存储在 Git 仓库之外。”
让我来详细拆解一下它的工作原理：
1. 安装和配置：
首先，你需要安装 Git LFS 客户端。这很简单，官网有各个平台的安装包。
然后，在你的 Git 项目中，你需要告诉 LFS 哪些类型的文件需要被 LFS 管理。通常是通过 `git lfs track ".psd"` 这样的命令来指定文件扩展名。
执行 `git lfs track` 命令后，会在你的项目根目录下生成一个 `.gitattributes` 文件，里面记录了哪些文件类型由 LFS 管理。这个 `.gitattributes` 文件是需要提交到 Git 仓库里的，这样其他人拉取代码时，Git 才知道哪些文件需要通过 LFS 来处理。
2. 文件的“代理”：
当你修改了被 LFS 管理的文件（比如你修改了一个 PSD 设计图），Git LFS 客户端会拦截这个操作。
它不会把新的 PSD 文件直接添加到 Git 的对象数据库里。
取而代之的是，它会生成一个小小的文本文件，这个文本文件里包含着这个大文件的元信息，比如它的 SHA256 hash 值、文件大小等等。这个小文本文件才是真正被 Git 跟踪和提交到 Git 仓库里的。你可以把这个小文本文件理解成一个“占位符”或者“指针”。
3. 文件的实际存储：
同时，Git LFS 客户端会把你修改的大文件上传到一个专门的大文件存储服务器。这个服务器可以是你自己搭建的，也可以是 GitHub 提供的（在 GitHub 上的行为）。
当你在另一个地方克隆或者拉取这个项目时，Git 会先拉取到那些“指针”文件。
当你的 Git 客户端（安装了 LFS 客户端）检测到这些是 LFS 指针时，它就会自动去那个大文件存储服务器上下载实际的文件，并替换掉仓库里的指针。
LFS 带来的好处（我最看重几点）：
仓库体积控制得当： Git 仓库里只剩下小小的文本指针，仓库的体积得到了极大的控制。克隆、拉取、切换分支的速度都会大幅提升，体验简直是天壤之别。
版本控制的连续性： 即使是大型文件，LFS 也能很好地跟踪其版本变化。虽然仓库里存的是指针，但 LFS 机制保证了你可以轻松地获取到任何一个历史版本的大文件。
工作流程的顺畅： 开发者无需再担心因为提交大文件而拖慢整个团队的开发进度。大家都可以专注于代码本身，而 LFS 会默默地处理好大文件的存储和同步。
兼容性： LFS 的设计原则是尽可能地融入现有的 Git 工作流程。大多数 Git 命令（如 `git commit`, `git checkout`, `git pull`）在安装了 LFS 客户端后，都能自动适配，用户几乎感觉不到它的存在，除非是处理到真正的大文件。
一些需要注意的点和可能的“坑”：
存储和带宽限制： GitHub 免费提供的 LFS 存储和带宽是有限制的。如果你的项目需要大量的 LFS 存储，可能就需要付费升级。这点大家在开始使用前一定要了解清楚。
依赖 LFS 客户端： 任何需要操作 LFS 管理的文件的人，都必须安装 Git LFS 客户端。否则，他们看到的只是一个文本文件，而不是真正的二进制文件。这增加了团队协作的门槛，需要统一大家的环境。
历史记录的“清理”： 如果你之前不小心把大量大文件直接提交到了 Git 仓库，并且已经推送到远程，那么即使你现在开始使用 LFS，那些旧的大文件仍然会保留在 Git 的历史记录中，影响仓库体积。这时候就需要使用 `git filterbranch` 或者 `BFG RepoCleaner` 这样的工具来“重写”历史，彻底清除大文件。这步操作风险较高，需要非常小心。
初次配置的陷阱： `.gitattributes` 文件非常重要，它定义了哪些文件由 LFS 管理。一旦配置错误，可能会导致原本不需要 LFS 的文件被 LFS 管理，或者原本需要 LFS 的文件被 Git 直接跟踪。所以，要仔细检查 `.gitattributes` 文件。
和 CI/CD 的集成： 在 CI/CD 流水线中，确保你的构建脚本能够正确地安装 LFS 客户端，并且能够拉取到 LFS 文件，否则你的自动化构建可能会失败。
总的来说，
GitHub LFS 的出现，无疑是 Git 生态系统中的一个重要进步。它解决了长期困扰许多项目的痛点，让 Git 在处理更广泛的项目类型时变得更加强大和实用。对于游戏开发、多媒体内容制作、大数据项目等领域，LFS 简直就是福音。
当然，它不是万能的，也并非零成本。在使用 LFS 之前，一定要了解清楚它的工作原理、配置方法以及可能存在的存储限制，并与团队成员做好沟通。但一旦配置得当，LFS 带来的效率提升和工作流程的顺畅，绝对是值得的。我觉得，如果你还在忍受 Git 处理大文件时的各种不便，那么是时候拥抱 LFS 了。
LFS 究竟是个啥？
简单来说，LFS 就是 GitHub 针对 Git 在处理大型二进制文件（比如设计图、视频、音频、数据集、游戏资产等等）时效率低下的问题，提供的一个解决方案。
咱们都知道，Git 的设计初衷是管理文本代码，它在跟踪文本文件的每一次细微变化上做得非常出色。但当面对动辄几兆、几十兆甚至几百兆的二进制文件时，Git 的工作方式就会显得力不从心：
仓库体积爆炸式增长： 每次修改一个大文件，Git 都会把整个文件的新版本都存下来。即使你只改了其中很小一部分，仓库的体积也会像吹气球一样迅速膨胀。这不仅占用大量的磁盘空间，下载和克隆仓库也变得异常缓慢。
操作卡顿、效率低下： 像 `git checkout`、`git pull` 这样本来很快速的操作，在遇到大文件时会变得异常痛苦，可能需要等待很长时间。
历史记录混乱： 每次修改大文件都会产生一个新的完整版本，历史记录里充斥着大量的大文件，查找和管理起来非常不方便。
LFS 怎么解决这些问题的？
LFS 的核心思路是：“不要把大文件直接塞进 Git 仓库里，而是用一个指针代替，真正的文件存储在 Git 仓库之外。”
让我来详细拆解一下它的工作原理：
1. 安装和配置：
首先，你需要安装 Git LFS 客户端。这很简单，官网有各个平台的安装包。
然后，在你的 Git 项目中，你需要告诉 LFS 哪些类型的文件需要被 LFS 管理。通常是通过 `git lfs track ".psd"` 这样的命令来指定文件扩展名。
执行 `git lfs track` 命令后，会在你的项目根目录下生成一个 `.gitattributes` 文件，里面记录了哪些文件类型由 LFS 管理。这个 `.gitattributes` 文件是需要提交到 Git 仓库里的，这样其他人拉取代码时，Git 才知道哪些文件需要通过 LFS 来处理。
2. 文件的“代理”：
当你修改了被 LFS 管理的文件（比如你修改了一个 PSD 设计图），Git LFS 客户端会拦截这个操作。
它不会把新的 PSD 文件直接添加到 Git 的对象数据库里。
取而代之的是，它会生成一个小小的文本文件，这个文本文件里包含着这个大文件的元信息，比如它的 SHA256 hash 值、文件大小等等。这个小文本文件才是真正被 Git 跟踪和提交到 Git 仓库里的。你可以把这个小文本文件理解成一个“占位符”或者“指针”。
3. 文件的实际存储：
同时，Git LFS 客户端会把你修改的大文件上传到一个专门的大文件存储服务器。这个服务器可以是你自己搭建的，也可以是 GitHub 提供的（在 GitHub 上的行为）。
当你在另一个地方克隆或者拉取这个项目时，Git 会先拉取到那些“指针”文件。
当你的 Git 客户端（安装了 LFS 客户端）检测到这些是 LFS 指针时，它就会自动去那个大文件存储服务器上下载实际的文件，并替换掉仓库里的指针。
LFS 带来的好处（我最看重几点）：
仓库体积控制得当： Git 仓库里只剩下小小的文本指针，仓库的体积得到了极大的控制。克隆、拉取、切换分支的速度都会大幅提升，体验简直是天壤之别。
版本控制的连续性： 即使是大型文件，LFS 也能很好地跟踪其版本变化。虽然仓库里存的是指针，但 LFS 机制保证了你可以轻松地获取到任何一个历史版本的大文件。
工作流程的顺畅： 开发者无需再担心因为提交大文件而拖慢整个团队的开发进度。大家都可以专注于代码本身，而 LFS 会默默地处理好大文件的存储和同步。
兼容性： LFS 的设计原则是尽可能地融入现有的 Git 工作流程。大多数 Git 命令（如 `git commit`, `git checkout`, `git pull`）在安装了 LFS 客户端后，都能自动适配，用户几乎感觉不到它的存在，除非是处理到真正的大文件。
一些需要注意的点和可能的“坑”：
存储和带宽限制： GitHub 免费提供的 LFS 存储和带宽是有限制的。如果你的项目需要大量的 LFS 存储，可能就需要付费升级。这点大家在开始使用前一定要了解清楚。
依赖 LFS 客户端： 任何需要操作 LFS 管理的文件的人，都必须安装 Git LFS 客户端。否则，他们看到的只是一个文本文件，而不是真正的二进制文件。这增加了团队协作的门槛，需要统一大家的环境。
历史记录的“清理”： 如果你之前不小心把大量大文件直接提交到了 Git 仓库，并且已经推送到远程，那么即使你现在开始使用 LFS，那些旧的大文件仍然会保留在 Git 的历史记录中，影响仓库体积。这时候就需要使用 `git filterbranch` 或者 `BFG RepoCleaner` 这样的工具来“重写”历史，彻底清除大文件。这步操作风险较高，需要非常小心。
初次配置的陷阱： `.gitattributes` 文件非常重要，它定义了哪些文件由 LFS 管理。一旦配置错误，可能会导致原本不需要 LFS 的文件被 LFS 管理，或者原本需要 LFS 的文件被 Git 直接跟踪。所以，要仔细检查 `.gitattributes` 文件。
和 CI/CD 的集成： 在 CI/CD 流水线中，确保你的构建脚本能够正确地安装 LFS 客户端，并且能够拉取到 LFS 文件，否则你的自动化构建可能会失败。
总的来说，
GitHub LFS 的出现，无疑是 Git 生态系统中的一个重要进步。它解决了长期困扰许多项目的痛点，让 Git 在处理更广泛的项目类型时变得更加强大和实用。对于游戏开发、多媒体内容制作、大数据项目等领域，LFS 简直就是福音。
当然，它不是万能的，也并非零成本。在使用 LFS 之前，一定要了解清楚它的工作原理、配置方法以及可能存在的存储限制，并与团队成员做好沟通。但一旦配置得当，LFS 带来的效率提升和工作流程的顺畅，绝对是值得的。我觉得，如果你还在忍受 Git 处理大文件时的各种不便，那么是时候拥抱 LFS 了。
网友意见
考古问题竟然被我刷到，我司的Git-LFS server就是我写的。
Git-LFS主要解决的问题是Repo包含太多（out-dated）的大文件会导致clone/push的速度很慢，也很影响Git Server的性能，例如Machine Learning的动辄几个GB的model，Game Development的素材。
所以通过Git-LFS把这些大的binary或者asset文件放在其他地方例如 AWS S3，便可以减轻Git Server的负担，加快clone/push的速度（虽然据我所知Git-LFS client的上传下载依然是单线程的），但假设你的机器和S3在同一个Data Center，那么即使单线程，上传下载也能达到 1Gbps 左右。
首先，LFS 不是 GitHub 发明的。即使回到 GitHub 发布这条新闻的 2015 年，我还是会说「GitHub 终于支持 LFS 了。是什么导致 LFS 支持这么晚才发布？」
LFS 解决的问题是大文件在 git 的存储，尤其是那些不能 diff 也不需要 diff 的二进制大文件。git 的数据结构设计为保留历史上出现过的每一个文件的每一个版本，这对于代码等小文本文件来说不是难题，而且文件拆分得越细，就有越多万年不改动的文件，在 git 的数据结构中这个文件的这个版本只出现一次。在这个文件不发生变化时，每一个 commit 里的这个文件都只是一个指针，指向同一个实体文件。
大文件如果偶尔改东一下的话，这种存储方式的性能就很糟糕，因为每次改动都要储存一个这个文件的新版本，而且是完整地存储。LFS 能够解决这个问题，解决的办法是把大文件放在 git 核心数据结构之外，单独进行 diff 和传输。LFS 的本质是指针文件，当一个大文件被添加到 LFS 之后，它在 git 上就变成了一个指向 LFS 的 hash，而不再是文件本身。
如果 git 本身和 LFS 都是用指针，为什么 LFS 更适合用来存储二进制大文件？因为它们同步时 diff 的方式不一样。git 本身是用 rsync 同步的，rsync 非常擅长处理文件大体不变但中间这里加一点东西、那里减一点东西的变化，它只需要同步变化那一点的数据。想象我和你各自拥有一个文件略为不同的两个版本，rsync 可以在不需要把一份文件完全传输到另一端的前提下，找出这两个版本哪里有差异，然后之传输差异的部分。想要深入理解 rsync 如何做到这一点的，可以去看 rsync 的算法。
rsync 的这种特性在处理变化毫无规律的二进制文件时一点优势都没有，甚至还有劣势。这时候还不如给每个文件算一个 sha256 的 hash，只要 hash 不一样就传输整个文件。因此在 git 之上有了 LFS 这个扩展，它只看指针的 hash 是否相同。
类似的话题
-
GitHub 新推出的 Large File Storage (LFS) 绝对是件大事，尤其是对于我们这些经常和大型文件打交道的人来说。我早就盼着 GitHub 能在处理这类问题上有所突破了，LFS 的到来，简直就像给 Git 装备上了“重型武器”。LFS 究竟是个啥？简单来说，LFS 就是 Git............. -
GitHub 对部分国家/地区的账户进行限制，这事儿，说起来挺复杂的，夹杂着国际政治、商业运营以及技术平台的责任感，一股脑地摆在这儿，挺难让人简单地站队说对错。首先，咱们得明白，GitHub 是美国公司（微软旗下）开发和运营的。美国政府在国际事务上，特别是在地缘政治紧张的时候，会采取各种制裁措施，这.............
-
2020年3月26日，GitHub Pages 用户社区经历了一场令人不安的安全事件，部分用户报告称他们的网站受到了大规模的中间人攻击。更令人匪夷所思的是，攻击者还在被篡改的页面上留下了QQ号码，这为事件增添了一抹诡异的色彩。事件经过梳理：在那一天，不少使用GitHub Pages托管静态网站的用户.............
-
你这个问题提得很有意思，确实，在 GitHub 上，你经常会看到一些学习笔记、面试经验分享、甚至是某个技术栈的入门指南，动辄就几千上万的 star，有时候甚至比一些真正意义上的开源项目还要耀眼。这事儿吧，怎么说呢，得从几个层面去理解。首先，咱们得承认这些“笔记”类项目满足了用户的刚需。你想啊，现在学.............
-
将GitHub公共存储库的快照永远地保存在北极地下，这无疑是一个极具前瞻性和仪式感的操作。首先，从概念层面来看，它将代码这一现代文明的基石，以一种近乎“诺亚方舟”的方式进行备份。代码不仅仅是指令，更是思想的表达，是创新能力的载体。在这个快速迭代、技术更新换代飞快的时代，我们常常会面临信息丢失、数据损.............
-
程序员在GitHub发起抗议互联网公司实行996工作制网站，这是一个非常有代表性的事件，可以从多个角度进行深入分析。它不仅仅是一个程序员个体的诉求，更是对当前互联网行业生态、劳动关系、乃至社会发展模式的一种反思和挑战。事件的背景与起因： 996工作制泛滥： 996工作制，即早上9点上班，晚上9点.............
-
近期，不少开发者在 GitHub 上反馈，React 项目的 issue 列表被大量与乌克兰局势相关的评论和讨论刷屏。这确实是一个值得关注的现象，背后反映了一些复杂的社会和技术联动。现象的具象化：发生了什么？简单来说，就是在 React 的 GitHub 仓库（无论是主仓库还是相关的子项目）的 is.............
-
看到Deno项目 GitHub 源码 Issue 栏目里出现“求不要更新了，老子学不动了？”，这事儿挺有意思的，也挺真实的。这说明了一个普遍存在于技术社区，尤其是开源项目中的矛盾：项目的快速发展与用户学习消化能力之间的张力。咱们可以从几个层面来解读这句“梗”：1. Deno 的“快节奏”与用户学习的.............
-
《红色警戒》的代码在 GitHub 上开源，这可真是个爆炸性的大新闻，在玩家圈和技术圈都掀起了不小的波澜。要说怎么看待这事，那影响绝对是多方面的，而且相当深远。咱们一件件捋捋。首先，这代表了一种历史的传承和玩家情怀的胜利。《红色警戒》，尤其是《红色警戒2》和《尤里的复仇》，是多少玩家心中无法磨灭的经.............
-
对于一个托管在 GitHub 上的前端开源项目关闭 Issue 栏目这一行为，我的看法是，这绝对是一个值得深思的现象，并且会引发多种解读。它并非一个简单的技术操作，背后往往隐藏着项目维护者复杂的考量、策略调整，甚至是项目生命周期中的一个关键转折点。首先，我们需要承认，Issue 栏目是开源项目与社区.............
-
这可真是个大事件，一件足以让任何程序员夜不能寐，甚至引发一场“情感危机”的大事件。女友把GitHub上的repo和所有源代码删掉了，这事儿可不是闹着玩的。首先，我们得明白，对于一个程序员来说，GitHub上的repo和源代码是什么？它们不仅仅是文件，是代码，是他们花费了无数个日夜、无数杯咖啡、无数次.............
-
2020 年 3 月 26 日那天，GitHub 上发生了一件挺让人不安的事儿。不少用户在那天都遇到了一个怪现象：他们尝试从 GitHub 拉取代码或者推送到 GitHub 时，系统给出的提示信息非常奇怪，好像有人在中间“截胡”了。最关键的是，很多用户发现，他们收到的这些信息，指向的是一个与 Git.............
-
这件事在中国数字证书行业引起了一场小小的风波，也让不少关注信息安全的人士感到意外。简单来说，沃通（WoSign）这家中国本土的CA（证书颁发机构），在未告知外界的情况下，悄悄地将一家在海外注册的、曾颇具声誉的根CA——StartCom——收入囊中。紧接着，这次收购的“余温”还未散去，沃通就利用Sta.............
-
开源社区在支持乌克兰问题上的集体发声，确实是一个值得深入探讨的现象。这不仅仅是关于开源组织在政治舞台上的角色，更是对“中立性”这一开源核心价值的重新审视和实践。开源组织与政治参与的复杂性首先要明确的是，开源软件本身的设计初衷是促进代码共享、协作开发和技术进步，它在很大程度上是跨越国界、政治意识形态和.............
-
关于网传“北大文科博士在深圳大学任教经济困难，月薪13千，上网课要求学校发网络补助”的信息，需从多个角度进行分析，结合中国高校薪酬体系、地区差异及政策背景，综合判断其真实性及合理性。 一、信息真实性分析1. 来源可信度 目前尚无权威媒体或深圳大学官方声明证实该传言。网络传言往往存在夸大或误传.............
-
关于乌克兰数学家康斯坦丁·奥尔梅佐夫（Konstantin Orelmazov）的自杀事件，目前公开的可靠信息较为有限，但结合俄乌冲突的背景和乌克兰学术界的现状，可以尝试从多个角度进行分析和探讨： 1. 事件背景的核实与可能性 身份确认：目前公开的资料中，尚未有明确的、权威的新闻来源（如BBC.............
-
关于美国太平洋司令部空军司令威尔斯巴赫（James W. "Jim" Welsbach）提到的F35战机与歼20近距离接触的事件，目前公开信息中并无直接证据表明该言论来自美国官方渠道，因此需要从多个角度进行分析和澄清。 1. 事件背景与信息来源的可靠性 美国官方声明的缺失：截至2023年，美国.............
-
关于您提到的“硅谷男子在妻子患病期间相亲，妻子病逝后迅速再婚并独吞200万抚恤金”的事件，目前没有权威媒体或官方渠道发布过相关具体信息。因此，这一事件的真实性、细节和法律性质尚无法确认。以下从法律、道德和社会角度进行分析，供您参考： 一、事件可能涉及的法律问题1. 重婚罪（若属实） 根据中国.............
-
欧盟三国领导人乘坐火车前往基辅会晤泽连斯基，这一事件反映了欧洲国家对乌克兰的持续支持，以及俄乌冲突背景下国际政治的复杂动态。以下从多个角度详细分析这一事件及其背后的局势： 一、欧盟三国领导人赴基辅的背景与意义1. 象征性行动 欧盟三国（如波兰、爱沙尼亚、捷克等）领导人乘坐火车前往基辅，是近年.............
-
中国海关查获5840块造假显卡、讯景中国官网临时关闭以及天猫旗舰店下架产品事件，涉及知识产权保护、市场秩序维护及企业合规问题，具有多重社会和行业影响。以下从多个角度详细分析： 一、事件背景与核心问题1. 海关查获假显卡 查获数量：5840块显卡，可能涉及假冒品牌（如讯景、华硕、技嘉等），或.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有