GIT好不好,要看具体情况

中山野鬼 发布于 2012/03/07 14:02
阅读 3K+
收藏 7

先向这里各位技术同行问个安好。最近我也在调研和架构GIT系统。而且GIT是我目前肯定要上的版本控制方式。

很感谢这里有这么多同行发表了关于GIT方面的知识,心得,以补充了我对于GIT方面的信息。但我这里大多数人一边倒的支持迁移GIT的观点表示异议。

我本人的专长是算法优化,简单说就是如何让程序跑的更快,通过改变程序本身代码方式,不是通过调整环境或硬件设备。由于职业习惯,通常动手前,往往要根据需求确定方案。不同的需求,优化的方式完全不一样,甚至相反。其实很多工作也都需要这个思想。得具体问题具体分析。

GIT最主要的优势,我大体也总结一下:

1、分布式。如同网络一样,防止核心部分崩溃导致整体系统崩溃。

2、原生态的linux环境。

其他什么速度,方便,这个都不能算明显的优势。GIT也不能说是最小巧精干的。最小巧精干的,也未必功能完善。

而优势劣势,独立的谈是没有意义的。其实只是事物的特点。只有放在一定场合或环境下,当和环境匹配时,才叫优势,反之才叫劣势。

例如分布式,这个概念很早就有了。而且确实有很多好的地方。但是不代表任何情况下分布式都有优势。如果一个项目任务,集中管理的需求非常明确。分布式的优点就立刻呈现为缺点,此处我就不举例说明。

用linux原生态,来解释,就很简单。在WIN平台下就会有很多问题。当然这里,我相信更多的linux开发人员,自然不用太考虑win平台下的情况。

写这个文章,只是想对一些听意见,特别是还没有确定迁移到GIT的朋友们给个意见。最好结合自己的项目情况,决策。毕竟工具永远只是工具。再好的工具也要看是否适手,是否自己精通使用。

再次声明,我这边马上就会上GIT。因此不是我反对GIT。否则也不会使用。但下面我就对

迁移到 Git 的八个理由

的8个理由,做点极端的反例。同时希望该文章作者不要介意,不是针对您的言论。您的言论我认为是正确的,特别是在我目前的工作目标下。

1、快速

所谓不快速或很慢,更多情况发生在开发团队跨国家,导致异地服务器访问慢。即便如国内大型公司,开发团队分组在几个大城市的BASE,到这个级别的企业,也会大力加强VPN之类的手段,以提高网络速度。所以出现其他,CVS,SVN,P4速度慢导致要迁移GIT的情况,在国内开发团队内很少发生。1秒和5秒是有差异的,0.2秒和1秒,说实话,差异真的不大。所以差异几倍也得看绝对量,那个对比图对系统设计性能有用,对实用性参考,意义并不大。

2、离线工作

这和分组协同开发本身就是个相对矛盾的。要想协同度越高,离线状态要越短。极端的抬杠(上文作者,不好意思啊!先行道歉),各个机器网络中断1周,两个不同组之间就有1周的不同步,双方始终是在对方1周前的版本上开发的,就是分布式再好,也解决不了问题,分布式本身也不是为了解决这个而设计的。CVS,SVN,P4,就开发而言,哪个又不能离线呢?当然可能有人认为我是偷换概念。原文作者明名说的是版本控制。但是离线的版本控制只能是自身代码的版本控制,不是组队的版本控制,这也不是GIT的开发目的和目标。

如果你精通CVS,SVN,P4,你在自己机器上另外架个SERVER,对自己的版本进行控制,阶段性版本上传系统和其他组merge,这个要比迁移到GIT可能更能提高你的效率。

因为,自身代码版本控制,和工程系统团队化的版本控制属于两个概念,后者多了MERGE的工作内容,也是非常重要的内容。也是很多版本控制系统的精髓所在。

3、回退

很抬杠的说,这对没有版本控制概念的新手有诱惑力。对已经很熟练CVS,SVN,P4的熟手,这不是个迁移GIT的理由。

4、省心

这事和回退基本一样。如果公司的服务器崩了,那是IT的责任。记得曾经听过一个老外电视上说过,最安全的方式,还是restore ,backup,当然最老土,甚至不科学。继续抬杠,如果你的版本没有用GIT发布到网络里,你自己的机器崩了,一样不会省心。工具永远不能替代人,比工具更重要的是工作行为和习惯的意识养成。希望大家理解,抬杠的目的不是反对上文的作者,我很支持他,只是不要给别人一个错觉。啊这个好,我们学这个或哎,怎么总出来新工具,我要天天学。更多的精力在整天跟风,而不是自身工作能力和素养的培养上,这样并不妥当。

 

5、选择有用的代码提交

关于这个功能。我目前没有理解的太透彻,也借次机会咨询一下各位朋友。GIT的选择代码提交和自身代码部分合并到系统中,有什么本质区别?如果没有,则一如即往的说,别的版本控制器+merge工具,一样可以处理。而且自己本机一个自己代码的版本控制系统,会更加安全可靠。只是操作烦琐。可能有人说我老土。我表示承认,但我仍然想说程序员的开发行为习惯和思维素质可能更重要,例如我现在写代码基本不DEBUG了。出了错,就把修改的代码进行正向分析,我另可规划代码设计时,尽可能缩小可测试的代码片的规模,也本能的拒绝操作debug。由此的习惯也导致,基本上只要效果有变化,哪怕3,4行代码我都会独立本机做版本提交(本地server,维护我自己的代码版本用的,不是为了和别人merge工程用的)

6、自由选择工作方式

这个不太好提异议。因为我本人更喜欢固化一个工作方式,而精力更多的面对我的工作任务。呵呵。所以没考虑过自由选择工作方式本身有什么价值。

7、保持工作独立性

这个事情很难说。得看项目系统的特性。例如linux本身以及很多开源项目。其项目组织和项目设计的模块化目标就是需要希望能分散开发,独立成型的,用GIT这类,再好不过了。反之,则是噩梦。例如,如果A,B,C,D组,任何一组,都需要同步其他所有组最新的版本才有利于自身工作有效完成,向一个中央服务器一次性获取,还是分别获取,分别merge?集中控制方式,会根据a,b,c,d的提交顺序,将merge工作分别让a,b,c,d完成,自身与当前版本的处理。而分布式,从理论上说,得 a,b,c,d同时完成自身和所有其他团队新代码的合并,由此导致很多重复工作。例如,c是第三个提交,他只需要处理b针对a,b之间已经合并好的新版本,而分布式,理论上,应该是a,b,c,d面向的合并任务均相同。大家都要将所有模块均合并处理。因为理论上,分布式的思想,不存在任何一个结点有义务整合所有工作,并分发给所有人。

8、随大流

如果放在linux开源项目上,我非常支持。准确说不是随大流,这叫做跟着标准化走。实际上这种大流就是没有标准的标准。如果你搞linux OS,其他人都是GIT,实际就是一个标准。你不按标准来,(不是接口协议,开发文档中的标准)而是工具标准,如同英语一样,你就没有办法和别人合作。

但放到项目开发上,我不认同随大流,因为每个人的精力有限,要么什么都懂点,这也是人才,要么专于自己敢兴趣的面上。这才是重点,工具不工具的,也要看是否符合自己而不能随大流。

本文并不是给GIT的支持者或者反对者,而是希望那些非常焦虑每天都要学新东西的人一个提示。应以自己为主,而不能跟着工具转。工具不是拿来学的,而是拿来用的。为了用,值得用,才不得以而学。

 

 

以下是话题补充:

@中山野鬼:提起这个话题的原因是,早在10年前我就不太喜欢学新的软件,逐步养成个习惯,导致现在经常调研一段时间发现不该学。建议大家,针对自由开源的linux环境下的项目很多。贸然跟进去,会耽误和浪费技术人员,如同美女,看看就行,别都追求,虽然确实漂亮,但不一定和你有关系啊。 (2012/03/07 23:53)
加载中
1
ddatsh
ddatsh
LZ写到的 迁移到GIT 8个理由反例中
1.快速
小公司的话,几十M的SVN库,就算是在内网,一台普通PC机作SVN SERVER
浏览LOG也是非常慢的

2、离线工作
真的是偷换概念太厉害了
SVN之类,本地架SERVER,COMMIT到本地,再和REMOTE MERGE?
要知道SVN的分支跟踪无法和GIT的比拟

LZ提到了,要想协同度越高,离线状态要越短,我想你是要尽量避免冲突吧?
在此举一个例子

svn之所以集中管理,一定程度上是需要避免代码的冲突,而git这种所谓的离线提交,等到联网push的时候不是也会冲突吗?从这个角度来看,离线与在线提交都会产生代码冲突,那为什么git就好,svn就不好呢?

群英汇蒋鑫 : SVN 使用功能分支开发,也是要等到合并分支时才解决冲突的。冲突多寡和模块的耦合度相关和版本控制系统关系不大。Git对合并的追踪功能强大, git rev-list BRANCH1..BRANCH2 就可以知道 BRANCH2 哪些提交未合并到 BRANCH1 , SVN 很困难。


3.回退
如果LZ能够详细的罗例各种场景下的回退操作,与GIT相比较后
我认为不不光是对没版本控制概念的新手有诱惑力。和 对已经很熟练CVS,SVN,P4的熟手,这不是个迁移GIT的理由

例如 蒋鑫  的GIT权威指南12章中举的几个例子,悔棋,多步悔棋,回到未来的三种场景,丢弃历史,revert commit,以及rebase ...

 

何况git可以透明的在SVN,CLEARCASE,CVS 等上面套上一层去使用


ddatsh
ddatsh
@Java行者 : 嘿嘿
douglarek
douglarek
呵呵,每每遇到git相关,@dd 都会参战,呵呵,赞同你的关于离线,svn与git无法比拟的说法,一个简单的特性:svn只能保存单一的线性提交历史,一不小心就会被搞糊涂;而git则支持非线性的提交,关于这方面的例子多的不能再多了,我们有时候会看到某个时间的提交甚至早于他的上一个提交,svn只能望洋兴叹了
0
虫虫
虫虫
原创?
红薯
红薯
还用问,肯定是的
0
难易
难易

废话这么多,没有抓住git的精髓,分支

没有哪个版本控制系统对分支有如此合适的支持,

当你的公司要面对不同的客户,或者出不同的可用版本的时候,

你就会发现廉价分支的重要性。

0
中山野鬼
中山野鬼

引用来自“虫虫”的答案

原创?
呵呵。如同上面朋友说的,废话这么多肯定不是摘抄别人的经典名句。
0
中山野鬼
中山野鬼

引用来自“难易”的答案

废话这么多,没有抓住git的精髓,分支

没有哪个版本控制系统对分支有如此合适的支持,

当你的公司要面对不同的客户,或者出不同的可用版本的时候,

你就会发现廉价分支的重要性。

不是我没有抓住精髓,我只是想强调GIT不是任何情况下都是有优势,借此废话文章,给大家一个提醒,别盲目转GIT。不过你说我废话多,这个是个事实,习惯,改不过来了。呵呵。很多朋友都这么说我。
0
天猪
天猪

我们公司是svn, 自己参与开源用git.

想了解下,git在公司里面用, 如何控制权限?

mark35
mark35
@天猪蓝虫. : bingo
天猪
天猪
@mark35 Gitosis?
mark35
mark35
有个程序配合git实现权限控制。这个程序本身就是利用git的功能
0
中山野鬼
中山野鬼

引用来自“天猪蓝虫.”的答案

我们公司是svn, 自己参与开源用git.

想了解下,git在公司里面用, 如何控制权限?

哈。不好意思,我也是新手。看了很多GIT资料。也在学习GIT,理解分布式的项目开发特性。关于权限的问题,我也非常关心,也正在分析。但还能力回答好你这个问题。你这个问题不是个如何使用git命令的问题,是个整个规划的问题。我在学习综合这类的方案呢。希望能多讨论交流。
0
ajavaloser
ajavaloser
先收藏下,过两天再看,楼主,我看好你哦
0
devbean-豆子
devbean-豆子
git 自己没有权限控制,和 svn 不一样,所以 git 的权限控制全部依赖于操作系统以及服务器的设置。
0
天猪
天猪
SSH这块我了解不多, 就不知道git能否做到限制某些用户只能操作某些目录.
ddatsh
ddatsh
参照楼上
返回顶部
顶部