最近工作中遇到一個開發團隊，對代碼的版本控制管理居然沒有要求，導致了種種問題。

1.由於分支沒有規範，最後一個小版本上線合代碼居然化了幾個小時，最後開發人員自己都不知道合到哪個分支。

2.一些人把所有的代碼都提交到master上，造成在維護的時候，難以得到想要的高效的穩定的版本，也無法區分版本管理節點

3.代碼提交的說明，很多人都不註意這個，隨意寫寫就ok了。後期想要明確某次提交修改的問題點時，往往需要重復看代碼才能明確，

在向主幹分支提交（merge）代碼時，代碼說明往往該作為一個模塊的修復，而不是一個一個問題點，細節點的修復。

（比如，提交了一版代碼，忽然發現有個變量命名不規範，又提交了一版，一會又發現漏提交了某個問題，又提交一次，

這對於主幹分支來說，就沒能發揮代碼版本控制的功能，說的不好聽一點，這種版本控制管理就只是相當於一個代碼的暫存控件而已，

談不上控制和管理）

4.雖說是使用版本控制，但很多人都不明確，這個版本控制到底是什麽，多數人只怕還停留在“代碼存儲”的概念上吧。

。。。

還有很多，列舉起來種種難以窮盡。

當然，在實際的工作中，雖然沒有完美的工作流，但是，我卻相信是有更好更佳的工作流的。

比如，版本控制來說，對後期代碼維護，版本維護，客戶問題應急響應等方面都是很有幫助的。

拿 GitLab 來說，它很好地支持了多分支代碼版本，需要利用這個特性來提高開發效率，上圖就是目前的分支管理規範。

以下是個人在工作中的一點總結，分享出來大家共同勉勵。有不足之處，希望大家多多交流，以求共同進步。

最穩定的代碼放在 master 分支上，不要直接在 master 分支上提交代碼，只能在該分支上進行代碼合並操作，例如將其它分支的代碼合並到 Master 分支上。



開發中的代碼需要從 master 分支拉一條 develop 分支出來，該分支所有人都能訪問，但一般情況下，也不會直接在該分支上提交代碼，代碼同樣是從其它分支合並到 develop 分支上去。



當需要開發某個特性時，需要從 develop 分支拉出一條 feature 分支，例如 feature-1 與 feature-2
 
，在這些分支上並行地開發具體特性。



當特性開發完畢後，決定需要發布某個版本了，此時需要從 develop 分支上拉出一條 release 分支，

例如 release-1.0.0，並將需要發布的特性從相關 feature 分支一同合並到 release 分支上，隨後將針對 release 分支推送到測試環境，測試工程師在該分支上做功能測試，開發工程師在該分支上修改 bug。



待測試工程師無法找到任何 bug 時，可將該 release 分支部署到預發環境，再次驗證以後，均無任何 bug，此時可將 release 分支部署到生產環境。
待上線完成後，將 release 分支上的代碼同時合並到 develop 分支與 master 分支，並在 master 分支上打一個 tag，例如 v1.0.0。



當生產環境發現 bug 時，需要從對應的 tag 上（例如 v1.0.0）拉出一條 hotfix 分支（例如 hotfix-1.0.1），並在該分支上做 bug 修復。待 bug 完全修復後，需將 hotfix 分支上的代碼同時合並到 develop 分支與 master 分支。



對於版本號也有要求，格式為：x.y.z，其中，x 用於有重大重構時才會升級，y 用於有新的特性發布時才會升級，z 用於修改了某個 bug 後才會升級。針對每個微服務，都需要嚴格按照以上開發模式來執行。

需要善用代碼版本控制系統，我曾經遇到一個開發團隊，由於分支沒有規範，最後一個小版本上線合代碼居然化了幾個小時，最後開發人員自己都不知道合到哪個分支。拿 GitLab 來說，它很好地支持了多分支代碼版本，需要利用這個特性來提高開發效率，上圖就是目前的分支管理規範。
最穩定的代碼放在 master 分支上，不要直接在 master 分支上提交代碼，只能在該分支上進行代碼合並操作，例如將其它分支的代碼合並到 Master 分支上。
日常開發中的代碼需要從 master 分支拉一條 develop 分支出來，該分支所有人都能訪問，但一般情況下，也不會直接在該分支上提交代碼，代碼同樣是從其它分支合並到 develop 分支上去。
當需要開發某個特性時，需要從 develop 分支拉出一條 feature 分支，例如 feature-1 與 feature-2，在這些分支上並行地開發具體特性。
當特性開發完畢後，決定需要發布某個版本了，此時需要從 develop 分支上拉出一條 release 分支，例如 release-1.0.0，並將需要發布的特性從相關 feature 分支一同合並到 release 分支上，隨後將針對 release 分支推送到測試環境，測試工程師在該分支上做功能測試，開發工程師在該分支上修改 bug。
待測試工程師無法找到任何 bug 時，可將該 release 分支部署到預發環境，再次驗證以後，均無任何 bug，此時可將 release 分支部署到生產環境。待上線完成後，將 release 分支上的代碼同時合並到 develop 分支與 master 分支，並在 master 分支上打一個 tag，例如 v1.0.0。
當生產環境發現 bug 時，需要從對應的 tag 上（例如 v1.0.0）拉出一條 hotfix 分支（例如 hotfix-1.0.1），並在該分支上做 bug 修復。待 bug 完全修復後，需將 hotfix 分支上的代碼同時合並到 develop 分支與 master 分支。
對於版本號也有要求，格式為：x.y.z，其中，x 用於有重大重構時才會升級，y 用於有新的特性發布時才會升級，z 用於修改了某個 bug 後才會升級。針對每個微服務，都需要嚴格按照以上開發模式來執行。

關於代碼控制管理的一些想法