版本項：

    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.