2019年，office365个人和家庭版自带1T的onedrive同步盘的速度怎样？
浙江杭州电信：可以跑满带宽（可能是学校的网络比较好
浙江杭州移动：上传速度比百度云慢（这是真的，逃
给你的git仓库瘦身
很久没有写博客了，最近遇到了一个git问题，比较典型，记录下来与大家分享。 我们使用git版本控制的时候享受了很多便利，不管是代码合并，分支提供给我们的并发,但我们也往往忽略了每次提交之后在我们本地项目根目录下.git文件夹里面的存储变化。我遇到的git“臃肿”问题就是因为在提交的时候把较大文本加入版本控制，在其他人拉取更新反推远程分支的时候，每一次都会加剧.git下面的objects的文件夹大小，最终的结果就是再也无法顺利从远程pull，也无法顺利clone该项目。 关于.git的产生和相关文件，可见此文的详细讲解：http://www.jianshu.com/p/fa31ef8814d2 。 简单的说，每一次提交修改的改变都会以文件的形式存储在本地项目根目录下的.git中，会在.git/objects下面形成一个Blob（一段二进制数据）文件记录。这意味着，即使你只改动了某个文件的一行内容，Git 也会生成一个全新的对象来存储新的文件内容。所以git仓库随着时间变化会自增长，我们往往忽视了这种潜在的危险。 下面来就我遇到的问题来思考解决方案，其实由于.git过大，我们可以从两种方向去思考，第一种治标不治本的方法：压缩git仓库。第二种删除git提交记录中大文件，在gc压缩。第一种方法是比较直接快捷的，可以使用命令：git gc --prune=now。 当你再次du -hs的时候会发现仓库大小有一定的变小。其实git自身在可承受范围内会自动用gc帮你压缩打包，所以除非真的遇到pull,push都困难的时候，可以不用手动执行。这个方法明显的缺点在于压缩的效果有限，且大文件还一直在之后的每次提交中，为以后埋下隐患。 本人更推荐第二种方法，大文件对象再删除。 先查找大文件，命令如下： git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')" 例如删除nspatientList1.txt文件： git filter-branch --force --index-filter 'git rm -rf -...
评论
发表评论