按分类归档：技术

这两周已经开始在公司几个项目/产品里推广Git了，有一些心得，在此分享： 工具神马的都是浮云 实际上，工具神马的都是浮云！ Git或HG之类的DVCS就是神器吗？不，充其量也只是另一个VCS或SCM，所谓的分布式、轻量级分支神马的在某些人看来或许是扯蛋的玩意，人家可能用SVN用得不知有多爽多出神入化呢。如果你仅仅是因为要推广一种新工具而去推广Git，那你一定会饱吃闭门羮。不信试试。 真正重要的，是驾驭在工具上面的灵魂（思想），有些人虽然用着Git，但只把Git当作备份工具用；有些人尽管还用着古老的抢占式的VSS，但提交的守则却是规规范范，标签打得清晰条理！前者不管用什么版本管理工具，都是YAST（Yet Another Scm Toolkit），而后者不管用什么管理工具，都能把代码版本管理得齐齐整整。 记住一点：不要把版本管理工具当作代码备份工具用！否则，你需要的只是dropbox。 既然工具是浮云，那我为什么还选择Git？嘿，当你的团队开始有了强有力的版本管理意识支持后，就会下意识地选择方便趁手的工具（好吧，我这里不说强大），Git实际就是这么一种工具，适合各种各样有洁癖的人、提交狂人等。 规范地使用SCM才是正经事 如果你的团队习惯把SCM当备份工具用，那么恭喜你，你有足够好的切入点推广Git了。如何判断一个团队是否把SCM当作备份工具了，有大概以下几个可供参考的现象： 一古脑儿的提交文件，有时1个文件，有时十几个文件，N个功能点一齐提交 备注的特征：“略”，“提交一些代码”，“fix一个Bug”，“今天的代码”等 从来不给代码打上版本号，程序从头到尾只有唯一一个版本，就是Now 遇见冲突就慌张，不懂处理 等等 我推广Git，目的不是为了Show up，说我懂得一个很潮的东西，你们也跟着用吧，而是要彻底改变团队把SCM当备份工具用的习惯，是为产品代码质量负责。 代码版本管理，最终目的是要实现代码版本的可控性，包括大至版本级的重取，包括功能级别的增减，甚至是小至commit级别的回滚。我用以达到这种可控性的是一些规范，而非Git本身（当然Git及它的扩展Git flow立功不小）。 我制定的规范大致有两个： 双分支代码结构 严格的代码提交规范 并有一个推荐的（非强制的）最佳实践： 使用git-flow轻松控制提交粒度 双分支代码结构 双分支指项目推进过程中总是保持使用两个主分支：开发分支(develop)、成品分支(master)。 1）开发分支（develop） 日常的开发工作都是围绕该分支进行。开发分支上的代码只有在封版的时候才会被合并到master分支。 本地的develop分支，开发人员在上面开发功能并提交，当完成一个完整的功能开发并通过测试时，才能把代码push到远程的develop分支。 远程的develop分支上的代码，要求在任何时候总是可以通过编译，所以每次队员把代码push到服务器上之前，需要确保自己的代码已通过编译并测试。远程的develop分支的代码会用于项目的自动构建。 2）成品分支（master) 该分支上面的代码总是稳定的，成品级的。只有在每次发布新版本的时候，才会从develop上面把上版本开始到现版本的修改移到master分支，master分支通过标签(tag)来区分不同的代码版本。产品的实施人员所面对的总是该分支。 代码提交规范 代码提交规范有三大点，必须严格遵守： 控制好提交粒度。每次的提交都必需具有独立性的原子性，建议是以一个功能点或Bug fix为单位；无直接关联的文件不能在同一次提交；除了初次提交，尽量不用commit -a。 认真对待提交备注，多花一分钟回想本次提交的代码所含的意义，清晰描述下来，很有可能以后看备注的人是你。 … 继续阅读 →