本文章讲解Git代码管理中团队应该遵守的一些规则，让大家可以愉快的一起开发工作。
本篇文章需要结合Git代码提交规范-实践篇 一起食用哟~

上一节我们已经讲了如何利用Gitee来实际操作团队开发流程，
那里面的一些细节我们还是要弄明白的，这里就是一些笔者工作过程中的一些总结和感悟，
大家可以一起讨论学习。

1. 分支的定义

分支名	含意
master	主分支，用来承载线上稳定大版本，多个版本需要打tag
dev	开发分支，顾名思义一直开发的分支，需要合并到master分支

基本上使用这两个版本就能够愉快的开发了，
但是项目越做越大就会衍生出：bugfix（专门修bug，在master基础上合并到dev和master）、release（发布用，基于dev，合并到dev/master）、feature（特性分支，基/合dev）
拓展资料：Git分支管理及命名规范
大体的开发流程如下图所示:

2. 约束

2.1 远程命名

【建议】远程命名要求：origin自己的远程代码仓，upstream上游仓(公司主仓)

2.2 拉取代码

【建议】为了不产生冲突，请开发之前先拉取上游仓代码

git pull upstream dev

2.3 新建Issues

【强制】开发之前，需要新建一个Issues，这样才能追溯需求，而且在合入的时候需要关联此Issues。
标题的前缀可选：【需求】、【bug】、【优化】、【测试】、【升级】、【技术】、【其他】
详情里面越详细描述越好，功能的，如果涉及到bug，将错误信息不要吝啬的贴上去。

2.3 代码规范

【强制】请自觉遵守公司开发规范或手册！
【强制】提交的修改行数不得超过1000行。
如下面所示，如果前期框架搭建、重构等涉及到超过1000行，需要评估后提交！

【强制】单个文件行数不得超过1000行。
一个js/java等文件，最大行数不要超过1000行，若超过需要拆分到不同作用域的文件去！

【强制】一个方法行数不得超过100行。
一个js、java方法、函数等不得超过100行，超过的话需要方法拆分出来。

2.4 MR提交

【强制】必须有前缀：【需求开发】、【bug修复】、【重构优化】、【测试】、【技术升级】
修改内容需要详细添加，尽量有图、流程图等。

【强制】提交MR不要涉及到多个commit
一个MR对应一个Commit。

以上就是开发过程中需要注意的一些点了，当然还是比较雏形的，后期如果遇到哪些问题在归纳总结。
如果其他网友有更好的或补充的方法论，欢迎大家留言讨论哟~~