寫在前面
我們在入職新公司要做的最重要的事情之一就是要熟悉專案的開發上線流程。這對我們能否快速上手至關重要。
主要的流程分為三部分
- 正常的需求分析開發上線流程；
- 測試bug修復合併測試流程；
- 線上bug修改合併上線流程；
工具：git （PS：svn版本管理也可以參照此流程）
理想流程
顧名思義，就是我們收到需求之後先開發，然後提測，然後上線，業務驗收，需求關閉，形成了一個完成的版本流程；
那麼我們可以怎麼來進行版本管理的?
首先我們將版本分成三個分支
- develop
- release
- master
下面介紹下各個分支的作用：
develop -- 開發分支，我們日常的開發自測便在次分支上完成
release -- 待發布分支/測試分支，測試在此分支上進行合併測試
master -- 線上分支，線上程式碼執行在此分支上
所以理想流程，是來了一個需求我們在develop上開發，然後merge到release上進行提測，測試完成之後再從release分支merge至master分支釋出線上。這裡的例子是單需求序列開發的例子。
如果是多需求並行開發呢，這就需要我們根據不同的需求基於develop來拉取不同的分支，比如中臺專案platform-1，platform-2等等，拉取不同的分支之後分別進行開發，再本地測試完成之後在合併到develop統一測試一遍完整流程，沒問題之後通知測試merge到release分支提測，後續流程同上。
測試BUG修改
一名前輩曾經說過，要想寫出沒有bug的程式碼的最好辦法就是一句程式碼也不寫。
我覺得很有道理，bug不可避免，那麼測試測出了bug之後我們要如果修改呢。
其實這裡可以將bug也理解為需求，將上面的開發流程再重複一遍即可，這是一個並行的需求，需要我們從develop分支在拉取一次程式碼，自測完成之後，合併到develop分支，然後再合併到release分支。
當然如果測試的時間非常緊迫，我們也可以直接基於release分支來建立bugfix-1分支，本地測試完成之後直接merge到release分支來進行測試，merge到release之後，別忘記還要同步merge至develop分支。
線上BUG修改
線上bug並不可怕，可怕的是沒有及時修復。亡羊補牢，為時不晚。
線上出現問題之後，第一時間根據日誌和master分支程式碼定位問題，定位出問題之後需要基於master來拉取分支hotfix-1，以迅雷不及掩耳之勢修復完問題，然後merge到master分支，釋出線上。
什麼你說上面的流程沒有測試，怎麼能直接釋出線上？
如果本次無法驗證， 確實需要測試來進行驗證，那麼可以將測試環境release分支直接切換到hotfix-1分支，測試完成之後迅速切回來，然後merge到master分支，釋出線上。
當然，合併master之後，別忘記同步合併到release和develop分支。