GIT 是目前用得最多的也是最好用的合作开发工具。记得最开始工作的时候由于 GIT 用的很不熟练导致增加了很多工作量，关于 GIT 的使用教程网上有很多，这里记一下一个完整的使用 GIT 进行合作开发的体系。
GIT 分支
合理利用分支的命名可以更高效的进行代码的管理，一个合理的多人开发的项目，分支主要根据场景进行命名。
主要的分支为：master 、develop （dev）、release 、hotfix（bug）
- master 分支——为主分支，也是用于部署生产环境的分支，需要确保 master 分支的稳定性。master 分支一般由 develop 以及 hotfix 分支合并，处于安全考虑，任何时间都不能直接修改 master 分支上的代码
- develop 分支——开发分支，可以简写为 dev 分支。始终保持最新完成以及 bug 修复后的代码。一般开发新功能时，feature 分支都是基于 develop 分支下创建的
- feature 分支——开发新功能时，以 develop 为基础创建 feature 分支。分支命名：feature/ 功能名， 命名规则：feature/user_module、 feature/cart_module
- release 分支——为预上线分支，发布提测阶段，release 分支代码为基准提测
- hotfix 分支——为修复分支，它的命名规则与 feature 分支类似。线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支
完整的流程：
- 项目会有一个 master 分支，用于线上运行。dev 分支，用于测试环境运行。
- 当有新功能需求时，以 develop 为基础根据需求创建 feature 分支，如增加权限验证：feature/add_auth，开发自测完成后合并入 dev 分支
- 进入提测阶段，以 dev 分支为基础创建 release 分支，如果测试过程中若存在 bug 需要修复，则直接由开发者在 release 分支修复并提交。当测试完成之后，合并 release 分支到 develop 分支，合并 develop 分支到 master 分支。此时master为最新代码，用作上线。
- 若某时发现系统存在 bug，需要及时修复，以 master 分支为基础创建 hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支。
日志规范
在一个团队协作的项目中，开发人员需要经常提交一些代码去修复 bug 或者实现新的 feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范 commit messages 编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。
编写良好的 Commit messages 可以达到 3 个重要的目的：
-
加快 review 的流程
-
帮助我们编写良好的版本发布日志
-
让之后的维护者了解代码里出现特定变化和 feature 被添加的原因
目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。如下图：
Commit messages的基本语法
当前业界应用的比较广泛的是 Angular Git Commit Guidelines。
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines
具体格式：
<type>: <subject> <BLANK LINE> <body> <BLANK LINE> <footer>
type: 本次 commit 的类型，诸如 bugfix、 docs、 style 等
scope: 本次 commit 波及的范围
subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点：
-
使用祈使句
-
首字母不要大写
-
结尾无需添加标点
body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |
footer: 描述下与之关联的 issue 或 break change
# 标题行：50个字符以内，描述主要变更内容 # # 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括: # # * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等 # * 他如何解决这个问题? 具体描述解决问题的步骤 # * 是否存在副作用、风险? # # 如果需要的化可以添加一个链接到issue地址或者其它文档
Type的类别说明：
- feat: 添加新特性
- fix: 修复bug
- docs: 仅仅修改了文档
- style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
- refactor: 代码重构，没有加新功能或者修复bug
- perf: 增加代码进行性能测试
- test: 增加测试用例
- chore: 改变构建流程、或者增加依赖库、工具等