- #99
- #98
- #97
- #96
- #95
- #94
- #93
- #92
- #91
- #90
- #89
- #88
- #87
- #86
- #85
- #84
- #83
- #82
- #81
- #80
- #79
- #78
- #77
- #76
- #75
- #74
- #73
- #72
- #71
- #70
- #69
- #68
- #67
- #66
- #65
- #64
- #63
- #62
- #61
- #60
- #59
- #58
- #57
- #56
- #55
- #54
- #53
- #52
- #51
- #50
- #49
- #48
- #47
- #46
- #45
- #44
- #43
- #42
- #41
- #40
- #39
- #38
- #37
- #36
- #35
- #34
- #33
- #32
Git 如何管理大型档案?
Git 允许我们记录任何文件的变更,并且可以轻松地回溯任何一个版本,但是当需要存储大型文件时 Git 就会显得力不从心,因为 Git 并不是为了存储大型文件(图片、视频、音乐……等二进制文件)而设计的。
试想一张 1MB 的图片只要改动了 10 次,Git 就会存储 10 个版本的图片也就是 10 MB 到存储库当中!(虽然这样简略的说明不完全正确,实际 Git 会存储两个版本之间的差异,而不是存储每个版本的完整副本,但二进制文件间差异难压缩的问题仍是挑战)容易导致性能底下、浪费存储空间、耗费网络资源……等问题。
而 Git LFS 解决问题的方式是将大型文件内容存储在额外的服务器上,而不是直接存储在 Git 存储库中,通过将实际大型文件替换成指向大型文件的指针,就算文件再大、变动再多次,Git 存储库的大小都不会增加。
如果对于 Git LFS 详细如何使用、我实际使用它的体验、有些什么事项需要特别留意可以参考看看新文章:我如何使用 Git LFS 来托付大型 Git 文件?
- #31
- #30
- #29
- #28
- #27
- #26
- #25
- #24
- #23
- #22
- #21
- #20
- #19
- #18
- #17
- #16
- #15
- #14
- #13
- #12
- #11
- #10
- #9
- #8
- #7
- #6
- #5
- #4
- #3
- #2
- #1