我们常听一个说法“在语法上，C++ 是 C 的超集”，这句话的意思是说，C++ 继承并发展了 C 。这是十分有道理的事情，但是这个说法往往造成两个常见的误解：
这两点其实并不正确。C++ 作为一门独立的语言，虽然起源于 C ，但是在设计思想上和 C 可以说是截然不同，但是又因为起源于 C ，在设计时又不可避免的带上了 C 的烙印，本文希望探讨一下 C++ 与 C 的继承和发展关系，故起名为“滥觞”。
这章可以看作是“CPP设计-寸步难行”的姊妹篇，这章介绍了 C 和 C++ 的不同，“寸步难行”介绍了 C 和 C++ 的相同之处。
当我们提起 git 的时候，我们总说它是版本控制工具。但是版本控制工具到底是什么？我觉得是一种特化的数据库，我们根据版本号去查询对应的项目内容，这种特殊数据库用于进行代码管理。而对于 git，我愿意定义它为“分布式、并发、无锁数据库”。
Git 是 Linus 写出来的版本控制工具，其诞生的直接原因是原来为 Linux 进行版本控制的工具 BitKeeper 不再免费了。也就是说，git 的直接需求是 Linux 的版本控制，而 Linux 是世界上最复杂的开源项目之一，所以 git 的设计是较为彪悍的，它支持最为复杂的分布式并发开发，并且可以促进这种集市一般的开发文化。
正因为如此，我个人觉得 git 并不用户友好，它迫使每一个希望更好地利用 git 的用户，都需要去了解 git 的底层实现理解和 git 面临的现实需求。光是“指针分离”这一个常见的现象，如果希望合理的解释，那么就必须深入 git 的底层实现，在了解了指针引用，版本快照，追踪分支和版本快照等一系列实现知识后，还需要了解频繁切换分支，生成分支，并行开发，分布式开发等多个版本管理需求，才可以明白它为啥不把这种直接暴露底层实现的功能更好的封装一下。
总的来说，git 不够友好，不够简洁，并不是开发者的开发水平不行，而是其需求过于强了，所以不得不将工具设计得这么复杂。而如vscode 或者 IDEA 将 git 封装成更为易用的状态，但是这种方式往往限制了 git 的功能，其本质其实是限制了需求的强度。而一旦面对更高强度的需求，不得不承认 git 做得已经很“友好简洁”了。
