如果非得了解下 GIT 系统… – 实践篇
git gc ( garbage collect )命令将会收集所有松散对象并将它们存入 pack,合并这些 pack 进一个大的 pack,然后将不被任何 commit 引用并且已存在一段时间 (数月) 的对象删除,除此之外还会将所有引用 (references) 并入一个单独文件(上面有提到随着各种操作,.git下还会产生更多文件夹,.git中的packed-refs文件夹就是这时候产生的)。该命令可能通过修改配置中的 gc.auto 和 gc.autopacklimit 来调整操作阈值。注意:git gc 调用的也是 git prune ,如有需求也可关注这个命令。 至于”info文件夹是干嘛的?”这个问题还未知… 官网的描述也没看懂,也没查到或者在项目中实际出现这个文件夹有存在什么文件,要么等遇到再说? 至此git对象中的三个对象已经知道是咋回事了,还剩个tags对象,简单介绍下。 tags对象通常也是一个commit对象,指的是一个指定了开发者可读名称的一个特殊对象,如有需要也可通过 git cat-file 来解析探索。 其间关系大致如下:
关系图的话,这个是git官网的… 和上面的结构是一样的。 基于objects的介绍再回过头来看看”内容、寻址、文件、系统”便比较清晰了:以git对象作为内容,通过唯一的校验和寻址,文件形式存储的一个版本控制系统。 了解完这些,主要还是希望能够运用到实际生产中来解决问题。如 “项目中.git文件为什么这么大?怎么处理?” 可能的处理方案: 1. 执行 git gc ,如果压缩后能达到预期效果,则不做过多处理 2.针对历史记录中对某些大文件的引用,则删除对应引用的对象,操作如下
3.若还是难处理,或者不好处理,或者不想删除大文件的引用,则备份一份.git,然后初始化git仓库,操作如下
参考 关于git hooks,参考Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks 关于更详细的.git文件夹,参考 Gitrepository-layout-objectsinfo https://git-scm.com/docs/gitrepository-layout#gitrepository-layout-objectsinfo (编辑:源码网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |