版本項：

    maven工程 pom.xml

    git 的分支和tag

詳解：

    maven的版本管理，pom.xml 中的該包的版本號，主要是在打包后攜帶版本信息，以此，我們可以通過配置maven的snapshot版和release版的版本號使用deploy命令存儲版本包，如果是開發(fā)階段，那使用的版本為snapshot 版 如1.1-snapshot 如果是開發(fā)測試結(jié)束，則將版本改為release版。snapshot 為快照版本，release為正式版本

    git的版本管理，當一個版本結(jié)束后，我們既需要維優(yōu)分支來維護上一階段的任務，又需要開發(fā)新的功能，如果現(xiàn)網(wǎng)環(huán)境出現(xiàn)問題，我們不能將新功能升級上去，因為這部分功能屬于未完成階段。那我們就可以開出分支[維優(yōu)分支]，來維護上一階段的功能，到新功能完成后，將開發(fā)分支與維優(yōu)分支合并，升級現(xiàn)網(wǎng)。

我們的分支結(jié)構(gòu)為：

develop 分支，這是我們的開發(fā)分支，所有新功能的開發(fā)都在這個分支上。

master 分支，功能開發(fā)測試完畢合并到master分支，[該分支為備份作用，可以直接用該分支作為開發(fā)分支]

1.0.x分支 ,當1.0版本功能開發(fā)測試完成后，分離的分支，如果1.0版本有問題，可以直接切到該分支進行維護升級，維護的過程可以用git 創(chuàng)建tag作為一個階段的正式版本

1.2.x分支，當1.0版本功能開發(fā)測試完成后，分離的分支，如果1.0版本有問題，可以直接切到該分支進行維護升級，維護的過程可以用git 創(chuàng)建tag作為一個階段的正式版本

功能的開發(fā)測試階段使用 alpha->beta->rc->正式版 的順序來標識

alpha :內(nèi)測版,問題較多

beta:公測版，問題較少

rc:release candidate 發(fā)行侯選版本，已經(jīng)非常接近正式版只有少許bug

修改過程：

1. 在develop分支上開發(fā)1.0 版本，當開發(fā)完畢后，進入測試階段，如果功能較多，需要記錄標簽,如rc階段，修改pom.xml 文件將版本改為1.0.0-rc1,創(chuàng)建1.0.0-rc1的標簽，deploy包

2. 當1.0版本開發(fā)完，切出分支 1.0.x ,之后develop分支的pom.xml 改為1.1.0-snapshot，develop分支上開發(fā)1.1版本的功能。

3. 在1.0.x分支上，當維護一個階段需要打標簽，則先修改分支上pom.xml 的版本號為1.0.0 打標簽，再將pom.xml 文件的版本號改為1.0.1-snapshot 以此類推 當1.0.1-snapshot的過程開發(fā)完后，改pom.xml 為1.0.1 打標簽，deploy包，再將pom.xml的版本設(shè)置為下一版本為1.0.2-snapshot

4.當開發(fā)分支上的1.1 版本的功能開發(fā)完畢后，將1.0分支的功能合并到開發(fā)分支，測試成功，則為1.1版本切出分支1.1.x ，保存到master分支，1.2的功能繼續(xù)在開發(fā)分支上開發(fā)

*注:不管是開發(fā)分支還是維優(yōu)分支，打的tag中都為正式版本，而分支中都為snapshot 版本。當一個版本的功能完畢后，將pom.xml 的快照版本，設(shè)置為正式版本，打標簽，deploy包，然后再將pom.xml 的版本號設(shè)置為下個版本的快照版本。

通過以上過程，我們才能將每個階段的包保存，并且有tag記錄每個版本的信息

但是對于需要快速迭代的工程，每一個版本結(jié)束都要進行一次配置的更改，如果一天迭代幾百次，恐怕對于維優(yōu)團隊無疑是個沉重的負擔。

如果這些修改配置，deploy包，打tag都人工做，不光有特別多的工作量，還有失誤的風險，如何使其自動化處理，對于這個問題提供以下解決方案

1.