### 一、前言 Git是我们每日工作中都会接触到的工具。它给我们带来了极大的便利，但随之而来的也在团队中使用出现了各式各样的风格，这些风格我们并不认为它是错的，只能说不太适合现在日益壮大的团队。团队的壮大也有我们每一个人的汗水，希望各位能尽量遵循现有规范，达到log日志语义化，分支名称标准化。谢谢 ***** ### 二、Git日志格式规范 `{type}: {subject}` - type ：表示提交信息的类型，具体为一下可选项中的任意一种： | 可选项 | 含义 | | --- | --- | | feat | 添加功能 | | fix | 修复bug | | opt | 优化功能 | | merge | 合并代码 | - subject ：表示提交的内容，中英文均可，**建议中文** - 例子：🌰  上面的例子我们对`yarn.lock`文件进行了修改，假设我们这是一个需求，就是在这个文件中添加空格，那么我们提交时log日志便是这样的：`git commit -m "feat: 添加空格"`，其中`feat`代表我们此次提交的类型为**新增**，而`：`后面便是我们对此次提交的说明。 ***** ### 三、Git分支格式规范 `{type}-{id}-{task}-{createTime}` - type ：表示分支的类型，具体为一下可选项中的任意一种： | 可选项 | 含义 | | --- | --- | | feat | 添加功能 | | fix | 修复bug | | opt | 优化功能 | | merge | 合并代码 | - id ：表示`需求id`，此id可以去`禅道上查看（需求前面的数字）`：  - task ：表示`需求名称`，名称使用**驼峰方式连接** - createTime ：分支创建的时间，以当前时间为例：`190415`代表着19年4月15日 - 例子：🌰 以上面提到的id为`013`的需求为例，我们试着创建一个分支： `feat-013-salesBonus-190415`，这样我们的分支就建立好了。so easy ***** ### 三、代码合并规范 写在最后也是最为严重的问题。合并代码对其他人代码的覆盖以及部分的**丢失**问题比较**严重**，所以我们`merge`代码时如果遇到冲突一定要找到和你冲突的人**面对面**进行解决。提交前需对修改代码进行`diff`后在提交。尽量避免此类问题再次出现在团队中。这样大家辛苦工作的成果也不会因为这类意外而**付之东流**。