首页 > .git 文件太大时怎样处理

.git 文件太大时怎样处理

一个 repo 里有 .jar 之类文件, 从 Github 下载 tag 里的 .zip 文件大小有 8M,
然后我用 filter-branch --tree-filter 删除了相关目录, 但大小没减多少..
查看了一下, 整个 repo 特别是 .git/objects/ 文件太大, 总共 48M,
于是网上搜 git gc 命令的参数尝试性地弄了几个, 到了 37M, 主要是 .git/objects/pack/ 36M.
作为一个 JS 前端模块还是太大了. 其实太早的 commit 可以丢弃的.
我想删除重建 .git 用来打包是可以的,
但遇到这样的问题时大家会怎么处理来舍弃无用的历史和文件?

---------

更新:
关于去掉部分 commit, 换个说法,,
我去掉一部分文件和一部分文件相关的 commit, 但要求方便从官方版本 merge 更新
目的是保证我的 repo (不用于开发, 仅仅发布压缩代码) 小, 而更新能进行 merge.


.jar文件显然不属于你自己的前端代码,而属于第三方依赖,不应该放在代码库之中。建议在项目前期用脚本管理第三方依赖的版本,把这个.jar文件从代码库之中去掉。


clone的时候,可以指定深度,如下,为1即表示只克隆最近一次commit.

git clone git://xxoo --depth 1

git是可以改历史的
你试试先在本地把没用的历史合并 再强行push上去


如果是java建立的web项目,加上 ssh 什么的加上,也不算太大啦。
或者你可以考虑把公共的 jar 都剥离出去,不要直接放在项目中。


使用git lfs
https://git-lfs.github.com/


使用 git rebase 可以修改提交历史。

比如合并前两个提交:http://stackoverflow.com/questions/59...

善用rebase,除了删除某些提交之外,还可以修改提交日志;拆分一次包含多个功能的提交;合并几个相同功能的提交,保持代码库历史整洁。


.git 下是你的本地仓库,记录的是全部的 git commit 历史信息,
clone 的时候指定 depth 可以不下载过多的历史 commit 信息。

不过你的疑问似乎是发布的时候如何处理,
简单,发布的时候删掉 .git 目录即可。

【热门文章】
【热门文章】