前端规范与思考(五)—— git规范

本文属于原创文章,转载请注明–来自桃源小盼的博客

提交信息模板

1
2
3
类型(范围):主题(最多50个字)
解释为什么要做这些改动
提供相关文章和其它资源的链接和关键字

类型说明:

  • feat (新特性)
  • fix (bug修复)
  • remove(删除特性)
  • docs (文档改动)
  • style(格式化, 缺失分号等)
  • refactor (重构代码)
  • test (添加缺失的测试,重构测试)
  • chore (构建任务等)

范围说明:

一般指页面或模块

提交信息示例:

1
2
feat(顶栏):增加用户头像
refactor(底栏):函数set重命名为setTitle

优秀的提交信息,能让我们查看历史提交时,能更容易和更快速的理解做了什么。如果每次提交都写fix bug,相当于什么也没写,只是提供了一个类型值。

提交原子性

代码提交的原子性,是指一个提交包含一个不可分割的特性、修复或者优化,同时这个提交要尽可能小。

1. 以单个事情的角度提交的改动

建议:独立的功能点、模块、组件或修复bug等。

2. 每次提交保证可运行

没有人希望拉取了你的代码后运行报错。

3. 多人合作时,尽早提交,尽早拉取

这么做是为了降低代码冲突的问题。解决冲突一般来讲,既耗费人力也耗费时间。

分支

关于分支,每个团队的情况都不同,并不能一概而论。所以我们得根据自身的情况,来选择合适的git工作流,既不能太复杂难用,也不能简单到混乱,合适舒服就是最好的。

禁忌

  • 禁止推送主分支
  • 禁止使用git push -f

尽量在仓库里禁止以上行为

参考资料