公司开发部门 GIT SVN 之争

[Navee]

公司最开始决定是使用GIT作为版本控制 , 也都使用了4,5个月了 , 开发人员也都是20多岁年轻力壮的年轻人 , 每个组的组长也一直在做git使用的培训 , 即使是这样 , 还是遇到了非常大的阻碍 , 主要是如下几点 :
1.代码合并导致代码丢失
2.很多人对代码commit到本地后还要push到remote表示很不解
3.个别同事经常反馈commit的记录丢失
因为很多同事都遇到这3个问题 , 所以普偏反馈建议改为SVN作为版本控制 , 特别是接连好几次有同事反馈了第三个问题 , 我和运维都表示很吃惊 , 表示绝对不会出现丢失的情况 ; 但是公司的领导看到这样的反馈 , 还是建议采纳开发的建议 , 改为SVN , 然后运维就将GIT 改为了SVN

个人的一点看法:
对于第一点 , 我觉得完全是开发人员自己的问题造成的 , 如果开发人员不找到自己的原因 , SVN也会出现合并造成代码丢失的问题
第3点问题 , 当时有人说这样的问题 , 我表示也是非常的诧异的 , 我自己也是刚用git , 但是也觉得并不会出现这样的问题 , 之道有一次自己做了这样一个操作 , 在一个branch上checkout了一个commit,然后在这个commit的基础上做了一下修改,然后commit了,最后checkout 原有branch时发现 , 这个commit在branch的log上是不存在的 , 由此我猜测是不是当时那位遇到commit丢失的同事是否也是像我这样操作了 ;

总之用了一个多月的git , 觉得git在需要频繁修改bug的场景下 , 发挥巨大优势的branch比svn还是要好用很多的 ; 发表这个帖子并不是想说git 比svn好用 (LZ在一个公司使用过2年的Microsoft sourcesafe , 那种恶心的版本控制简直不想再提) , 而是提一下自己以及同事在使用git确实会遇到一些影响开发的问题 .

[Navee]

@xudongz 最初并不是由我决定用git的 , 而是几个组的负责人决定的 , 原有开发团队使用了几个月并没有发生过任何问题 , 问题是出现在最近团队扩充了一些新人 (我也是新人) , 新员工有做git使用的培训的. 领导决定换到svn , 是因为项目负责人在新员工反馈问题后再次做了git使用培训, 依旧有反馈问题 , 并且影响了项目的开发 (主要是代码合并问题), 才决定换回svn的

[Catstyle]

少年，你都checkout了，你还想看到什么东西？
建议好好看看progit这本书，搞git的应该人手一本，起码过一遍

[Navee]

@Andiry a001 002 指的版本hash

[tracyone]

git其实比svn容易多了，对个人而言，不需要搭建什么服务器....一个git init，然后git add ...然后你就可以开始修改...不断git add然后git commit.

[tabris17]

既然平台存在就没必要迁移，各用各得不就好了么

[jarlyyn]

git绝对不是必须的。

但连git最基本基本的操作都不能理解的话，似乎有点不太是和做程序员了？

[yoa1q7y]

@Navee 大哥！！！你的表述完全是git的正常表现啊亲
你有没有理解checkout,rebase,HEAD,commit这几个概念啊。。。。原来这就是你所说的提交丢失。。
这完全就是你不会用，或者概念根本没理解
简直无语

[Navee]

@sortbylist 我发帖并不是想下个结论svn 和git中哪个更加好用 , 而是想描述一下svn和git在项目开发中使用的问题 , 让那些还在争论项目中是使用svn还是git的同学看看

[2code]

我们这边设计师都会用git，那些说会丢commit的人，好意思说自己是做开发的？

[feilaoda]

赶紧把那些人开了，git都不愿意学，也指望那些人去学一些更深更难的东西。你让他学其他，也会瞎bb。
git带来的好处，只会svn的人能懂？

[yoa1q7y]

@sortbylist 用了这么多年git，头一次听说有丢失记录的情况
全世界都在用git，请不要把你不会用，不愿研究，理解能力差推卸到git身上

[metrue]

我们用perforce，也挺不错的，有专门的integration team 来做大规模merge。

[Andiry]

@Navee 你所说的这第三步 3.checkout a001 , 修改a文件提交一版a003 根本就不成立，git会提示

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

用checkout -b根本不会丢东西

[Andiry]

不过git也是有缺陷的，如果文件系统挂了还在做修改，很可能reboot之后整个git就挂了，需要手动修正head。这个我还真碰到过。

[Navee]

@yoa1q7y
我知道造成commit丢失肯定是我操作上的问题 , 但是你不能否认的是 , 在以一个成功的操作下 , 产生了一些奇怪的问题 , 对使用者( 特别是那些刚刚使用git的用户)来说是多么大的困惑
如@sortbylist 所说 , 你用的没有问题 , 并不能代表别人使用的没问题 .
我只是就自己遇到的问题做了一个操作还原而已 , 你说我操作有问题 , 然而你也并没有说出问题出在哪里, 而是搬出一大堆唬人的概念:checkout,rebase,HEAD,commit , 是不是我再问你你就让我补git 基础知识去?

[sortbylist]

@yoa1q7y 全世界都在用git，吹牛皮也先打下草稿。你怎么不说全世界都在用linux，全世界都在用vim。所以不会用，不会研究，理解能力差就怪公司员工咯，这么牛逼把他们都辞了，招聘简章里写必须会用git，因为我们公司不提供svn，来了也不能开发，快滚。我就呵呵了。
公司领导决定使用git，并且使用了四五个月，就说明是在研究，是在理解，最终无法代替svn，让所有人都能很好的开发，就说明git没有svn好。懒得跟你扯别的。要么辞了那些不会用git的人，要么就转回svn。你选个吧。还不研究，理解能力差。都这么牛逼，windows直接滚蛋。

[Navee]

@feilaoda 我确实是不想和那几个天天吐槽git不好用的同事共事的 , 和他们一起工作给人的感觉就是:遇到问题都是找别人的原因

[gengzhengtao]

大型项目的分布式开发的确很适合使用 GIT 来进行管理，但是如果你们公司的项目更倾向于集中化代码管理，开发人员无法将代码带出公司，也不需要离线开发，分布式开发，那用 SVN 并没有什么错，而且对于开发人员来说理解起来也简单，误操作也少，反而更好。没有什么是最好的，只有最合适的。

[jdlau]

丢了代码就说是工具的问题，这人你放心？

[yoa1q7y]

@Navee 是的，我就是要告诉你把基础知识看一遍
http://git-scm.com/book/zh/v1
我说的这些概念是使用git必须要理解的，请问有什么问题吗？
你的问题出在你没理解这些概念，请问有什么不对吗？