1 項目版本管理控制流程規范的好處
1. 保證各個環境（開發、測試、生產、主干）的獨立，避免相互影響
2. 各個環境的職能更明顯，開發分支只負責開發，測試分支只用於測試，各司其職，提高開發和測試的效率
3. 多個版本，多次合並，便於追溯問題
4. 開發版本沒有問題才會合並到測試版本，測試版本沒有問題才會合並到生產版本，每次的合並都盡量的確保了代碼的正確性，提高軟件版本穩定性，
5. 減少最終發布時合並主干出現沖突的概率
6. 降低沖突處理的難度
2 項目版本管理控制流程規范
2.1 項目版本管理控制流程圖
2.2 基本流程介紹
- 2.2.1 需求A的開發發版流程
**節點1** 每個項目都有一個主分支 Master，它是一個穩定的可用版本，Master 上的每個版本就是拿來可以用的對應版本號的發布版本，Master 是不允許隨意改動的
**節點2** 開發人員A拿到一個具體需求A（新模塊或異常修復），從 Master 唯一新建分支DevelopA，並進行開發
**節點3** 開發人員A完成分支DevelopA后，從Master分支上新建唯一SIT分支，將DevelopA分支合並到該SIT分支進行集成測試，此時由測試人員A對SIT分支上的需求A進行測試**（集成測試）**
**節點4** 經過SIT測試發現A沒有問題，從Master分支上新建唯一UAT分支，將DevelopA分支合並到UAT分支，進行驗收測試，此時由業務人員A對UAT分支上的需求A進行測試**（用戶驗收測試）**
**節點5** 經過UAT測試發現A沒有問題，從Master分支上新建唯一Master_1分支，將DevelopA分支合並到Master_1分支，初步發布生產版本，投入使用檢查新版本的穩定性
**節點6** 經過一段時間（大概一周），生產上的版本趨於穩定，經過確認沒有問題，則將DevelopA分支合並到Master分支作為功能的最后輸出
- 2.2.2 需求A測試過程接到需求B的開發發版流程
**節點7** 在需求A進行節點2到節點6（測試）的全過程，開發人員B拿到一個新的具體需求，從 Master 唯一新建分支DevelopB，並進行開發
**節點8** 開發人員B完成分支DevelopB后，則將DevelopB分支合並到**現有SIT分支**，進行集成測試，此時由測試人員B對SIT分支上的需求B進行測試
**節點9** 經過SIT測試發現B沒有問題，則將DevelopB分支合並到**現有UAT分支**，進行驗收測試，此時由業務人員B對UAT分支上的需求B進行測試
**節點10** 經過UAT測試發現B沒有問題，則將DevelopB分支合並到**現有Master_1分支**，初步發布生產版本，投入使用檢查新版本的穩定性
**節點11** 經過一段時間（大概一周），生產上的版本趨於穩定，經過確認沒有問題，則將DevelopB分支合並到Master分支作為功能的最后輸出
2.3 注意事項
1. 每一個分支都是**以Master分支為源**分支進行新建，再進行修改或者合並操作的
2. **代碼的開發和修改只能使用源需求分支**：
需求的開發或者測試過程發現問題而對代碼的改動，**只可以從需求分支上進行修改**
開發人員需要對該分支的代碼本地進行自測，確保分支能運行跑通，才可以合並到SIT分支上進行測試
3. **代碼的合並只能使用源需求分支**：
不能直接將SIT分支合並到UAT分支
不能直接將UAT分支合並到Master_1分支
不能直接將Master_1分支合並到Master分支
因為SIT、UAT、Master_1分支上同時存在着多個需求進行測試，如果將SIT、UAT、Master_1分支作為源代碼合並到目標分支，那也會將尚未完成測試的其他需求的代碼合並到目標分支，這樣會影響到目標分支代碼的正確性和穩定性
4. SIT分支，UAT分支，Master_1分支，是測試人員和業務人員用來測試需求完成情況的分支：
測試過程發現問題，**不能直接對該測試分支進行修改**，需要通知開發人員，由開發人員對源需求分支進行修改
5. Master分支是用於輸出穩定代碼版本的分支：
只有當代碼經過生產驗證，趨於穩定才可以合並到Master分支上
6. 在SIT測試節點、UAT測試節點、檢查功能穩定性節點：
凡是測試中發現某個需求未完成要求或者出現相關bug，則需要從該問題所對應的需求分支上進行修改（從源頭需求節點），然后按照流程規范的順序**重頭開始**進行發版測試，不可以直接修改發現問題的節點
3 發版流程控制案例
下面使用IDEA，以一個簡單案例對發版流程控制進行介紹
3.1 需求A的開發發版流程
- 3.1.1 節點1 初始版本
每個項目都有一個主分支 Master，它是一個穩定的可用版本，Master 上的每個版本就是拿來可以用的對應版本號的發布版本，Master 是不允許隨意改動的
場景模擬：現在假設Master分支上有文件index.jsp,內容如下
- 3.1.2 節點2 需求A的開發
開發人員A拿到一個具體需求A（新模塊或異常修復），從 Master 唯一新建分支DevelopA，並進行開發
場景模擬：開發人員A拿到需要A，需要着手開發
3.1.2.1 從Master新建需求A分支
3.1.2.2 在需求A分支上進行代碼的開發
- 3.1.3 節點3 需求A的SIT測試
開發人員A完成分支DevelopA后，從Master分支上新建唯一SIT分支，將DevelopA分支合並到該SIT分支進行集成測試，此時由測試人員A對SIT分支上的需求A進行測試（集成測試）
場景模擬：開發人員A完成需求A的開發，要發布SIT版本供測試人員A測試
3.1.3.1 從Master新建SIT分支
3.1.3.2 將需求A分支合並到該SIT分支進行測試
在SIT分支上，對需求A分支的代碼改動進行合並：
合並完成的結果：
代碼合並完成，發布SIT測試版本，由測試人員A對需求A的完成情況進行測試
- 3.1.4 節點4 需求A的UAT測試
經過SIT測試發現A沒有問題，從Master分支上新建唯一UAT分支，將DevelopA分支合並到UAT分支，進行驗收測試，此時由業務人員A對UAT分支上的需求A進行測試（用戶驗收測試）
場景模擬：測試人員A完成需求A的測試，要發布UAT版本供業務人員A測試
3.1.4.1 從Master新建UAT分支
3.1.4.2 將需求A分支合並到該UAT分支進行測試
在UAT分支上，對SIT分支的代碼進行合並：
合並完成的結果：
代碼合並完成，發布UAT測試版本，由業務人員A對需求A的完成情況進行測試
- 3.1.5 節點5 需求A的版本穩定性檢驗（上線版本）
經過UAT測試發現A沒有問題，從Master分支上新建唯一Master_1分支，將DevelopA分支合並到Master_1分支，初步發布生產版本，投入使用檢查新版本的穩定性
場景模擬：業務人員A測試需求A的UAT版本沒有問題，要發布到生產上投入使用，檢驗新版本代碼的穩定性
3.1.5.1 從Master新建Master_1分支
3.1.5.2 將需求A分支合並到該Master_1分支並發版使用
在Master_1分支上，對UAT分支的代碼進行合並：
合並完成的結果：
代碼合並完成，發布生產檢驗版本Master_1，投入生產使用，檢驗代碼的穩定性
- 3.1.6 節點6 需求A的穩定代碼輸出
經過一段時間（大概一周），生產上的版本趨於穩定，經過確認沒有問題，則將DevelopA分支合並到Master分支作為功能的最后輸出
3.2 需求A 測試過程接到需求B的開發發版流程
- 3.2.1 節點7 需求B的開發
在需求A進行節點2到節點6（測試）的全過程，開發人員B拿到一個新的具體需求，從 Master 唯一新建分支DevelopB，並進行開發
場景模擬：在需求A的開發或者測試的過程中，開發人員B拿到一個需求B，需要着手開發
3.2.1.1 從Master新建需求B分支
3.2.1.2 在需求B分支上進行代碼的開發
- 3.2.2 節點8 需求B的SIT測試
開發人員B完成分支DevelopB后，則將DevelopB分支合並到現有SIT分支，進行集成測試，此時由測試人員B對SIT分支上的需求B進行測試
場景模擬：開發人員B完成需求B的開發，要發布SIT版本供測試人員B測試，此時，由於SIT環境只有一個，所以需要將需求B分支上的代碼合並到正在進行需求A測試的SIT分支上
在SIT分支上，對需求B分支的代碼改動進行合並：
合並完成的結果：
代碼合並完成，發布SIT測試版本，由測試人員B對需求B的完成情況進行測試
- 3.2.3 節點9 需求B的UAT測試
經過SIT測試發現B沒有問題，則將DevelopB分支合並到現有UAT分支，進行驗收測試，此時由業務人員B對UAT分支上的需求B進行測試
場景模擬：測試人員B完成需求B的SIT測試，要發布UAT版本供業務人員B測試，此時，由於UAT環境只有一個，所以需要將需求B分支上的代碼合並到正在進行需求A測試的UAT分支上
在UAT分支上，對需求B分支的代碼改動進行合並：
合並完成的結果：
代碼合並完成，發布UAT測試版本，由業務人員B對需求B的完成情況進行測試
- 3.2.4 節點10 需求B的版本穩定性檢驗（上線版本）
經過UAT測試發現B沒有問題，則將DevelopB分支合並到現有Master_1分支，初步發布生產版本，投入使用檢查新版本的穩定性
場景模擬：業務人員B完成需求B的UAT測試，要發布到生產上投入使用，檢驗新版本代碼的穩定性，此時，由於生產環境只有一個，所以需要將需求B分支上的代碼合並到正在檢驗需求A穩定性的Master_1分支上
在Master_1分支上，對需求B分支的代碼改動進行合並：
合並完成的結果：
代碼合並完成，發布生產檢驗版本Master_1，投入生產使用，檢驗代碼的穩定性
- 3.2.5 節點11 需求B的穩定代碼輸出
經過一段時間（大概一周），生產上的版本趨於穩定，經過確認沒有問題，則將DevelopB分支合並到Master分支作為功能的最后輸出
3.3 補充：測試發現了問題
凡是測試中發現某個需求未完成要求或者出現相關bug，則需要從該問題所對應的需求分支上進行修改（從源頭需求節點），然后按照流程規范的順序重頭開始進行發版測試，不可以直接修改發現問題的節點
場景模擬：測試人員或者業務人員在測試過程中發現了需求A的bug
此時開發人員A不能直接修改測試人員或者業務人員正在測試的分支，而應該修改需求A對應的源開發分支，然后再按照發版控制規范流程將修改后的代碼合並到相關版本，發版測試
3.4 代碼合並過程的問題
發現問題：合並操作沒有效果
場景模擬：Master_1在合並UAT分支的最新代碼，發現合並沒有效果
可能的原因：Master_1已經合並過UAT分支的代碼，后來其他人提交過UAT分支的代碼，所以本地的UAT分支上的代碼不是最新的，本地需要切換到UAT分支，進行更新，然后再切換到Master_1分支，重新進行代碼的合並
4 添加分支
4.1添加分支的時機
以下情況建議添加分支進行開發：
1. 在必須按與現有分支不同的時間表或周期發布代碼時
2. 在向客戶發布功能且團隊打算進行不影響計划的發布周期的更改時，不應該對每個客戶情景創建分支，因為這會產生較高的集成成本
4.2添加分支的原則
在創建分支時，應從Master上創建分支，因為Master分支最穩定，如果從其他工作分支創建分支，會導致集成問題，因為無法保證其他工作分支的穩定性
5 開發人員注意事項
-
1.開發人員每天早上工作前至少更新一遍工作分支上的代碼
-
2.代碼寫到一段落，需要更新一遍代碼並提交自己修改的代碼（勤update，勤提交）
-
3.提交代碼前一定要進行update，更新代碼后再提交
-
4.更新或者提交代碼時如果發現代碼有沖突，需要立即找到代碼沖突的相關人員查找原因，合並之后才能提交，不能直接強制提交
-
5.發布到UAT和生產環境的代碼，需要由專門的發版人員進行操作，每次發版需要要有對應的記錄，文檔留底