为什么要做代码管理规范?
讲个小故事,王者荣耀或者英雄联盟都玩过吧。我们要gank(游戏中一个或几个的游戏角色行动,对对方的游戏角色进行偷袭、包抄、围杀)对面中单选手,于是约定策略为
- 我方中单负责勾引,牵扯住对方中单
- 我方打野埋伏在草丛,等待辅助过来
- 辅助选手从下路赶过来支援
如果各位选手按照策略进行会对敌方进行一波很好的击杀,但由于打野沉不住性子,在埋伏的过程中,去了对方野区反了波野怪被看到了位置。对面选手来了波反蹲,我方其它选手并不知情,毅然选择开战,结果可想而知被地方反杀。
代码管理也是一个多人合作的才能达到互利共生,这就需要有一个约定的策略,才能保证项目能能够顺利进行。
一、commit规范
规范的commit日志,能让人一眼扫出关键信息。坏的日志让人看的不明所以,一头雾水,特别是在需要代码回滚的情况下。曾经有个团队成员一直用以下方式提交,后来有一次她的代码需要回滚,这种日志的情况下,回滚了三四次都没有找到正确的节点。多次劝她无果,现在这位同事已经被公司接触劳动合同了。
Commit message 提交规范,包括type(必需) + subject(必需),提供更多的历史信息,方便快速浏览。可过滤某些信息(比如构建安装包);
#1 type
#主要type
feat:新功能
fix: 修补bug
#特殊type
docs:文档(document)
style:格式(不影响代码运行的变动)
refactor:重构(既不是新功能,也不是修改bug的代码变动)
test:增加测试
build:构造工具的或者外部依赖的改动,例如webpack,npm
chore: 不修改src或者test的其余修改,例如构建过程或辅助工具的变动
#2 subject
subject是 commit 目的的简短描述,不超过50个字符。
举例如下:
- 新增功能
- 修补bug
带来的好处:
• 可读性好,清晰,不必深入看代码即可了解当前commit的作用。
• 为 Code Reviewing做准备
• 方便跟踪工程历史
• 让其他的开发者在运行 git blame 的时候清晰明了
• 提高项目的整体质量,提高个人工程素质
二、分支管理规范
分支管理规范。
- 当前任务开发分支为develop分支,develop作为开发分支以及提测分支使用。如有新的上线需手动将master分支代码合并到develop分支
- develop分支测试通过,从develop切到当前版本分支比如:v2.0(下面都以v2.0举例),用v2.0作为预发分支以及上线分支。
- v2.0在预发环境测试通过后,可直接作为上线分支上线。
- v2.0分支上线成功之后,需合并到master分支
- 线上bug修改,修复v2.0的线上bug,可切新的分支v2.1,依次累加等。
git分支管理流程图如下:
三、总结
好的Git管理方法,能极大的提高团队工作效率,避免提交错乱。
参考:https://www.processon.com/diagrams/new#template
如有问题请联系我~
欢迎加入QQ群: