详解 Git 大文件存储（Git LFS） - 网站源码_资源分享

责任编辑主要就传授在 Git 库房中怎样管理工作大的十进制文档，详尽如是说了甚么是 Git LFS，Git LFS 是怎样组织工作的，和怎样采用 Git LFS。

责任编辑译者自 Atlassian 非官方如是说 Git LFS 的该文，Atlassian 是 Git LFS 的主要就合作开发人员众所周知，这篇如是说 Git LFS 的该文较为权威性，讲的也很详尽。书名门牌号：

https://www.atlassian.com/git/tutorials/git-lfs

责任编辑与此同时也加了我对个人的许多注解，注解文本会明晰用涂黑手写体标记出。

甚么是 Git LFS？

Git 是分布式系统版控制技术，这意味著在布季夫操作过程中常将库房的整座历史纪录数据传输到应用程序。对涵括大文档（特别是时常被修正的大文档）的工程项目，如上所述布季夫须要大批天数，即使应用程序会浏览每一文档的每一版。Git LFS（Large File Storage）是由 Atlassian, GitHub 和其它开放源码COBOL合作开发的 Git 扩充，它透过延后地（lazily）浏览大文档的有关版来增加大文档在库房中的负面影响，简而言之，大文档是在 checkout 的操作过程中浏览的，而并非 clone 或 fetch 操作过程中浏览的（这意味著你在前台间歇 fetch 控制台库房文本到邻近地区时，并不能浏览大文档文本，而要在你 checkout 到组织工作区的这时候才会或者说去浏览大文档的文本）。

Git LFS 透过将库房中的大文档代替为细微的操作符（pointer）文档来努力做到这一点儿。在恒定采用前夕，你将总有一天不能看见那些操作符文档，即使它是由 Git LFS 手动处置的：

\1. 当你加进（执行 git add 命令）两个文档到你的库房时，Git LFS 用两个操作符代替其文本，并将文档文本储存在邻近地区 Git LFS 内存中（邻近地区 Git LFS 内存坐落于库房的.git/lfs/objects 产品目录中）。

\2. 当你推送新的提交到服务器时，新推送的提交引用的所有 Git LFS 文档都会从邻近地区 Git LFS 内存数据传输到绑定到 Git 库房的远程 Git LFS 储存（即 LFS 文档文本会直接从邻近地区 Git LFS 内存数据传输到远程 Git LFS 储存服务器）。

\3. 当你 checkout 两个包含 Git LFS 操作符的提交时，操作符文档将代替为邻近地区 Git LFS 内存中的文档，或者从控制台 Git LFS 储存区浏览。

关于 LFS 的操作符文档：

LFS 的操作符文档是两个文责任编辑档，储存在 Git 库房中，对应大文档的文本储存在 LFS 服务器里，而并非 Git 库房中，下面为两个图片 LFS 文档的操作符文档文本：

version https://git-lfs.github.com/spec/v1 oid sha256:5b62e134d2478ae0bbded57f6be8f048d8d916cb876f0656a8a6d1363716d999 size 285

操作符文档很小，小于 1KB。其格式为 key-value 格式，第一行为操作符文档规范 URL，第二行为文档的对象 id，也即 LFS 文档的储存对象文档名，可以在.git/lfs/objects 产品目录中找到该文档的储存对象，第三行为文档的实际大小（单位为字节）。所有 LFS 操作符文档都是这种格式。

Git LFS 是无缝的：在你的组织工作副本中，你只会看见实际的文档文本。这意味著你不须要更改现有的 Git 组织工作流程就可以采用 Git LFS。你只需按常规进行 git checkout、编辑文档、git add 和 git commit。git clone 和 git pull 将明显更快，即使你只浏览实际检出的提交所引用的大文档版，而并非曾经存在过的文档的每两个版。

为了采用 Git LFS，你将须要两个支持 Git LFS 的托管服务器，例如Bitbucket Cloud或Bitbucket Server（G itHub、GitLab也都支持 Git LFS）。库房用户将须要安装 Git LFS 命令行应用程序（参考这里其实更好），或支持 Git LFS 的 GUI 应用程序，例如Sourcetree。

安装 Git LFS

\1. 有三种简单的方式来安装 Git LFS：

a. 用你最喜欢的软件包管理工作器来安装它。git-lfs 软件包在 Homebrew，MacPorts，dnf 和packagecloud中都是可用的；或者

b. 从工程项目网站浏览并安装Git LFS；

c. 安装 Sourcetree，它是捆绑了 Git LFS 的两个免费的 Git GUI 应用程序。

\2. 一旦安装好了 Git LFS，请运行 git lfs install 来如上所述化 Git LFS（如果你安装了 Sourcetree，可以跳过此步骤）：

$ git lfs install Git LFS initialized.

你只须要运行 git lfs install 一次。为你的系统如上所述化后，当你布季夫包含 Git LFS 文本的库房时，Git LFS 将手动进行自我引导启用。

创建两个新的 Git LFS 库房

要创建两个新的支持 Git LFS 的库房，你须要在创建库房后运行 git lfs install：

# initialize Git $ mkdir Atlasteroids $ cd Atlasteroids $ git init Initialized empty Git repository in /Users/tpettersen/Atlasteroids/.git/ # initialize Git LFS $ git lfs install Updated pre-push hook. Git LFS initialized.

这将在你的库房中安装两个特殊的 pre-pushGit 钩子，该钩子将在你执行 git push 的这时候数据传输 Git LFS 文档到服务器上。

所有Bitbucket Cloud库房已手动启用 Git LFS 。对Bitbucket Server，你须要在库房设置中启用 Git LFS：

当你的库房如上所述化了 Git LFS 后，你可以透过采用 git lfs track 来指定要跟踪的文档。

布季夫现有的 Git LFS 库房

安装 Git LFS 后，你可以像往常一样采用 git clone 命令来布季夫 Git LFS 库房。在布季夫操作过程的结尾，Git 将检出默认分支（通常是 master），并且将手动为你下载完成检出操作过程所需的所有 Git LFS 文档。例如：

$ git clone [email protected]:tpettersen/Atlasteroids.gitCloning into Atlasteroids… remote: Counting objects: 156, done. remote: Compressing objects: 100% (154/154), done. remote: Total 156 (delta 87), reused 0 (delta 0) Receiving objects: 100% (156/156), 54.04 KiB | 31.00 KiB/s, done. Resolving deltas: 100% (87/87), done. Checking connectivity… done. Downloading Assets/Sprites/projectiles-spritesheet.png (21.14 KB) Downloading Assets/Sprites/productlogos_cmyk-spritesheet.png (301.96 KB) Downloading Assets/Sprites/shuttle2.png (1.62 KB) Downloading Assets/Sprites/space1.png (1.11 MB) Checking out files: 100% (81/81), done

库房里有 4 个 PNG 文档被 Git LFS 跟踪。执行 git clone 命令时，在从库房中检出操作符文档的这时候，Git LFS 文档被两个两个浏览下来。

加快布季夫速度

如果你正在布季夫包含大批 LFS 文档的库房，显式采用 git lfs clone 命令可提供更好的性能：

$ git lfs clone [email protected]:tpettersen/Atlasteroids.git Cloning into Atlasteroids… remote: Counting objects: 156, done. remote: Compressing objects: 100% (154/154), done. remote: Total 156 (delta 87), reused 0 (delta 0) Receiving objects: 100% (156/156), 54.04 KiB | 0 bytes/s, done. Resolving deltas: 100% (87/87), done. Checking connectivity… done. Git LFS: (4 of 4 files) 1.14 MB / 1.15 MB

git lfs clone 命令不能一次浏览两个 Git LFS 文档，而要等到检出（checkout）完成后再批量浏览所有必需的 Git LFS 文档。这利用了并行浏览的优势，并显著增加了产生的 HTTP 请求和进程的数量（这对提高 Windows 的性能尤为重要）。

拉取并检出

就像布季夫一样，你可以采用常规的 git pull 命令拉取 Git LFS 库房。拉取完成后，所有须要的 Git LFS 文档都会作为手动检出操作过程的一部分而被浏览。

$ git pull Updating 4784e9d..7039f0a Downloading Assets/Sprites/powerup.png (21.14 KB) Fast-forward Assets/Sprites/powerup.png | 3 + Assets/Sprites/powerup.png.meta | 4133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 4136 insertions(+) create mode 100644 Assets/Sprites/projectiles-spritesheet.png create mode 100644 Assets/Sprites/projectiles-spritesheet.png.meta

pull 命令来浏览当前提交的所有丢失的 Git LFS 文本：

$ git lfs pull Git LFS: (4 of 4 files) 1.14 MB / 1.15 MB

加快拉取速度

像 git lfs clone 命令一样，git lfs pull 命令批量浏览 Git LFS 文档。如果你知道自上次拉取以来已经更改了大批文档，则不妨显式采用 git lfs pull 命令来批量浏览 Git LFS 文本，而禁用在检出前夕手动浏览 Git LFS。这可以透过在调用 git pull 命令时采用-c 选项覆盖 Git 配置来完成：

$ git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull

由于输入的文本很多，你可能希望创建两个简单的Git 别名来为你执行批处置的 Git 和 Git LFS 拉取：

$ git config –global alias.plfs “\!git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull” $ git plfs

当须要浏览大批的 Git LFS 文档时，这将大大提高性能（同样，特别是在 Windows 上）。

采用 Git LFS 跟踪文档

当向库房中加进新的大文档类型时，你须要透过采用 git lfs track 命令指定两个模式来告诉 Git LFS 对其进行跟踪：

$ git lfs track “*.ogg” Tracking *.ogg

请注意，”*.ogg”周围的引号很重要。省略它将导致通配符被 shell 扩充，并将为当前产品目录中的每一.ogg 文档创建单独的条目：

# probably not what you want $ git lfs track *.ogg Tracking explode.ogg Tracking music.ogg Tracking phaser.ogg

Git LFS 支持的模式与.gitignore 支持的模式相同，例如：

# track all .ogg files in any directory $ git lfs track “*.ogg” # track files named music.ogg in any directory $ git lfs track “music.ogg” # track all files in the Assets directory and all subdirectories $ git lfs track “Assets/” # track all files in the Assets directory but *not* subdirectories $ git lfs track “Assets/*” # track all ogg files in Assets/Audio $ git lfs track “Assets/Audio/*.ogg” # track all ogg files in any directory named Music $ git lfs track “**/Music/*.ogg” # track png files containing “xxhdpi” in their name, in any directory $ git lfs track “*xxhdpi*.png

那些模式是相对你运行 git lfs track 命令的产品目录的。为了简单起见，最好是在库房根产品目录运行 git lfs track。须要注意的是，Git LFS 不支持像.gitignore 那样的负模式（negative patterns）。

运行 git lfs track 后，你会在你的运行命令的仓库中发现名为.gitattributes 的新文档。.gitattributes 是一种 Git 机制，用于将特殊行为绑定到某些文档模式。Git LFS 手动创建或更新.gitattributes 文件，以将跟踪的文档模式绑定到 Git LFS 过滤器。但是，你须要将对.gitattributes 文档的任何更改自己提交到库房：

$ git lfs track “*.ogg” Tracking *.ogg $ git add .gitattributes $ git diff –cached diff –git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..b6dd0bb — /dev/null +++ b/.gitattributes @@ -0,0 +1 @@ +*.ogg filter=lfs diff=lfs merge=lfs -text $ git commit -m “Track ogg files with Git LFS”

为了便于维护，透过始终从库房的根产品目录运行 git lfs track，将所有 Git LFS 模式保持在单个.gitattributes 文档中是最简单的。然而，你可以透过调用不带参数的 git lfs track 命令来显示 Git LFS 当前正在跟踪的所有模式的列表（和它在其中定义的.gitattributes 文档）：

$ git lfs track Listing tracked paths *.stl (.gitattributes) *.png (Assets/Sprites/.gitattributes) *.ogg (Assets/Audio/.gitattributes)

你可以通过从.gitattributes 文档中删除相应的行，或者透过运行 git lfs untrack 命令来停止采用 Git LFS 跟踪特定模式：

$ git lfs untrack “*.ogg” Untracking *.ogg $ git diff diff –git a/.gitattributes b/.gitattributes index b6dd0bb..e69de29 100644 — a/.gitattributes +++ b/.gitattributes @@ -1 +0,0 @@ -*.ogg filter=lfs diff=lfs merge=lfs -text

运行 git lfs untrack 命令后，你自己必须再次提交.gitattributes 文档的更改。

提交和推送

你可以按常规方式提交并推送到包含 Git LFS 文本的库房。如果你已经提交了被 Git LFS 跟踪的文档的变更，则当 Git LFS 文本数据传输到服务器时，你会从 git push 中看见许多其它输出：

$ git push Git LFS: (3 of 3 files) 4.68 MB / 4.68 MB Counting objects: 8, done. Delta compression using up to 8 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 1.16 KiB | 0 bytes/s, done. Total 8 (delta 1), reused 0 (delta 0) To [email protected]:tpettersen/atlasteroids.git 7039f0a..b3684d3 master -> master

如果由于某些原因数据传输 LFS 文档失败，推送将被终止，你可以放心地重试。与 Git 一样，Git LFS 储存也是文本寻址的（而并非按文档名寻址）：文本是根据密钥储存的，该密钥是文本本身的 SHA-256 哈希。这意味著重新尝试将 Git LFS 文档数据传输到服务器总是安全的；你不可能用错误的版意外覆盖 Git LFS 文档的文本。

在主机之间移动 Git LFS 库房

要将 Git LFS 库房从两个托管提供者迁移到另两个托管提供者序，你可以结合采用指定了-all 选项的 git lfs fetch 和 git lfs push 命令。

例如，要将所有 Git 和 Git LFS 库房从名为github的控制台移动到名为bitbucket 的控制台：

# create a bare clone of the GitHub repository $ git clone –bare [email protected]:kannonboy/atlasteroids.git $ cd atlasteroids # set up named remotes for Bitbucket and GitHub $ git remote add bitbucket [email protected]:tpettersen/atlasteroids.git $ git remote add github [email protected]:kannonboy/atlasteroids.git # fetch all Git LFS content from GitHub $ git lfs fetch –all github # push all Git and Git LFS content to Bitbucket $ git push –mirror bitbucket $ git lfs push –all bitbucket

Git LFS 通常仅浏览你实际在邻近地区检出的提交所需的文档。但是，你可以采用 git lfs fetch –recent 命令强制 Git LFS 为其它最近修正的分支浏览额外的文本：

$ git lfs fetch –recent Fetching master Git LFS: (0 of 0 files, 14 skipped) 0 B / 0 B, 2.83 MB skipped Fetching recent branches within 7 days Fetching origin/power-ups Git LFS: (8 of 8 files, 4 skipped) 408.42 KB / 408.42 KB, 2.81 MB skipped Fetching origin/more-music Git LFS: (1 of 1 files, 14 skipped) 1.68 MB / 1.68 MB, 2.83 MB skipped

这对在外出午餐时批量浏览新的 Git LFS 文本很有用，或者如果你打算与队友一起审查组织工作，并且由于网络连接受限而无法在以后浏览文本时，这将非常有用。例如，你可能希望在上飞机之前先运行 git lfs fetch –recent！

Git LFS 会考虑包含最近提交超过 7 天的提交的任何分支或标签。你可以透过设置 lfs.fetchrecentrefsdays 属性来配置被视为最近的天数：

# download Git LFS content for branches or tags updated in the last 10 days $ git config lfs.fetchrecentrefsdays 10

默认情况下，git lfs fetch –recent 将仅在最近分支或标记的最新提交浏览 Git LFS 文本。

但是，你可以透过配置 lfs.fetchrecentcommitsdays 属性，将 Git LFS 配置为在最近的分支和标签上浏览更早提交的文本：

# download the latest 3 days of Git LFS content for each recent branch or tag $ git config lfs.fetchrecentcommitsdays 3

请谨慎采用此设置：如果分支移动很快，则可能会导致浏览大批数据。但是，如果你须要查看分支上的插页式更改，跨分支的 cherry-pick 提交或重写历史纪录，它可能会很有用。

如在主机之间移动 Gi

$ git lfs fetch –all Scanning for all objects ever referenced… ✔ 23 objects found Fetching objects… Git LFS: (9 of 9 files, 14 skipped) 2.06 MB / 2.08 MB, 2.83 MB skipped

删除邻近地区 Git LFS 文档

你可以采用 git lfs prune 命令从邻近地区 Git LFS 内存中删除文档：

$ git lfs prune ✔ 4 local objects, 33 retained Pruning 4 files, (2.1 MB) ✔ Deleted 4 files

这将删除所有被认为是旧的邻近地区 Git LFS 文档。旧文档是以下未被引用的任何文档：

当前检出的提交尚未推送（到 origin，或任何 lfs.pruneremotetocheck 设置的）的提交最近一次提交

默认情况下，最近的提交是最近十天内创建的任何提交。透过加进以下文本计算得出：

中讨论的 lfs.fetchrecentrefsdays 属性的值（默认为 7）；至lfs.pruneoffsetdays 属性的值（默认为 3）

你可以配置 prune 偏移量以将 Git LFS 内容保留更长的天数：

# dont prune commits younger than four weeks (7 + 21) $ git config lfs.pruneoffsetdays 21

与 Git 的内置垃圾收集不同，Git LFS 文本不能手动修剪，因此，定期运行 git lfs prune 命令是保持邻近地区库房大小减小的好主意。

你可以采用 git lfs prune –dry-run 来测试修剪操作将产生甚么效果：

$ git lfs prune –dry-run ✔ 4 local objects, 33 retained 4 files would be pruned (2.1 MB)

和采用 git lfs prune –verbose –dry-run 命令精确查看哪些 Git LFS 对象将被修剪：

$ git lfs prune –dry-run –verbose ✔ 4 local objects, 33 retained 4 files would be pruned (2.1 MB) * 4a3a36141cdcbe2a17f7bcf1a161d3394cf435ac386d1bff70bd4dad6cd96c48 (2.0 MB) * 67ad640e562b99219111ed8941cb56a275ef8d43e67a3dac0027b4acd5de4a3e (6.3 KB) * 6f506528dbf04a97e84d90cc45840f4a8100389f570b67ac206ba802c5cb798f (1.7 MB) * a1d7f7cdd6dba7307b2bac2bcfa0973244688361a48d2cebe3f3bc30babcf1ab (615.7 KB)

–verbose 模式输出的长十六进制字符串是要修剪的 Git LFS 对象的 SHA-256 哈希（也称为对象 ID 或 OID）。你可以采用“查找路径”中描述的技术或引用 Git LFS 对象的提交来查找有关将被修剪的对象的更多信息。

作为附加的安全检查，你可以采用–verify-remote 选项在删除之前，检查远程 Git LFS 储存区是否具有你的 Git LFS 对象的副本：

$ git lfs prune –verify-remote ✔ 16 local objects, 2 retained, 12 verified with remote Pruning 14 files, (1.7 MB) ✔ Deleted 14 files

这将使修剪操作过程明显变慢，但是你可以从服务器上恢复所有修剪的对象，从而使你高枕无忧。你可以透过全局配置 lfs.pruneverifyremotealways 属性为系统永久启用–verify-remote 选项：

$ git config –global lfs.pruneverifyremotealways true

或者，你可以透过省略上述命令中的–global 选项，仅对当前库房启用控制台校验。

从服务器删除控制台 Git LFS 文档

Git LFS 命令行应用程序不支持删除服务器上的文档，因此怎样删除他们取决于你的托管服务提供商。

在 Bitbucket Cloud 中，你可以透过库房设置> Git LFS查看和删除 Git LFS 文档：

请注意，每一 Git LFS 文档均透过其 SHA-256 OID 进行索引；透过 UI 看不到引用每一文档的路径。这是即使在许多不同的提交中，可能对应有许多引用对象的不同路径，因此查找它将是两个非常缓慢的操作过程。

要确定给定的 Git LFS 文档实际包含甚么，你有三个选项可用：

在 Bitbucket Git LFS UI 的左栏中查看文档预览图像和文档类型采用 Bitbucket Git LFS UI 右栏中的链接浏览文档-搜索引用 Git LFS 对象的 SHA-256 OID 的提交，如下一节所述

查找引用 Git LFS 对象的路径或提交

如果你有两个 Git LFS SHA-256 OID，你可以采用 git log –all -p -S 命令确定哪些提交引用了它：

$ git log –all -p -S 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc commit 22a98faa153d08804a63a74a729d8846e6525cb0 Author: Tim Pettersen <[email protected]> Date: Wed Jul 27 11:03:27 2016 +1000 Projectiles and exploding asteroids diff –git a/Assets/Sprites/projectiles-spritesheet.png new file mode 100755 index 0000000..49d7baf — /dev/null +++ b/Assets/Sprites/projectiles-spritesheet.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc +size 21647

此 git log 咒语会透过加进或删除包含指定字符串（Git LFS SHA-256 OID）的行（-S）的任何分支（–all）上的提交生成补丁（-p）。

该补丁将向你显示 LFS 对象的提交和路径，和加进它的人和提交天数。你可以简单地检出提交，Git LFS 将在须要时浏览文档并将其放置在你的组织工作副本中。

如果你怀疑特定的 Git LFS 对象坐落于当前的 HEAD 或特定的分支中，则可以采用 git grep 查找引用它的文档路径：

# find a particular object by OID in HEAD $ git grep 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc HEAD HEAD:Assets/Sprites/projectiles-spritesheet.png:oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc # find a particular object by OID on the “power-ups” branch $ git grep e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4 power-ups power-ups:Assets/Sprites/shield2.png:oid sha256:e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4

你可以用任何包含 Git LFS 对象的 ref，commit 或 tree 代替 HEAD 或 power-ups。

包含/排除 Git LFS 文档

在某些情况下，你可能指向为特定提交浏览可用的 Git LFS 文本的子集。例如，在配置 CI 构建以运行单元测试时，你可能只须要源代码，因此可能要排除构建代码不须要的重量级文档。

你可以采用git lfs fetch -X（或–exclude）排除模式或子产品目录：

$ git lfs fetch -X “Assets/**”

或者，你可能只想包含特定的模式或子产品目录。例如，音频工程师可以采用git lfs fetch -I (或 –includ

$ git lfs fetch -I “*.ogg,*.wav”

$ git lfs fetch -I “Assets/**” -X “*.gif”

排除和包含支持与 git lfs track 和.gitignore 相同的模式。你可以透过设置 lfs.fetchinclude 和 lfs.fetchexclude 配置属性，使那些模式对特定库房来说永久生效：

$ git config lfs.fetchinclude “Assets/**” $ git config lfs.fetchexclude “*.gif”

透过附加–global 选项，也可以将那些设置应用于系统上的每一库房。

锁定 Git LFS 文档

不幸的是，没有解决十进制合并冲突的简便方法。采用 Git LFS 文档锁定，你可以按扩充名或文档名锁定文档，并防止十进制文档在合并前夕被覆盖。

为了利用 LFS 的文档锁定功能，你首先须要告诉 Git 哪些类型的文档是可锁定的。在下面的示例中，在 git lfs track 命令后附加了–lockable 标志，该命令既将 PSD 文档储存在 LFS 中，又将它标记为可锁定。

$ git lfs track “*.psd” –lockable

然后将以下文本加进到.gitattributes 文档中：

*.psd filter=lfs diff=lfs merge=lfs -text lockable

在准备对 LFS 文档进行更改时，你将采用 lock 命令以便将文档在 Git 服务器上注册为锁定的文档。

$ git lfs lock images/foo.psd Locked images/foo.psd

一旦不再须要文档锁定，你可以采用 Git LFS 的 unlock 命令将其移除。

$ git lfs unlock images/foo.psd

与 git push 类似，可以采用–force 标志覆盖 Git LFS 文档锁。除非你完全确定自己在做甚么，否则不要采用–force 标志。

$ git lfs unlock images/foo.psd –force

Git LFS 怎样组织工作

如果你想了解有关 clean 和 smudge filter，pre-push 钩子和 Git LFS 背后的其它有趣的计算机科学的更多信息，请查看来自 Atlassian 在 LinuxCon 2016 的 Git LFS 的演示文稿。

作者：terryshchen，腾讯 IEG 应用合作开发工程师

更多干货尽在腾讯技术，非官方QQ交流群已建立，交流讨论可加：957411539。