背景

随着同一业务线研发人力增多,混乱往往就逐渐成为了必不可免的问题。此时如果没有一套科学的流程规范,成员「个性」将会导致项目维护成本越来越高

本文主要从分支日志两个方面来谈谈git在项目版本管理中的策略

分支管理策略

说到分支管理,就不得不提工作流。目前业内广泛使用的工作流有三种:Git flowGithub flowGitlab flow

在写这篇文章之前,我用过的也只有Git flow一种,我原以为其一招鲜就可吃遍天,结果发现这事还没那么简单。对于这三种工作流的介绍,阮一峰老师的博客里写的很清楚,科普请自提之。这里主要说使用策略

阶段性版本发布项目(Git flow)

对于目标是一段时间以后产出一个新版本的项目,Git flow是合适的。特别是对于小团队单线开发,不会有多需求同时开发的情况。使用Git-flow可以最大程度保证项目安全、有节奏的完成发布和管理。因此Git-flow适合有节奏按版本发布的项目,团队人员在4人以下

在这种流程下,需要同时维护两个长期分支:master、develop。比较合适的场景有:

  • 开源类库
  • 客户端项目(如iOS App)

持续发布项目(Github flow 与 Gitlab flow)

对于发版不固定,甚至代码一有变动,就部署一次的项目。Github flow是合适的。因为这种流程足够简单,就一个长期分支master维护。比较合适的场景有:

  • Web或者动态化业务(RN、Weex)
  • 后端接口服务

上图是Github flow的一个单线使用流程。而在互联网公司中往往为了最大化产研资源利用率,当前功能刚提测,下一轮评审可能就来了,即一波赶一波。目前在我的团队,工作流以这个思想为前提稍加了改造,如图:

关于CI部署方面,统一走Tag事件,避免不小心合并到主分支导致提前发布

另外

gitlab flow倡导的上游优先策略不仅有能适应不同开发环境的弹性,也有单一分支管理的简单和便利。不过个人感觉没有前两种来的爽快…维护成本也不低。所以具体用哪种,还是综合下来看场景

合并小插曲

快速合并(Fast Forward)

常规合并(–no-ff)


sourceTree图可以看到,如果执行快速合并,开发者根本不会看到被合并的分支,就像在当前分支直接commit一样

正常合并如果没有合并冲突,都会进行快速合并。但是对于大多数功能驱动式项目开发来说,要尽量避免快速合并,毕竟有些时候还是要追溯log,不仅对于代码分析特别有用,另外保证整个项目提交链的完整性也很有必要

日志管理策略

起因

某次项目质量管理时发现了如下图这样的提交…一个修bug的操作,commit却密集的提交了7次之多

git日志过于随意会有什么问题?也许你会说代码写对、项目正常跑不就完了呗,何必纠结那些细节。但如果意识到以下问题,可能你就不这么想了:

  • 正常运行的功能出问题,要回滚代码到某个改动前或者查哪个改动引起的问题
  • Code review,试想一些很小的改动,却多次无效提交,一个个看会不会崩溃
  • 提取迭代的记录(CHANGELOG)做某项总结,结果发现这段时间都TM干了些啥
  • 破窗效应,分支污染将导致恶性循环,对往后的管理和维护是在埋雷

策略

此模块包含以下两个部分

  • commit lint:用于在提交前检查commit message是否符合规范
  • commit tool:帮助我们简便生成符合规范的commit message

具体用法教程太多,比如这个帖子:https://juejin.im/post/6844903710112350221

逼格

如果想在日志里做点骚操作,可以考虑emoji。要实现这个你需要关注两个库:gitmojiemojify

库安装好以后,在项目根目录执行:gitmoji -i,用来加git钩子,使得commit时可以弹出交互式moji对话框。另外配合zsh增加别名,让git log色彩斑斓

1
alias gl="git log --color | emojify | less -r"

参考资料