企业版本控制的改革：从ClearCase到Git--我的布道之旅
#企业版本控制的改革：从ClearCase到Git–我的布道之旅# #前沿#
特别声明：本文专为图灵社区活动“唤醒你心中的布道师”而写，欢迎大家积极参与！
特别感想：本文的风格照搬高翌翔的“布道体” 从自定义ORM框架到NHibernate——我的识道、行道、布道之旅
程序员杂志第十二期中讲到了企业开发的困境，其中有一点就是企业的流程和工具很难适应新的敏捷开发模式。我认为其中之一就是版本控制系统，本文就是探讨一下我是如何来推动这个改变的，也就是我的布道之旅。
【免责声明】这里不是探讨两种技术的好坏，而是如何推动变革，每个技术都有适应的场所，请勿生搬硬套。关于版本控制的选择，可以看看Martin Fowler写的版本控制工具(english)
#介绍#
在传统企业中，版本控制系统大都采用ClearCase，因为在早期它应该提供了强大的企业应用的功能，我们企业也很早使用了。而且长久以来，在它周围建立了无数的应用和流程，同事们都觉得它是必须的了。
然而随着敏捷和开放的推动下，在有些产品用Clearcase开发碰到了很多局限，比如在家上班，远程团队开发。有人开始想到引入其他工具（svn，git）来解决，不过在大型企业中要改变这种基础的工具是很难的。
我做为一个软件开发的探索者，努力的想改变点什么，但不知从何而起。
#了解分布式版本控制（DVCS）——初识道#
开始考虑这个的时候是在2009年初，svn是第一个考虑的对象，因为它在开源中用的最多，sourceforge和eclipse的很多项目多用它，但我总觉得缺了点什么。
恰好我有个Geek朋友：陈忠克极力推荐一个分布式版本控制工具：mercurial，说实话听了介绍不是很懂，没有眼前一亮的感觉。聊了一下，感觉和svn的分支没有多大区别，还两层提交呢。
同时他也告诉我还有其他的分布式版本控制工具git，bazaar可供选择。
不管怎么样，我了解了这块领域有了最新的技术，或许能解决我们的问题。
#尝试在日常中使用分布式版本控制——初行道#
为了尽快了解DVCS，我决定要在日常的开发中用用它，实践它，尽快的掌握它的关键。
由于Geek对mercurial很熟，我就踏踏实实的用mercurial用了两个星期，不懂就问他，顺便查查资料去比较一番。
wooh,wooh，DVCS真是很神奇，很好用，特别对我（作为码农）的胃口，感觉DVCS天生是为软件开发用的。
在同一时刻，我又比较深入的看了看其他的系统如git，发现git的生态圈更好一点。在软件开发中，生态圈会决定将来这个工具的发展趋势。
- 如eclipse插件开发邮件中开始讨论并决定用git替代svn。
- git有很多的书可供选择（如 ProGit），git在线网站的内容也极其丰富。
- github也漂亮得提供git的支持。补充一下，那时候bitbucket和github还在同一个水平线上。google code也还不支持git，只有mercurial和svn。
通过这些实践和了解，发现DVCS：git很适合我们所在的企业产品软件开发。
#宣扬和推广分布式版本控制——初布道#
要在企业中换一个版本控制工具难度非常大，所以必须要造势，也就是此处的布道，我采用了下面的方法：
- 每月我们都有固定学习新东西的时间，我就推荐了mercurial、git两个课程，让大家共同来学习，了解它。顺便我要看看开发者对它的接受程度，有趣的是，水平越牛的人越是喜欢它，纷纷过来问什么时候能在产品开发中用上git。
- 除了开发者，管理者和其他的使用者（配置管理的同事）的想法也很重要。我经常抓住机会和这些人聊DVCS ，聊git，给他们介绍，看看他们有什么想法。当然他们会不同意我的观点（有强势的，有委婉的），我就试图去说服他们，挖掘出推动这个变化的关键因素。
慢慢的我就开始得到了很多如何推动这个变化的材料，以及说服他们的模板（哈哈对症下药）。
#详细研究版本迁移——再识道#
开发者想使用分布式版本控制的呼声越来越高，管理者也开始认真考虑了。
在企业中，改变所需要的研究评测报告（word，ppt)是必不可少的了，这也给了我一次重新认识集中式和分布式版本控制的过程，我花了更多的时间去想这个改变对企业带来的好处。实际上开发者有时候不会考虑到整个软件开发的所有方面，如安全，持续集成等等。报告的大致框架是：
- 现在问题是什么？
- 什么是DVCS，git是什么？
- 能改变什么？带来的好处？
- 如果变化，计划是什么？
研究报告就不细讲了，太技术了，而且有点商业机密，哈哈。
这一期间，使我更详细的了解了git和对企业可能的影响（有好的，有坏的），并制定了相应的对策。
#开始在小范围实施——再行道#
布道需要耐心和机遇，机缘巧合，迁移到git的建议比较顺利的被管理层接受了。（我的报告难得那么顺利通过的）。
然后就是要去认认真真的实施了，这不是一个小问题，既然是软件开发，来不得半点的马虎，细节决定一切。而且实施的好坏还涉及到自己的面子问题，讲笑了。
企业中一般从小范围开始实施，成功了才推广，下面是我们的一些实践。
- 我们用gitolite作为git服务器，架好试验平台，在一个小项目中开始尝试。
- 人手一本git的书，安排git入门培训，提高驾驭git的能力。
- 不断收集资料，提高对git的认识。
还好基本上没有出大的差错，虽然有蛮多技术难点的，不过最后都解决了。通过小范围的使用推广，我们的技术储备也加强了（特别是配置管理的人），对下一步的全面实施更有信心。
#推广，并引入gerrit做代码审查——再布道#
早期我们用的是gitolite来架git服务器，它很不错。不过后来发现gerrit更好用，后来就切换过去使用了。这一点很重要，要不断探索这些新技术，争取在大规模推广前，用一个最适合的工具，否者一用上，在企业中就很难改变了。
git开始在更多团队和更多产品中使用后，我们不断加强知识的培训，而且把相关的系统（如持续集成）都迁移到git上去。一切都还不错，只是git比想象中还复杂一点。
因为gerrit有很强大的代码审查（code review）功能，不久以后这个功能也用上去了，代码提交的质量一下子上了一个档次，这是开始推动git变革时没有想到的。
#结束语#
（此处引用高翌翔写的“布道体”结束语）
子曰：己所不欲，勿施于人。因此，布道者在布道前，须识道、行道，而布道时应谨记“己之所欲，慎施于人”，身教重于言教，务必身体力行、以身示道！
我的识道、行道、布道之旅没有终点，希望能结识更多的同路人 ;-)
#其他# 本文也是我用git记录在github上的，你可以看到每次的变化。
如果对此文有兴趣，帮忙顶一下，别忘了 @larrycaiyu ，希望有机会有人能帮我推荐到QConf 2012中去分享，到时我们可以探讨的更多。