maven git 工程版本管理

版本项：

    maven工程 pom.xml

    git 的分支和tag

详解：

    maven的版本管理，pom.xml 中的该包的版本号，主要是在打包后携带版本信息，以此，我们可以通过配置maven的snapshot版和release版的版本号使用deploy命令存储版本包，如果是开发阶段，那使用的版本为snapshot 版 如1.1-snapshot 如果是开发测试结束，则将版本改为release版。snapshot 为快照版本，release为正式版本

    git的版本管理，当一个版本结束后，我们既需要维优分支来维护上一阶段的任务，又需要开发新的功能，如果现网环境出现问题，我们不能将新功能升级上去，因为这部分功能属于未完成阶段。那我们就可以开出分支[维优分支]，来维护上一阶段的功能，到新功能完成后，将开发分支与维优分支合并，升级现网。

我们的分支结构为：

develop 分支，这是我们的开发分支，所有新功能的开发都在这个分支上。

master 分支，功能开发测试完毕合并到master分支，[该分支为备份作用，可以直接用该分支作为开发分支]

1.0.x分支 ,当1.0版本功能开发测试完成后，分离的分支，如果1.0版本有问题，可以直接切到该分支进行维护升级，维护的过程可以用git 创建tag作为一个阶段的正式版本

1.2.x分支，当1.0版本功能开发测试完成后，分离的分支，如果1.0版本有问题，可以直接切到该分支进行维护升级，维护的过程可以用git 创建tag作为一个阶段的正式版本

功能的开发测试阶段使用 alpha->beta->rc->正式版 的顺序来标识

alpha :内测版,问题较多

beta:公测版，问题较少

rc:release candidate 发行侯选版本，已经非常接近正式版只有少许bug

修改过程：

1. 在develop分支上开发1.0 版本，当开发完毕后，进入测试阶段，如果功能较多，需要记录标签,如rc阶段，修改pom.xml 文件将版本改为1.0.0-rc1,创建1.0.0-rc1的标签，deploy包

2. 当1.0版本开发完，切出分支 1.0.x ,之后develop分支的pom.xml 改为1.1.0-snapshot，develop分支上开发1.1版本的功能。

3. 在1.0.x分支上，当维护一个阶段需要打标签，则先修改分支上pom.xml 的版本号为1.0.0 打标签，再将pom.xml 文件的版本号改为1.0.1-snapshot 以此类推 当1.0.1-snapshot的过程开发完后，改pom.xml 为1.0.1 打标签，deploy包，再将pom.xml的版本设置为下一版本为1.0.2-snapshot

4.当开发分支上的1.1 版本的功能开发完毕后，将1.0分支的功能合并到开发分支，测试成功，则为1.1版本切出分支1.1.x ，保存到master分支，1.2的功能继续在开发分支上开发

*注:不管是开发分支还是维优分支，打的tag中都为正式版本，而分支中都为snapshot 版本。当一个版本的功能完毕后，将pom.xml 的快照版本，设置为正式版本，打标签，deploy包，然后再将pom.xml 的版本号设置为下个版本的快照版本。

通过以上过程，我们才能将每个阶段的包保存，并且有tag记录每个版本的信息

但是对于需要快速迭代的工程，每一个版本结束都要进行一次配置的更改，如果一天迭代几百次，恐怕对于维优团队无疑是个沉重的负担。

如果这些修改配置，deploy包，打tag都人工做，不光有特别多的工作量，还有失误的风险，如何使其自动化处理，对于这个问题提供以下解决方案

1.