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