GIT代码仓库管理规范

为什么要做代码管理规范？

讲个小故事，王者荣耀或者英雄联盟都玩过吧。我们要gank(游戏中一个或几个的游戏角色行动，对对方的游戏角色进行偷袭、包抄、围杀)对面中单选手，于是约定策略为

1. 我方中单负责勾引，牵扯住对方中单
2. 我方打野埋伏在草丛，等待辅助过来
3. 辅助选手从下路赶过来支援

如果各位选手按照策略进行会对敌方进行一波很好的击杀，但由于打野沉不住性子，在埋伏的过程中，去了对方野区反了波野怪被看到了位置。对面选手来了波反蹲，我方其它选手并不知情，毅然选择开战，结果可想而知被地方反杀。
代码管理也是一个多人合作的才能达到互利共生，这就需要有一个约定的策略，才能保证项目能能够顺利进行。

一、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个字符。

举例如下：

1. 新增功能
2. 修补bug
   带来的好处：
   • 可读性好，清晰，不必深入看代码即可了解当前commit的作用。
   • 为 Code Reviewing做准备
   • 方便跟踪工程历史
   • 让其他的开发者在运行 git blame 的时候清晰明了
   • 提高项目的整体质量，提高个人工程素质

二、分支管理规范

分支管理规范。

1. 当前任务开发分支为develop分支，develop作为开发分支以及提测分支使用。如有新的上线需手动将master分支代码合并到develop分支
2. develop分支测试通过，从develop切到当前版本分支比如：v2.0（下面都以v2.0举例），用v2.0作为预发分支以及上线分支。
3. v2.0在预发环境测试通过后，可直接作为上线分支上线。
4. v2.0分支上线成功之后，需合并到master分支
5. 线上bug修改，修复v2.0的线上bug，可切新的分支v2.1，依次累加等。

git分支管理流程图如下：

三、总结

好的Git管理方法，能极大的提高团队工作效率，避免提交错乱。

参考：https://www.processon.com/diagrams/new#template

如有问题请联系我~

欢迎加入QQ群: