好文收藏夹

很久没有写博客了，最近遇到了一个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 -...

Part 1 关于分布式版本控制 Git 是目前使用最广泛的分布式版本控制系统，在很多大型项目的背后都能见到 Git 的身影。 那么，什么是 分布式版本控制系统 ？Git 又有什么用呢？ 版本控制，顾名思义，就是对一个或一些文件的变化进行记录，并在以后查阅具体修订情况的系统。 最简单的版本控制就是存储同一个文件的不同版本，像这样： document-2019-2-15.md document-2019-2-16-1.md document-2019-2-16-2.md ... 这样做的弊端是很明显的，进行修改的时候容易错误修改之前的版本，而且在查询具体的某一次更改的时候也非常麻烦。 而成熟的版本控制系统，则拥有了更完善的版本控制功能：你可以方便地查阅对代码库的某一次修改，比对任意两个版本之间的差别，并在出现 bug 的时候，及时找到 bug 出现的原因，或是回退到之前的版本。在版本控制系统的帮助下，这些操作都将变得非常容易。 那么，相比于 集中式 版本控制， 分布式 版本控制有什么优势呢？ 集中式版本控制，顾名思义，就是在一个集中式的服务器上进行版本控制，这个服务器保存了所有版本信息，用户只需连接到服务器，就可以读取文件，推送更新。 对于管理员而言，集中式版本控制方便了项目的维护，他们只需控制好服务器就可以了；而对于开发者，他们可以从服务器里获得其他人的工作信息，大大提升了开发效率。 然而，正是因为它集中性，它也就变得脆弱了。一旦服务器宕机，因为所有开发者都没有版本信息，也就无法再继续协作，更糟糕的是，一旦数据丢失，诸如版本信息之类的，就再也找不到了——开发者所拥有的，只是项目的一个快照而已。 于是，分布式版本控制系统就应运而生了。 分布式版本控制系统之下，不仅仅服务器存储了版本信息，每个客户端也都存储了版本信息。 在这种情况下，即使服务器宕机，开发者也可以从其他开发者那里获得版本信息，继续协作。 你会发现我们甚至并不需要专门的服务器来维护版本信息，是的，每个客户端都可以视为一个服务器。 正是因为分布式版本控制的灵活性，我们可以实现很多在集中式管理系统里实现不了的功能，例如同时与多个小组的人协作，进行多分支开发。 我们接下来介绍的 Git ，正是一个非常易用的分布式版本管理系统。 Par...