目录
规则二，通过合并feature分支，形成release分支。
规则三，发布到线上正式环境后，合并相应的release-prod分支到master分支，在master分支上打上tag，同时删除关联的feature分支。
3.1在maven管理的项目中snapshot和release版本
3.1.1 snapshot是快照版本，代表不稳定和开发中的版本。
一、git分支管理
1、master
master分支为主分支，每次提交，
master分支都会向前新增一个节点，这样，随着不断提交，master分支也会越来越长。此分支不可删除，也不可随便提交。此分支一般由技术负责人管理该分支，是长期分支。
2、release
release-dev
release-dev分支为开发环境分支。
随着前后端分离和微服务盛行，虽然带了低耦合高内聚的好处，同时也引来了前后端接口对接问题、微服务和微服务间调用问题。
1、我们可以从master拉一个release-dev出来，各自后端开发人员开发完功能之后直接合并到release-dev，然后通知前端或者app开发人员对接接口（目前有了swagger之后接口对接也表现的比较友好，只要接口文档写的标准规范，可以减少很多沟通成本，当然接口评审也是大大减少返工的风险）。
2、如果前端发现接口有问题，直接把请求参数发给后端开发，让他本地调试，前端开发还可以直接对接其他可用的接口，也是可以提高一些产能，降低上线风险。
3、问题修复之后，后端开发可以合并到release-dev，重新发布，验证。
如果采用K8S，各个开发分支隔离，对降低分支合并冲突、各个业务相互影响启动很大的作用。所以次分支可以为长期分支也可以是短期分支，视公司情况而定
此分支一般由开发人员管理该分支。
release-test
release-test分支为测试分支。
当开发成员在开发环境对接完成，并且自测通过之后，可以提交请求合并到release-test分支，先经过技术负责人进行Code Review，通过后提交给测试，合并完成之后，发布到测试环境。
此分支一般由测试管理该分支。
release-prod
release-prod分支为uat环境分支，或者线上分支。一般都是从master 来取出最新分支，然后和业务分支合并完成，最后测试进行回归测试。
此分支一般由技术负责人管理该分支和模块的版本。
3、feature/hotfix
feature
feature分支为功能分支，在新版本开发和演进作用。该分支都是从master分支拉取出的最新分支，然后经过测试上线合并到master之后，在master打tag表明所有新功能开发完毕，最后删除该分支。
此分支是临时分支，一般由业务开发负责人和可以是开发人员创建，最终由技术负责人销毁。
例如：
feature-s1/xxx-index
feature-{迭代信息sprint1的简写}/{开发成员名字代号}-{description}
有些一个迭代拆分的比较详细的可以分成多个分支最终一个个合并上线
feature-s1/xxx-index、feature-s1/xxx-department、feature-s1/xxx-role
hotfix
hotfix分支为bug分支，用来修复主线master的bug。
切记，修复bug需要把长期分支都一起合并了了，不然之后需要rebase，就很麻烦了。
例子：
hotfix-ttt-xxx
hotfix-{开发成员名字代号}-{description}
二、git分支策略
规则一，开始工作前，从master创建feature分支。
规则二，通过合并feature分支，形成release分支。
规则三，发布到线上正式环境后，合并相应的release-prod分支到master分支，在master分支上打上tag，同时删除关联的feature分支。
一般项目打tag时，名称v0.1.1,描述的时候最好记录，迭代版本，已经简短的需求描述，助于后期的版本管理
三、 版本管理
git分支测试目前渐渐已经趋于平稳，和分支对应的版本也是开发项目中不可忽视的。
3.1在maven管理的项目中snapshot和release版本
3.1.1 snapshot是快照版本，代表不稳定和开发中的版本。
例如：
<dependency> <groupId>com.xxx.xx</groupId> <artifactId>discovery-common</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> 【所属环境】：SNAPSHOT版本一般在本地开发、开发环境、测试环境中出现，适用jar包不断更新的环境下。 【操作一】deploy时版本号一直不变，私服仓库jar包名会自动追加最新时间为版本号。 【操作二】使用jar包时IDE会自动下载最新的jar包，每种IDE会有不同的方式 【优点】在微服务开发环境下，在同一个迭代中A和B员工引用了C员工的c.jar包，c.jar 不时更新新的功能，多人协助下如果没有使用SNAPSHOT版本，A和B员工会经常出现无法及时更新jar包引起的项目报错等情况。虽然有很多种解决办法，但是势必会造成协调和工作的不变。如果使用SNAPSHOT，C员工只需要开发和对接中，不时deploy新版本，就可轻松愉快的进行对接和协同工作了。
3.1.2 release也就是功能趋于稳定和可以发布的版本
每个环境的发布，我们都必须把关联的jar保desploy到我们的maven仓库里面，maven仓库一般分为快照仓库和生产仓库。快照仓库也就是SNAPSHOT版本可以不限次数一直上传，生产仓库一般设置成制品不允许覆盖模式。所以测试完成之后打算发布到UAT环境的jar包，一个版本只能允许推送一次到生产仓库里面，如果在UAT环境发现bug（需要修改引用jar包时），我们一般可以升一个小版本然后重新发布到UAT环境。
最终如果UAT测试成功之后，发布到正式环境。
现阶段大部分都是使用docker容器发布项目，一般uat会把镜像上传到私服保存，如果测试通过，线上直接拉取镜像，发布到线上。
【小技巧】由于现阶段大部分项目都是微服务类型，涉及jar包引用比较复杂，我们可以先把所有的jar包打包好，然后再一个个发布服务，这样服务发布也不会出现优先级的问题了。
3.2版本号规约x.x.x
我们一般把版本分层三部分：主版本、次版本（迭代版本）、小版本
3.2.1主版本
主版本一般是由于重大升级，或者本版本不再维护会升级的一个版本，一般升级之后会有一个革命性的胜利。还有一些公司每一年升级一个大版本，主要还是看各个公司自己的方式，一个项目历经一年，也算是重大胜利了。
3.2.2次版本（迭代版本）
次版本也称为迭代版本，一般一个迭代生一个版本。
3.2.3小版本
小版本主要是线上bug类，或者无法成为一个迭代的功能提交（临时上线小功能），可以升级一个版本。
四、开发过程
背景：目前项目版本：0.5.3
1、产品创建一个迭代spint 10
2、开发从master拉取一个future-s10/zs-risk
3、确定一个版本0.6.0
4、需要修改的jar包版本都修改成0.6.0-SNAPSHOT并通知需要引用的开发人员、其他服务型项目直接0.6.0-SNAPSHOT版本就可以了
5、后端小伙伴开发完成之后
6、从master拉取一个release-dev分支或者重master rebase到release-dev分支
7、future-s10/zs-risk合并到release-dev分支，然后发布，通知前端可以对接了
8、前后端对接完，自测通过后，进行提交合并release-test请求
9、技术负责人（也可以多人code review）审批通过之后，提交给测试（中间如果有合并问题，开发人员自己解决）
10、测试合并分支之后，运维根据发布需求（很多公司测试直接发布也行，看约定），发布项目。
11、测试完成
12、技术负责人重最新的master拉一个release-prod，从 master 上拉取的时候 master 可能已经有其他需求上线了，release-prod 合并相关 feature 分支后需要进行回归测试
13、测试完成之后直接发布上线
14、线上没有问题之后，release-prod直接合并到master 然后打一个tag，最终删除关联分支
每家公司开发模式大大小小都有差别，不必生搬硬造，符合本公司就可以了。之后如果有空，给大家讲讲k8s相关的方式，稍微有点区别，大部分都差不多。
最后说一句，一切的规范只是为了减少大家的出错和返工，也是为了提高团队的效率。
参考文章：
243
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
