git打交道。不同的開發場景，也許每個團隊都有自己的git工作流。在這裡，我想分享一下我的團隊目前正在使用的基於gitlab的git工作流程 。一起交流一下。
規範化的git流程能夠降低我們的出錯幾率，也不會常常遇到git問題，然後去一系列git高階應對。我們的六套git玩兒，其實只要會基本的git操作就行了，然後規範化操作，基本上不會遇到git問題，這樣大家就可以最終將時間用於業務上。，希望大家研究git的時候在感興趣的時候，當遇到問題時，緊急尋找答案的時候##我們的這種git工作流程玩兒法呢，主要是分成下面幾個去分支：
##fix-xxx#master
#分支代表去最新的穩定版本的程式碼，一般是版本分支或修復分支的程式碼上線後合併過來的。 feat-xxx
vx.x.x代表的是版本分支，這個是我們在每個版本開始前，以此次版本號為名從master建立的分支，例如版本號是2.0.1，那麼版本分支則為v2.0.1。然後等到該版本的各個新功能在feat-xxx開發完成並冒煙測試通過後，就到gitlab上提一個mr合併到該版本分支上。等到各個環境測試通過後，就將版本分支的程式碼合併到master上，然後就可以刪除本次的版本分支了。
fix-xxx表示的是修復分支，通常在處理線上問題時，建立一個以缺陷名稱命名的分支，在缺陷測試通過後，透過mr合併到master分支去
注意：這裡有個細節是，在特性分支上開發提交的commit信息，一般認為是無用信息，會在合併給版本分支的時候給合併到一個commit（由於我們是使用gitlab#來合併，所以在發起mr請求時勾選 squash選項就好了），而在提測後不論是修復測試過程中bug，或者是優化功能的commit則會全部保留，這個目的是一個警示，因為我希望最好的情況是提測即上線，雖然達到這個目標有難度，但是這些留下的commit訊息可以幫助我們複盤
各分支的作用如上面所描述的那樣，接著聊聊我們開發的一些經典場景該怎麼做：
我們以本次需要開發一個1.0.0版本為例，這個其中有兩個功能模組，一個是需要添加一個按鈕，一個是需要添加一個表格
sequenceDiagram master->>v1.0.0: 从master切出 v1.0.0 master->>feat-add-button: 从master切出 feat-add-button master->>feat-add-form: 从master切出 feat-add-button feat-add-form->>feat-add-form: 开发完成 feat-add-button->>feat-add-button: 开发完成 feat-add-button->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit feat-add-form->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit v1.0.0->>v1.0.0: 提测 feat-add-button->>feat-add-button: 修复测试bug feat-add-button->>v1.0.0: 将修复的 commit cherry pick到 v1.0.0 v1.0.0->>master: 在gitlab上mr到master，并将合并信息改成 v1.0.0
#透過上面的時序圖，可以看到，我們以我們即將開始的版本命名了一個版本分支v1.0.0,並且也根據這個版本下面的兩個功能創建了兩個特性分支feat-add-button和feat- add-form,然後等功能開發完成後再透過gitlab發起mr（注意，這裡要把合併commit選項勾選上）合併到v1.0.0,那麼v1.0.0分支的程式碼就會從dev環境開始流轉，直到生產環境。這其中，如果有需要修復或優化的地方，也是先修改特性分支，然後再cherry pick到版本分支上面。上線以後刪除版本分支以及下面的特性分支。
透過這個流程管理的程式碼版本非常清晰，這是截取的master的一部分片段
在正常迭代流程還有個場景。那就是在開發過程中，pm突然過來說，因為某種不可抗力，有一個功能要砍掉。這時候，如果是程式碼還沒提測，也或者是功能比較簡單，處理起來還不算麻煩。但如果是，你的功能和其他同事的程式碼已經在測試了，也已經修復了一些bug，commit都交叉在一起，特別是那種涉及修改檔案還多的需求，這個時候處理起來就很麻煩，不只要看著別人的程式碼，還要警惕自己的程式碼別弄錯了。那這個時候，在我們流程裡就很簡單，直接刪除現有的版本分支就好了，再重新將需要上線的特性分支組合在一起就可以了。可以看到，版本分支是由特性分支組合起來的，也就是說，版本分支可以由不同的特性分支隨意組合。這樣處理起來就比較方便
我們以線上需要修復一個按鈕的點擊事件為例
sequenceDiagram master->>fix-button-click: 从master切出 fix-button-click fix-button-click->>fix-button-click: 修复问题并测试 fix-button-click->>master: 从gitlab发起mr合并到master
其實這裡的流程跟上面沒多大的差別，但這裡要注意的是，線上問題修復，一個bug一個commit，合併到master的時候不合併commit。而且需要將合併資訊修改為本次的版本號。例如本次則為v1.0.1
這個場景跟正常迭代場景並沒啥區別，只是取決於你有多個版本，就創建對應的版本分支就可以了。每個版本分支都按照正常迭代流程就可以了。
Q：為什麼沒有使用dev、test等對應環境的分支，這樣也好實現push既部署
A：我們這個流程是放棄了使用這些固定的分支的。有幾個原因，
程式碼提測後從dev到test，甚至再到uat（預發布）環境，如果在不同的環境都有程式碼的變動，那麼為了保持這些分支程式碼一致的話，就需要將程式碼同步到各個環境分支，這點兒有些費事兒。而版本分支不存在這個問題，版本分支只有一個，可以對應到各個環境。
方便多版本並行開發。版本分支可以創建多個，並行開發的時候比較方便部署到不同的測試環境。如果版本之間的模組關聯性不大，還可以並行測試。
語意化。版本分支可以透過分支名稱就知道目前有哪些分支正在開發中。
Q: master分支有變動怎麼處理
A: master分支有變動的話，及時的合併到自己的功能分支上，以防和其他成員代碼有衝突
推薦學習：《Git影片教學》
以上是分享一個git工作流程優雅的玩法的詳細內容。更多資訊請關注PHP中文網其他相關文章！
