Git提交规范流程和解决冲突实际使用

前言：GIT对于我们程序员来说是吃饭的工具，本篇主要是针对提交和分支以及对于大多数程序员闻风丧胆的冲突一些个人见解，如果有啥不对的或者你们公司git提交流程欢迎下方评论。

在讨论规范之前，我们需要定最基本的要求

1.团队内保持良好的代码格式便于易读和维护，最主要减少不必要的代码冲突（建议统一使用开发工具（idea）的代码格式化）。

2.提交任何代码必须确认代码可运行

3.提交的代码必须移除无用的包路径引用和无用的依赖，尽量不要使用过期的方法或者类

1 . commit message规范

规范格式:

<type>: <subject>

**type  **

• feature: 新功能（feature）
• fix: 修补bug、style等
• refactor: 重构（即不是新增功能，也不是修改bug的代码变动）
• test: 增加测试 chore: 构建过程或辅助工具的变动

subject

提交目的的简短描述，描述做了啥或者改了啥，如果有团队管理工具(issue ,JIRA)或者产品需求，必须以内部命名的需求代号作为描述信息的一部分，方便查看日志，合并和cherry-pick。

举例：

1. feature:开发完成#代号 XXX.XXX需求
2. fix:修改 #代号 XXXX查询问题

2. 提交规范以及GIT开发流程

**Git分支 **

1. master        （生产环境）    部署某个uat功能到准生产的时候合并到master，只允许uat分支合并/cherry-pick。
2. uat              （测试环境）    部署某个feature分支到测试的时候合并到uat，只允许feature分支合并。
3. feature/xxxx  (特性分支)      开发一个功能或者修改bug的时候合并/提交到feature
4. dev/xx           (本地开发版本)

在开发之前，需要在master分支上切一个以需求,BUG,重构.......命名feature分支 ，比如  feature/项目编号（BUG的代号）

2.1  本地没有项目，克隆代码的并切换到开发分支

克隆并在需要开发的feature分支上创建本地dev开发分支，本地分支可以以dev/自己标识的英文 命名。

git clone -b dev/xx  feature/项目编号

2.2  本地有项目，切换开发分支

为了避免本地分支与远程不一致，需要切换到 feature/项目编号分支，更新一下。

git checkout feature/项目编号

git pull

再在