2019-01-03 git 程式碼管理

個人的git程式碼管理心得：
1.我們一般不會用到分支branch。只有一種場景下我們需要開多個分支：
我們一邊在開發新需求，一邊要修改線上版本的bug。
所以，我們需要至少兩個分支：
dev下一版本開發分支，專門負責開發需求
prd線上版本修復分支，專門修復線上bug。（這裡我把master當成prd使用，這樣做是因為：master本身也是一個分支，打包預設都是master，測試也必須測試masyer上的分支的程式碼，所以master完全可以當做prd）

這裡面就有關於合併的藝術了。
第一：開發需求在dev分支
第二：修改線上bug和發版打tag在prd分支上。
這樣，在sourceTree上就會出現分叉點。
假設：提交日誌如下：
branch dev ： 開發需求1
branch master ： 修復bug1

然後到了合併這一天，在sourceTree上操作步驟如下：
本地分支選擇master ，在sourceTree上選取遠端的dev程式碼提交節點，進行程式碼合併。提交日誌為：branch master ：合併遠端dev程式碼到本地master分支，解決衝突

接著，測試介入，開發人員在master上解決測試提出的bug，日誌如下：
branch master ：解決測試人員反饋的bug

最後，測試完畢，打包，上線，發版，打tag

下一版本即將開發前，我們需要把dev更新到最新，這裡面又出現一次合併：
日誌如下：
branch dev ：合併遠端master程式碼到本地dev分支，解決衝突，開啟下一階段的需求開發

以上所有過程，只有兩個分支，一個版本開發週期裡，只會發生兩次程式碼合併的過程。減少了合併的操作，和測試人員的工作。

疑問1：dev合併到master後，如果線上版本出bug怎麼辦？
1.不嚴重bug，那就在dev階段解決，然後一期上線。
2.嚴重bug：立即拉取一個新分支，我叫它：緊急修復分支emergency
在這個分支上，我們使用程式碼回滾，然後修復bug，然後在這個分支上立即打一個包，給線上使用即可。