Git的推广心得

这两周已经开始在公司几个项目/产品里推广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立功不小)。

我制定的规范大致有两个:

  1. 双分支代码结构
  2. 严格的代码提交规范

并有一个推荐的(非强制的)最佳实践:

  1. 使用git-flow轻松控制提交粒度

双分支代码结构

双分支指项目推进过程中总是保持使用两个主分支:开发分支(develop)、成品分支(master)。

1)开发分支(develop)

日常的开发工作都是围绕该分支进行。开发分支上的代码只有在封版的时候才会被合并到master分支。

本地的develop分支,开发人员在上面开发功能并提交,当完成一个完整的功能开发并通过测试时,才能把代码push到远程的develop分支。

远程的develop分支上的代码,要求在任何时候总是可以通过编译,所以每次队员把代码push到服务器上之前,需要确保自己的代码已通过编译并测试。远程的develop分支的代码会用于项目的自动构建。

2)成品分支(master)

该分支上面的代码总是稳定的,成品级的。只有在每次发布新版本的时候,才会从develop上面把上版本开始到现版本的修改移到master分支,master分支通过标签(tag)来区分不同的代码版本。产品的实施人员所面对的总是该分支。

代码提交规范

代码提交规范有三大点,必须严格遵守:

  1. 控制好提交粒度。每次的提交都必需具有独立性的原子性,建议是以一个功能点或Bug fix为单位;无直接关联的文件不能在同一次提交;除了初次提交,尽量不用commit -a。
  2. 认真对待提交备注,多花一分钟回想本次提交的代码所含的意义,清晰描述下来,很有可能以后看备注的人是你。
  3. 编译、运行及测试没通过的代码不允许提交到服务器

基本上,严格遵守上面的代码提交规范,在双主分支的结构上协作,过程马上会变得舒服,如果加上一个提交粒度辅助工具的配合,那么效果更佳。

善用git-flow

git-flow的介绍可以参考我之前的文章(),在我的实践中,开发团队当中使用git-flow的话,使用最多的命令仅是git flow feature star/finish xxx,版本的发布只需要有一个人负责就行,所以git flow release start/finish vxxx这样的命令他们基本上可以不懂,hotfix那些更远的点的功能则可以到时再说。

所以,在团队内使用git-flow的难度并不大,最大阻碍可能是不能与现有的Git可视化工具结合。

使用git flow feature命令的益处在于:

  1. 方便地实现功能级别的粒度管理,让功能级的回滚更简单。
  2. 很好地隔离同时开发的功能代码,你可以同时本地start多个feature,而新代码互不相干扰

目前git-flow在团队内并不强制使用,不使用git-flow的前提是要使用双分支代码结构以及遵守提交规范,和细心地在各分支之间切换。

有git-flow那么方便的工具在,何乐而不用呢?

又是阶段性小结

在多人的团队内推广新的思想或新工具不容易,问号多,大家水平参差不齐等因素都会制约着推广的成效。这一次的推广,我准备了比较长的时间,包括学习、熟悉Git,反复思考和对比,最终确信Git推广好了,对团队、产品甚至我自己都是大大的益的。我觉得,在向别人推荐一种东西的时候,最好确保你对它非常了解了,包括它的好处,坏处。

由于大家水平参差不齐,不要指望一次培训就可以摆平。尽可能去到队员的位置上,帮助他们开始。因为你是花了几个月的时间来实践的东西,怎么能要求他们听你一堂课就学会?

最后附上我在公司培训用的PPT:

Git

View more presentations from jeffkit.

点击这里下载: git

This entry was posted in 技术, 软件 and tagged , , , , . Bookmark the permalink.

5 Responses to Git的推广心得

  1. joseph says:

    master对应的传统的RC Branch,
    远程develop对应传统的Trunk
    本地develop对应传统的(private)Feature Branch

    这样理解对吧?

  2. francis says:

    重点我感觉不在与版本控制的软件,而是写代码人员的态度。
    遇到过说一下班再也不想摸电脑的人,真不知道为啥要干这行。

    SVN提交信息可以忽略,索性每次就不写空着,被指责了就写上去几个点;
    提交时候不仔细看,一下把所有文件推上去,忽然发现把自己的配置信息也推出去了;
    没多一会儿又发现刚才居然又忘记add了几个文件,又一个新的版本诞生了 = =

    • jeff says:

      嗯。。没错啊。关键还是人和方法 :)

    • davidx says:

      赞同~
      工具只是帮助人们, 怎么使用, 是要靠观念和规范来指导的
      如果有好的思想, 用任何SCM都能很好的控制软件质量的
      所以, 带自己的团队, 代码规范, 开发流程, 都要提前规定好, 并严格执行

发布评论

您的电子邮箱不会被公开。 标记为 * 的区域必须填写

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>