第 9 章附录 A: Git 的缺点

优质

小牛编辑

126浏览

2023-12-01

有一些Git的问题，我已经藏在毯子下面了。有些可以通过脚本或回调方法轻易地解决，有些需要重组或重定义项目，少数剩下的烦恼，还只能等待。或者更好地，你可以加入 Git项目来帮忙。

SHA1 的弱点

随着时间的推移，密码学家发现越来越多的SHA1的弱点。人们发现，对资源雄厚的组织而言，找到哈希冲突是可能的。在几年内，或许甚至一个一般的PC也将有足够计算能力悄悄摧毁一个Git仓库。

希望在进一步研究出摧毁SHA1的方法之前，Git能迁移到一个更好的哈希算法。

Git在微软Windows上可能有些繁琐：

因为Git记录的是项目范围内的变更，重造单一文件的变更历史比其他跟踪单一文件的版本控制系统要稍微麻烦些。

好在麻烦还不大，也是值得的，因为Git其他的操作难以置信地高效。例如，`git checkout`比`cp -a`都快，而且项目范围的delta压缩也比基于文件的delta集合的做法好多了。

当一个项目历史很长后，与在其他版本系统里的检出代码相比，创建一个克隆的开销会大的多。

长远来看，开始付出的代价还是值得付出的，因为大多将来的操作将由此变得很快，并可以离线完成。然而，在一些情况下，使用`--depth`创建一个浅层克隆比较划算些。这种克隆初始化的更快，但得到克隆的功能有所削减。

一些中心版本控制系统都会维护一个正整数，当一个新提交被接受的时候这个整数就增长。Git则是通过哈希值来记录所有变更，这在大多数情况下都工作的不错。

但一些人喜欢使用整数的方法。幸运的是，很容易就可以写个脚本，这样每次更新，中心Git仓库就增大这个整数，或使用tag的方式，把最新提交的哈希值与这个整数关联起来。

每个克隆都可以维护这么个计数器，但这或许没什么用，因为只有中心仓库以及它的计数器对每个人才有意义。

空子目录不可加入管理。但可以通过创建一个空文件以绕过这个问题。

Git的当前实现，而不是它的设计，是造成这个缺陷的原因。如果运气好，一旦Git得到更多关注，并其有更多用户要求这个功能，这个功能就会被实现。

传统的计算机系统从0计数，而不是1。不幸的是，关于提交，Git并不遵从这一约定。很多命令在初始提交之前都不友好。另外，一些极少数的情况必须作特别地处理。例如重订一个使用不同初始提交的分支。

Git将从定义零提交中受益：一旦一个仓库被创建起来，HEAD将被设为包含20个零字节的字符串。这个特别的提交代表一棵空的树，没有父节点，早于所有Git仓库。

然后运行git log，比如，通知用户至今还没有提交过变更，而不是报告致命错误并退出。这与其他工具类似。

每个初始提交都隐式地成为这个零提交的后代。

不幸的是还有更糟糕的情况。如果把几个具有不同初始提交的分支合并到一起，之后的重新修订不可避免的将需要人员的介入。

对提交A和提交B，表达式“A..B”和“A…B”的含义，取决于命令期望两个终点还是一个范围。参见 git help diff 和 git help rev-parse 。