git lfs 上传大文件
Versioning large files can be problematic with distributed version control systems like Git. Git Large File Storage (or LFS) is a new, open-source extension to Git that aims to improve handling of large files.
使用分布式版本控制系统(如Git)对大型文件进行版本控制可能会遇到问题。 Git大文件存储 (或LFS)是Git的一个新的开源扩展,旨在改善大文件的处理 。
It does this by replacing large files in your repository—such as graphics and videos—with simple text pointers. These pointers reference the large files, which are hosted elsewhere, either by GitHub or another external source such as an AWS bucket.
通过使用简单的文本指针替换存储库中的大文件(例如图形和视频)来实现此目的。 这些指针引用了大型文件,这些文件由GitHub或其他外部源(例如AWS存储桶)托管在其他位置。
Initially this is confusing, but hopefully LFS will make more sense by the end of this tutorial.
最初,这令人困惑,但是希望LFS在本教程结束时会更有意义。
LFS will be available to all GitHub users soon, but as I'm handling a lot of large files through GitHub with my Chip Shop board game, I signed up to the early access program to find out more.
LFS将很快对所有GitHub用户开放,但是由于我正在通过Chip Shop棋盘游戏通过GitHub处理大量大文件,因此我注册了抢先体验计划以了解更多信息。
Note: Unless you have Git LFS enabled on your account, this tutorial won't work for you yet, but you can get an idea of the future feature.
注意 :除非您在帐户上启用了Git LFS,否则本教程尚不适合您,但是您可以对将来的功能有所了解。
If you have a Linux- or Windows-based system, visit git-lfs.github.com, download the installer, unarchive it and run the installer script.
如果您具有基于Linux或Windows的系统,请访问git-lfs.github.com ,下载安装程序,将其取消存档并运行安装程序脚本。
If you have a Mac, do the same, but Git LFS is also available via Homebrew: install with brew install git-lfs.
如果您使用的是Mac,请执行相同的操作,但是也可以通过Homebrew使用Git LFS:使用brew install git-lfs 。
Note: Git LFS will currently only work when using Git on the command line. I normally use Tower for managing my Git workflow, and this broke any LFS-related actions.
注意 :Git LFS当前仅在命令行上使用Git时有效。 我通常使用Tower来管理我的Git工作流程,这破坏了所有与LFS相关的操作。
Create a Git repository as you normally do, and initialize the files you wish to track with LFS by issuing commands such as:
像通常一样创建一个Git存储库,并通过发出以下命令初始化要使用LFS跟踪的文件:
git lfs track "*.psd" git lfs track "*.mp3"Then use git as normal:
然后像往常一样使用git:
git add *.psd git commit -m "Added PhotoShop files" git push origin masterSo far, not a lot is different, but if we look into the details of a file on GitHub, we can see a subtle difference. Here’s a file hosted on GitHub:
到目前为止,并没有什么不同,但是如果我们查看GitHub上文件的详细信息,我们可以看到细微的差别。 这是托管在GitHub上的文件:
And here’s a file hosted externally via LFS:
这是一个通过LFS在外部托管的文件:
In the first image (a traditional GitHub repository), the file is located in the repository. In the second image (an LFS-enabled repository) the file is located in an AWS bucket.
在第一个映像(传统的GitHub存储库)中,文件位于存储库中。 在第二个图像(启用LFS的存储库)中,文件位于AWS存储桶中。
Now go ahead and create some branches, make file changes, commit them and push:
现在继续创建一些分支,进行文件更改,提交并推送:
Hang on, that .git folder is still large: wasn't LFS supposed to handle files better?
继续,那个.git文件夹仍然很大:LFS是否应该更好地处理文件?
This is where LFS gets somewhat confusing and possibly not as useful as you may have hoped.
这就是LFS令人困惑的地方,可能没有您希望的有用。
To see what's happening more clearly, delete the repo folder you created and then re-clone it from GitHub. You should see something like the below, with an appropriately sized .git folder:
为了更清楚地了解正在发生的事情,请删除您创建的repo文件夹,然后从GitHub重新克隆它。 您应该看到类似下面的内容,并带有适当大小的.git文件夹:
Those files are ridiculously small! Try opening one, and you'll likely see this message:
这些文件太小了! 尝试打开一个,您可能会看到以下消息:
This is one of the aforementioned file references, and if you feel like cracking it open in a text editor you'll see something like this:
这是前面提到的文件引用之一,如果您想在文本编辑器中将其打开,则会看到以下内容:
version https://git-lfs.github.com/spec/v1 oid sha256:128b446a2cd06dd3b4dc2e2fe3336426792425870c3ada44ae7684b8391dc04d size 1036867This is great if you're a developer on a team, as you probably don't need lots of media files cluttering your computer. And when it comes to deployment or testing, you likely have a build process that will assemble a project with real media. But what if you're a designer and need to make changes? How do you access the real file?
如果您是团队中的开发人员,那就太好了,因为您可能不需要很多混乱的计算机媒体文件。 当涉及到部署或测试时,您可能会有一个构建过程,该过程会将项目与真实媒体组装在一起。 但是,如果您是设计师并且需要进行更改,该怎么办? 您如何访问真实文件?
Let's see what commands are available to LFS by typing git lfs:
让我们通过键入git lfs来查看哪些命令可用于LFS:
There are several that may be worth investigating in the future, but of most interest to us right now is fetch. By default, this will retrieve local copies of all files in the current checked out branch. This can be made specific by supplementing it with branches or commits:
将来可能有几个值得研究,但是现在我们最感兴趣的是fetch 。 默认情况下,这将检索当前检出分支中所有文件的本地副本。 可以通过添加分支或提交来使其具体化:
# Fetches All git lfs fetch # Fetches a particular branch git checkout -b new_image git lfs fetch new_image git lfs fetch 5a5c0ef0de779c9d4585320eab8d4a1bec696005And the files are available locally:
这些文件在本地可用:
I would love a specific command to then remove the local file and replace it with a reference. Maybe there is another way of accomplishing this, or it will come in a future version.
我希望有一个特定的命令来删除本地文件,然后将其替换为参考。 也许有另一种方法可以完成此任务,或者它将在将来的版本中提供。
Git LFS is a promising start, and I can see glimpses of genuine usefulness in the future. It needs better documentation and proper integration with 3rd party tools (the GitHub website included), which I'm sure are coming. If you have a decent Git, continuous integration and deployment system in place, then LFS will make far more sense. If you're a small team, then it may be more of a bottleneck.
Git LFS是一个有前途的开始,我可以看到将来真正有用的一瞥。 它需要更好的文档,并且需要与第三方工具(包括GitHub网站)进行适当的集成,我敢肯定它会来的。 如果您有一个不错的Git,持续集成和部署系统,那么LFS会更有意义。 如果您是一个小团队,那么它可能是一个瓶颈。
What are your thoughts? Useful or unnecessary?
你觉得呢?你有没有什么想法? 有用还是不必要?
翻译自: https://www.sitepoint.com/guide-versioning-large-files-with-git-lfs/
git lfs 上传大文件