不看好 git ,也看不懂为什么那么多人去使用 git

2019-09-10 13:33

 

上来就亮明观点,符合我的性格。呵呵呵。

为什么不看好 git 呢?

首先,我们来看看 git 产生的背景。

 

git 是 Linus 开发的,最初的目的,是为了管理 Linux 系统的源代码。这是一个分层集中式版本控制系统,并非网上人云亦云的分布式版本控制系统。以下作详细说明。

 

Linux 的开发习惯,与通常软件公司的开发习惯不同:

Linus,或者加上其它少量关键人员,负责 Linux 核心代码的维护,他们可能自己参与开发,也可能接受别人提供的软件包(软件功能增强、改进、或bug修复),合并到已有的代码库里。在接受其他人提供的软件包时,期望对方已进行完整测试、代码没有明显的问题、代码规范也符合相应的规定,不然,这几个关键人员,有权拒绝此软件包加入到Linux 核心代码。并且,同一个功能,可能有多个贡献方来提交软件包,这几个关键人员可选择其中之一(多个贡献方提交的软件包里选一个),加入Linux 核心代码。

linux core accept some software components, and deny some others.

单个软件包本身可能也比较复杂,由另一批少量关键人员、加上大量的开发人员进行开发。他们也按上述习惯,在接受其他组织/人提供的更小级别软件包时,期望对方已进行完整测试、代码没有明显的问题、代码规范也符合相应的规定,不然,这几个关键人员,有权拒绝此更小级别软件包加入到此软件包。并且,同一个功能,可能有多个贡献方来提交更小级别软件包,这几个关键人员可选择其中之一(多个贡献方提交的更小级别软件包里选一个),加入此软件包。

当然,有些情况下,软件包的层次会更多。

以上就是分层集中式的开发模式。

 

问题在于,大多数公司,或者临时/长期组建的软件项目组,都不是按 Linux 核心组的开发习惯,展开工作的。

对于一般公司来说,任何员工的每个小时的工作,都是人力成本,换句俗话来说,都是钱、是费用。为避免因单个程序员电脑硬盘损坏造成的代码丢失,造成公司的费用损失,很多公司要求,每个程序员,每天下班前,都需要 check-in 代码到代码库,那些编译不能通过的部分代码,注释起来,仍要check-in 代码到代码库。

极少有公司去要求:那个谁,你负责的权限模块,全部开发、测试完成后,再放到公司级版本库;那个谁,你负责的订单模块,全部开发、测试完成后,再放到公司级版本库...

 

因此,Linux 核心代码的管理模式,不具有通用性。

基于 Linux 核心代码的管理模式而开发出来的源代码版本管理工具 git ,也不具有通用性。不适合于大多数公司。

 

请注意,"分布式"、或"分层集中式"这些词,是时髦的词汇,但绝大部分场合,不需要。

在无需"分布式"的情况下,硬要套用"分布式"的做事方式,只会带来更多的不方便、付出更多的人力成本。

EJB 就是一个很好例子。

单从概念、技术角度,相比之前/同期的同类软件技术/产品/架构, EJB 均是优秀的。被广泛滥用之后,大家都发现,这玩意儿太难用了,无论是开发论坛、员工考勤、企业信息管理、电子商务,还是其他的软件系统/软件工具,绝大多数情况下,EJB 都只会带来技术难度及增加开发工作量。

这还是因为,“分布式”的技术,只适合用于“分布式”的场景下。不具有通用性。

 

知乎网上,也有很多对比讨论(git vs SVN)。

最明显的一点差别,在于 git 的日常两次提交习惯(第一次提交到本地个人电脑版本库、第二次提交到公司集中版本库),相比 SVN 的一次提交习惯,需要更多的培训、学习、适应时间。

且日常操作,更显麻烦(操作步骤多一倍)。

 

当然了,对于单个员工来说,学了不合适的时髦技术,可以增强找工作的个人竞争力;对于公司、团队来说,使用了不合适的时髦技术,增大了总体成本、变相降低了公司的竞争力。

值得不值得用,就看站在哪个角度来判断了。

 

 

欢迎转载,转载请注明出处: https://www.zheguisoft.com/staff_blogs/jacklondon_chen/2019, 及 https://www.cnblogs.com/jacklondon/p/git_will_not_go_far.html