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

发表于 更新于

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

前言

当下git对开发的重要性不必多言，如何让团队更好地使用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

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

参考资料