内网搭了个gitlab,团队其他成员认为svn足够了

kakai 发布于 2018/06/22 18:45
阅读 6K+
收藏 1

都不愿意接受和学习新事物,哪怕新事物更好。我跟他们说git比svn最明显的优点是可以建立多分支版本,项目对外发布时不容易出错。难道我的出发点不对吗?

加载中
0
御坂网络路由器
御坂网络路由器
安利的姿势不对,没抓住团队其他成员选择版本管理工具时的痛点。第一次安利失败了搞得气氛不融洽的话接下来越安利越反感,建议能忍则忍,忍不了就走人吧。
张云飞
张云飞
回复 @kakai : 你自已都用不熟, 团队里都习惯用svn,出了问题谁解决? 你觉得你这个建议合适吗? 在公司里做事主要是把事情做好,别太在意用工具。等你自已HOLD住,或者团队里有其他大牛在时再考虑不迟。
kakai
kakai
我也只是建议,这个团队合作做过一个项目,所以难以接受新的东西,我刚来,决策不了,仅仅建议而已。说实话,我自己对git也不是很熟练,也只会基本的东西,我是看到他们对外发布时都出错几次了。
1
wei2011
wei2011

对于团队来说,个人认为svn的确够用了,svn也可以创建多分支。git是专门为开源设计的,比如看到好的项目可以fork一下,自己当作私人项目来改,心情好可以发pull request到主分枝...但对于团队来说,好像不需要这些操作吧?对于团队来说现在用git只是当做另一个svn来用,没体会到git独到的地方,欢迎科普一下。

0
孤星闵月
孤星闵月
就我个人感觉,在不需要分布式的情况下,SVN确实比git好用
alleys
alleys
回复 @abcbuzhiming : 说的很好,虽然我在用git带是分支真还没用到,我们公司开发也就5个人,每人负责不同部分功能的代码,基本上就一个主分支就够了, 小项目,一套测试环境,测试没问题,就直接更新线上了,之前我还弄个开发分支,后来也不用了,直接一个master就行,上线出问题回滚下就OK, 唯一不好的就是master上太多提交,包括临时处理的bug会不太好看。好看就弄个dev分支
abcbuzhiming
abcbuzhiming
回复 @kakai : 大部分安利git失败的原因是很多团队其实压根就不需要分支。分支在开发中还真不是必须的,尤其是很多小型团队,主分支足够了。技术这个东西,不是越好就越受欢迎,更多功能,更多代价,你要推广,一定要找准团队的痛点,而不是“你认为这东西好”
kakai
kakai
也不是分布式,svn仅需提交一次,而git需要提交到本地,再推送到远端,麻烦点,但各分支独立运作,好处还是很多的。
0
eppen
eppen
Git用不明白还是SVN吧,省得出了同步问题还得找人解决。
kakai
kakai
那倒不会,因为我以前工作中也用git做过几个项目了,一般性问题还是能解决的。
0
tianyuliang
tianyuliang

相比之下,  git体验还是非常好的,尤其是熟悉了git命令的情况下

0
f
freezingsky

一个版本管理工具,都能抗拒。做为技术人员,对于流行的,而且被大范围推广的东西,没有一点想尝试的心?

0
麦壳饼
麦壳饼
一个版本管理都抗拒!是什么心态?这样的同事不共事也罢
0
朱__朱
朱__朱

说用svn就够了的,大部分根本不会用Git, 或者学了几天用了几天就放弃了;

说Git好用的,大部分都用过挺久的svn,或者被迫正在用svn

谁的说法更正确?不言而喻

我觉得一个技术人员,公司要求用svn没问题,但Git这么流行,这么受业界推崇,至少你自己要把Git玩的溜一点吧?又不是多难的东西。

所以我认为,不会用Git, 不喜欢Git的,基本上可以归到不爱学习,上进心不足的一类人里面去,除非没办法,否则面试的时候直接排除掉的。

另外,安利给别人的时候,心态要正确:你是在帮助别人,别人不接受,吃亏的是他,你只需要探口气怒其不争就可以了,没必要争。

安利的方式要正确:首先向有决策权的人安利,看其态度。如果决策人本身就是个老顽固,你们就是全都说用Git, 他也不会鸟你们。

张云飞
张云飞
SVN或者GIT都是版本管理工具,没和要那么纠结。和想不想学习没有半毛钱关系,人家可以剩下时间学习别的东西不行吗
张云飞
张云飞
为公司不用git就放弃工作,明显对git本身不熟悉,你那么喜欢GIT你可以SVN拉下来后本地GIT啊,GIT所有特性一样可以用。本地测通过再用SVN一次性提交好了。
t1n4c
t1n4c
这帽子扣得我实在是佩服
0
s
sleetdrop

SCM只是软件交付流程中的一个工具,不必太纠结。git比较繁复,但提供每项功能都是实打实的解决源码版本控制的痛点的,但上手有成本,且灵活性过高,未必完全适合企业使用,所以虽然同样是用git,根据不同的公司类型,开发的软件类型,交付的形式和节奏使用起来都各有不同。也就有了各种不同的flow. 比如linux内核的flow, 前两年推荐的git flow, Github基于PR, Gitlab基于MR的flow等,都是受限的使用git的一定量的子集来构建适合具体场景开发流程的。而且像认证,细粒度权限控制粒度等 git 自身并不提供企业类型的支持,所以不是用svn就落后,用git就先进。早以前 visual sourcesafe 和 cvs 等现在看起来那么尴尬的东西也支撑了很多大型的成功项目。如果git不熟练,不守规约,可能会引入更疯狂的问题。但如果用好了,生产力是远大于svn的. 且git也不算啥新东西,这种DVCS也有一些历史了,还可以算上和linux社区闹翻前Linus用的bitkeeper. 还有目前nginx还在用的mercurial. 都是开发了数年的成熟的DVCS实现了。

在团队中永远有部分人会接受新事物,一部分顽固派,一部分骑墙派。可以参看《布道之道》那本书里推荐的一些方法。

但你要有意愿引入新的生产力工具就要自己多花些时间把相关的东西搞通,然后show给大家。比如你把svn里的项目导入到gitlab里给大家秀一下它的好处,特别是对于生产力提升方面的,会得到Team leader的支持,这个对于执行比较重要。现在gitlab除了对于flow的支持,也带有wiki, bug和需求跟踪,CI/CD的各种接入等功能。对于中小型团队足够用的。

所以你与其烦恼发帖,不如先按楼上@uniqptr提到的去弄一个生动的小课件之类的给大家以正确的姿势安利一下。

BTW: 看到 uniqptr 的昵称好想在前面加个 * 取出来看里面有啥 :)

0
数字X
数字X
只会git,不会SVN的路过
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部