GIT结合Maven对源码以及jar包的管理建设

一、GIT管理规范

1.1 git分支概念

develop分支

开发分支，不管是要做新的feature还是需要做bug修复，都是从这个分支分出来做。

在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本。

feature-*-*分支

feature-姓名-功能描述

feature分支与开发任务一一对应。

对每一次迭代中的每一个原子的功能点，根据任务会由负责的开发人员以develop分支建立对应的feature分支进行处理，当功能点开发自测完毕之后，就将feature分支合并到develop分支去。

feature分支都是临时的分支，合并回develop后即删除

test分支

当一个迭代的代码都开发完毕，需要开始测试时，需要把develop的代码合并到test分支，用test分支代码构建测试环境，进行测试。

测试阶段的代码修复，由负责人以develop分支创建对应的feature-*-*分支，进行代码修复，然后依次合并到develop、test分支上，进行回归测试。

master分支

测试环境测试完毕，代码评审完成后，test分支代码合并到master分支，并且根据版本，创建对应的版本tag。

master分支的代码一直是稳定可产品化发布的状态。

hotfix-*-*分支

hotfix-姓名-修复内容

这个分支系列用于紧急线上修复，当生产环境中出现bug，且特别紧急需要立即解决的时候，就可以从master分支建立一个hotfix分支，进行紧急修复，修复完成后分别并入master和develop以及test分支。

Hotfix分支是临时的分支，合并到develop、test、master后即删除

1.2 版本Tag

原则上，一旦形成了tag，则不允许更改该tag的代码，即使里面有bug，修复的代码应该重新生成tag。

正常的稳定代码的tag命名规则为release-x.x.x，而热修复代码的tag命名规则为release-x.x.x-rcx。

假设当前版本为1.0.0，那么release的代码tag应为release-1.0.0，在此release-1.0.0的tag上hotfix的代码，应该生成release-1.0.0-rc1的tag，在release-1.0.0-rc1的tag上hotfix的代码，应该生成release-1.0.0-rc2，依此类推。

二、maven仓库建设

2.1 Maven中央仓库

使用Nexus搭建自己的中央仓库；
Nexus优势：

1. 加速构建
2. 节省带宽
3. 节省中央maven仓库的带宽
4. 稳定（应付一旦中央服务出问题的情况）
5. 控制和审计
6. 能够部署第三方构件
7. 可以建立本地内部仓库和公共仓库
8. 开箱即用，不需要数据库
9. 占用较少的内存，基于简单文件系统而非数据库

这些优点使得Nexus日趋成为最流行的Maven仓库管理器。

2.2 Maven版本管理

Maven有SNAPSHOT版本的概念，它与release版本对应，后者是指1.0.0，1.1.0，2.0.0这样稳定的发布版本。

项目到一个阶段后，就需要发布一个正式的版本（release版本）。

从1.0.0-SNAPSHOT到1.0.0到1.1.0-SNAPSHOT

1. 测试完成封版后，更新pom版本从1.0.0-SNAPSHOT到1.0.0
2. 对1.0.0打一个 git tag
3. 针对tag进行mvn deploy，发布正式版本到Maven中央仓库
4. 更新develop的pom版本，从1.0.0到1.1.0-SNAPSHOT

这些步骤可以手工一步步操作，也可以使用Maven组件：Maven Release Plugin 进行自动化操作。

https://blog.youkuaiyun.com/davidullua/article/details/127214124 介绍了Maven Release Plugin插件的使用方法。

2.3 Maven版本规则

{主版本号}.{次版本号}.{增量版本号}

例如版本号1.2.3，1是主版本号，2是次版本号，3是增量版本号；

• 主版本号：一般是指的当前的项目有了重大的架构变动，版本之间几乎完全不兼容。
• 次版本号：一般是指的项目的迭代版本，这种版本会修复大量的bug，带来一些小的新特性等，但是没有什么架构上的重大变化。
• 增量版本号：一般是用于修复一些紧急bug，改动量很小时，可以使用增量版本号。