上来就亮明观点，符合我的性格。呵呵呵。
为什么不看好 git 呢？
首先，我们来看看 git 产生的背景。
git 是 Linus 开发的，最初的目的，是为了管理 Linux 系统的源代码。这是一个分层集中式版本控制系统，并非网上人云亦云的分布式版本控制系统。以下作详细说明。
Linux 的开发习惯，与通常软件公司的开发习惯不同：
Linus，或者加上其它少量关键人员，负责 Linux 核心代码的维护，他们可能自己参与开发，也可能接受别人提供的软件包(软件功能增强、改进、或bug修复)，合并到已有的代码库里。在接受其他人提供的软件包时，期望对方已进行完整测试、代码没有明显的问题、代码规范也符合相应的规定，不然，这几个关键人员，有权拒绝此软件包加入到Linux 核心代码。并且，同一个功能，可能有多个贡献方来提交软件包，这几个关键人员可选择其中之一(多个贡献方提交的软件包里选一个)，加入Linux 核心代码。
单个软件包本身可能也比较复杂，由另一批少量关键人员、加上大量的开发人员进行开发。他们也按上述习惯，在接受其他组织/人提供的更小级别软件包时，期望对方已进行完整测试、代码没有明显的问题、代码规范也符合相应的规定，不然，这几个关键人员，有权拒绝此更小级别软件包加入到此软件包。并且，同一个功能，可能有多个贡献方来提交更小级别软件包，这几个关键人员可选择其中之一(多个贡献方提交的更小级别软件包里选一个)，加入此软件包。
当然，有些情况下，软件包的层次会更多。
以上就是分层集中式的开发模式。
问题在于，大多数公司，或者临时/长期组建的软件项目组，都不是按 Linux 核心组的开发习惯，展开工作的。
对于一般公司来说，任何员工的每个小时的工作，都是人力成本，换句俗话来说，都是钱、是费用。为避免因单个程序员电脑硬盘损坏造成的代码丢失，造成公司的费用损失，很多公司要求，每个程序员，每天下班前，都需要 check-in 代码到代码库，那些编译不能通过的部分代码，注释起来，仍要check-in 代码到代码库。
极少有公司去要求：那个谁，你负责的权限模块，全部开发、测试完成后，再放到公司级版本库；那个谁，你负责的订单模块，全部开发、测试完成后，再放到公司级版本库...
因此，Linux 核心代码的管理模式，不具有通用性。
基于 Linux 核心代码的管理模式而开发出来的源代码版本管理工具 git ，也不具有通用性。不适合于大多数公司。
请注意，"分布式"、或"分层集中式"这些词，是时髦的词汇，但绝大部分场合，不需要。
在无需"分布式"的情况下，硬要套用"分布式"的做事方式，只会带来更多的不方便、付出更多的人力成本。
EJB 就是一个很好例子。
单从概念、技术角度，相比之前/同期的同类软件技术/产品/架构， EJB 均是优秀的。被广泛滥用之后，大家都发现，这玩意儿太难用了，无论是开发论坛、员工考勤、企业信息管理、电子商务，还是其他的软件系统/软件工具，绝大多数情况下，EJB 都只会带来技术难度及增加开发工作量。
这还是因为，“分布式”的技术，只适合用于“分布式”的场景下。不具有通用性。
知乎网上，也有很多对比讨论(git vs SVN)。
最明显的一点差别，在于 git 的日常两次提交习惯(第一次提交到本地个人电脑版本库、第二次提交到公司集中版本库)，相比 SVN 的一次提交习惯，需要更多的培训、学习、适应时间。
且日常操作，更显麻烦(操作步骤多一倍)。
当然了，对于单个员工来说，学了不合适的时髦技术，可以增强找工作的个人竞争力；对于公司、团队来说，使用了不合适的时髦技术，增大了总体成本、变相降低了公司的竞争力。
值得不值得用，就看站在哪个角度来判断了。
================================================================================================
========================转发请注明来源:https://www.cnblogs.com/jacklondon/ ===========================
================================================================================================