一、Git 规范的必要性
既然认同需要一份 Git 规范，那么这个规范需要规范哪些内容，解决哪些问题
分支管理
代码提交在应该提交的分支
随时可以切换到线上稳定版本代码多个版本的开发工作同时进行
提交记录的可读性
准确的提交描述，具备可检索性
合理的提交范围，避免一个功能就一笔提交
分支间的合并保有提交历史，且合并后结果清晰明了避免出现过多的分叉
团队协作
明确每个分支的功用，做到对应的分支执行对应的操作
合理的提交，每次提交有明确的改动范围和规范的提交信息使用 Git
管理版本迭代、紧急线上 bug fix、功能开发等任务
二、分支管理
分支命名
master 分支
master 为主分支，主分支，永远处于稳定状态，对应当前线上版本
以 tag 标记一个版本，因此在 master 分支上看到的每一个 tag 都应该对应一个线上版本
master
分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码不允许在该分支直接提交代码
develop 分支
develop 为开发分支，始终保持最新完成以及bug修复后的代码,
包含了项目最新的功能和代码， 所有开发都依赖 develop 分支进行
一般开发的新功能时，feature分支都是基于develop分支下创建
小的改动可以直接在 develop 分支进行，改动较多时切出新的 feature 分支进行
推荐的做法: develop
分支作为开发的主分支，也不允许直接提交代码。小改动也应该以 feature
分支提 merge request 合并，目的是保证每个改动都经过了强制代码
review，降低代码风险
feature 分支
分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、
feature/cart_module
开发新功能时，以develop为基础创建feature分支
开发新的功能或者改动较大的调整，从 develop 分支切换出 feature
分支，分支名称为
开发完成后合并回 develop 分支并且删除该 feature/xxx 分支
release分支
发布分支，新功能合并到 develop 分支，准备发布新版本时使用的分支, 预发布
发布之前发现的 bug 就直接在这个分支上修复，确定准备发版本就合并到 master 分支，完成发布，同时合并到 develop 分支
当有一组feature开发完成，首先会合并到develop分支，当 develop
分支完成功能合并和部分
bug
fix，准备发布新版本时或者进入提测时，会创建release分支如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线
hotfix 分支
分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
当线上版本出现 bug 时，从 master 分支切出一个 分支，完成 bug 修复，然后将
合并到 master 和 develop 分支(如果此时存在 release 分支，则应该合并到
release
分支)，合并完成后删除该 分支
以上就是在项目中应该出现的分支以及每个分支功能的说明。
其中稳定长期存在的分支只有 master 和
develop
分支，别的分支在完成对应的使命之后都会合并到这两个分支然后被删除。简单总结如下：
master 分支: 线上稳定版本分支
develop 分支: 开发分支，衍生出 feature 分支和 release 分支
release 分支: 发布分支，准备待发布版本的分支，存在多个，版本发布之后删除
feature 分支: 功能分支，完成特定功能开发的分支，存在多个，功能合并之后删除
hotfix 分支: 紧急热修复分支，存在多个，紧急版本发布之后删除
三、Git日志规范
四、分支提交操作建议
分支间操作注意事项
在团队开发过程中，避免不了和其他人一起协作，同时也会遇到合并分支等一些操作，这里提交
2 个个人觉得比较好的分支操作规范。
同一分支 使用 rebase
默认的
行为是 merge，可以进行如下设置修改默认的
行为：
不要在公共分支使用rebase
本地和远端对应同一条分支,优先使用rebase,而不是merge 关于使用rebase 还是
merge
git rebase
git merge
个人推荐大家开发的时候，尽量及时rebase上游分支（我习惯是每周merge一次），有冲突提前
就fix掉，即使我们自己的分支开发了很久（哪怕是几个月），也不会积累太多的conflict，最后合并进主分支的时候特别轻松，
非常反对从master
check出新分支，自己闷头开发几个月，结果最后merge进主分支的时候，一大堆冲突，自己还嗷嗷叫的行为
尽量及时rebase上游分支，发现有冲突，merge
分支冲突解决建议
- 首先使用git status
分析原因，是哪个文件出现了冲突，可以使用文本编辑器打开该文件。冲突产生后，冲突文件会显示以下标记<<<<<<<
与======= 之间是本地修改的内容， ======= 与
>>>>>>> 之间是远程修改的内容。
根据这个，对冲突文件进行编辑，在修改完之后，
重新commit以下就可以了
- 如果我们确定远程的分支正好是我们需要的，而本地的分支上的修改比较陈旧或者不正确，那么可
以直接丢弃本地分支内容，运行如下命令(看需要决定是否需要运行git
fetch取得远程分支)： - 如果我们觉得合并以后的文件内容比价混乱，想要废弃这次合并，回到合并之前的状态，那么可以
运行如下命令：
rebase过程中出现的冲突
在rebase的过程中，也许会出现冲突(conflict).
在这种情况，Git会停止rebase并会让你去解决 冲突；
在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行
git-commit,只要执行:
这样git会继续应用(apply)余下的补丁
在任何时候，你可以用--abort参数来终止rebase的行动，并且"mywork"
分支会回到rebase开始前的状态。
五、最佳实践
设置好自己的提交用户名和邮箱
新功能重新建立功能分支
当您继续开发功能分支时，请经常根据master 分支对其进行重新设置。
这意味着要定期执行以下步骤，
这些步骤会在功能分支中重写历史记录 （这不是一件坏事）。
首先，它使您的功能分支看起来像master 并进行了所有更新以达到master 要求。
然后，您对功能分支的所有提交都会在顶部重放，因此它们会顺序出现在Git日志中。
您可能会在一路上遇到需要解决的合并冲突，这可能是一个挑战。
但是，这是处理合并冲突的最佳方法，因为它只会影响功能分支。
解决所有冲突并进行回归测试之后，如果准备好将功能部件合并回master
，请再执行一次上述变基步骤，然后执行合并，
在此期间，如果其他人推动更改以master 与您的冲突，则Git合并将再次发生冲突。
您需要解决它们并重复进行回归测试
使用标签
完成测试并准备从master
分支部署软件后，或者如果出于其他任何原因想要将当前状态保留为重要的里程碑，请创建Git标签。分支积累与提交相对应的更改历史记录时，标签是该时刻分支状态的快照。
可以将标签视为无历史记录的分支，也可以将其视为指向创建标签之前特定提交的命名指针。配置控制
是关于在各个里程碑保留代码状态。
能够复制任何里程碑的软件源代码，以便在大多数项目中都可以在需要时进行重建。
Git标签为此类代码里程碑提供了唯一的标识符。 标记很简单：
考虑一种方案，其中与给定Git标签相对应的软件已分发给客户，并且客户报告了问题。
尽管存储库中的代码可能会继续发展，但通常需要回到与Git标签相对应的代码状态，以准确地再现客户问题以创建
错误修复程序。 有时，较新的代码可能已经解决了该问题，但并非总是如此。
通常，您需要签出特定标签并从该标签创建分支：
