版本控制是企业开发中一个老生长谈的主题,这也是大部分公司新人进来后须要接纳的一个基础知识体系.服务器
从08年首次接触商业软件编写后,这几年前后接触了SVN,TFS,Git这几个主要的版本控制器,可是并无深刻的去研究过包含的思想,分布式
所以下文只能简单描述本身使用这些主流的版本控制的感觉.网站
接触SVN时,对软件开发仍是门外汉,大约只是图个新鲜,当初大约有10我的在同一个Responsite下写代码,只不过每一个人都只作本身的页面,互相不干涉,这样用了版本控制
一年多的时间,我都没有接触过更高深的理念,惟一知道的是,改错代码能够从服务器上找回来,这也是对其最初的印象.blog
进公司时,部门是用的TFS,当初有点逆反心理,以为我会SVN了,为何仍是要学TFS呢,因而在不是特别情愿的状况下先看了一段时间的TFS,对它重视起来是因为本身的一个不当心,开发
从服务器Check Out时,覆盖了本身的改的一些代码,当时是很是沮丧啊,那几行业务代码先后改了1个月,吸收了教训后,对TFS的心理排斥就没有了.不过我我的以为它的缺点有2个:部署
1:TFS服务端我曾尝试本身创建一个,可是对机器环境的要求比较高,尝试失败后,就放弃了get
2:客户端也挺庞大的,那时仍是用的笔记本,感受好卡同步
12年时,部门项目所有转移到Git上开发,和初接触TFS同样,我也是没有太在乎这些,同事简单的告诉我几个命令后,也没有体会到主管说的分布式开发的内在,当时的心理想法是博客
以为大家爱折腾就去折腾,随着项目的推动,有时会遇到多人工做同一个页面的可能性,在没搞懂Git时,发版本常常会出现已修复的Bug又存在下一个版本中,很是纠结啊,当时为一个事故,被直属主管,部门主管,公司领导
依次批评了一顿,因此说不少时候吃亏就是在一些小事情上.如今对Git的使用已经比较熟练了,也愈来愈懂它的强大之处.
它的优点在于相对TFS而言,部署比较简单,有一段时间,我部署在本身机器上,后来发现Bitbucket这个网站后,就全转移到上面了,我的以为开发人员积累本身独立的项目库仍是应该的.
下面贴一张我目前开发Silverlight项目的图:
第1步到第2步,是Git基本的使用,第3步到第4步,是发行版本后,须要修复Bug,第4步到第5步,是2个分支修改Bug同步.寥寥数语,若是对Git比较熟悉的话,
我想这张图很好解释,相比Git官方提供的流程图,省去了一些过程.
对于它的深刻理解: 请参考 http://www.uml.org.cn/pzgl/201112163.asp
关于版本控制器,博客园里不少人研究的很深很细,而我只是略懂皮毛,对上面3个版本控制器的评价主要仍是停留在我的感觉上,不过相比较而言,我更为推荐的
Git了,但愿没有用过的朋友能够感觉下强大之处.