分享一個git工作流程優雅的玩法

##.markdown-body{word-break:break-word;line-height:1.75;font-weight:400;font-size:16px;overflow-x:hidden;color:#252933 } .markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{line-height:1.5;margin-top:35px;margin - bottom:10px;padding-bottom:5px}.markdown-body h1{font-size:24px;line-height:38px;margin-bottom:5px}.markdown-body h2{font-size:22px;line-height : 34px;padding-bottom:12px;border-bottom:1pxsolid #ececec}.markdown-body h3{font-size:20px;line-height:28px}.markdown-body h4{font-size:18px;line-高度： 26px}.markdown-body h5{font-size:17px;line-height:24px}.markdown-body h6{font-size:16px;line-height:24px}.markdown-body p{line-height:繼承; margin-top:22px;margin-bottom:22px}.markdown-body img{max-width:100%}.markdown-body hr{border:none;border-top:1pxsolid #ddd;margin-top: 32px;margin -bottom:32px}.markdown-body程式碼{word-break:break-word;border-radius:2px;overflow-x:auto;background-color:#fff5f5;color:#ff502c;font-size: .87em;填充:.065em .4em}.markdown-body程式碼,.markdown-body pre{font-family:Menlo,Monaco,Consolas,Courier New,monospace}.markdown-body pre{overflow:auto;position:relative ;line- height:1.75}.markdown-body pre>code{font-size:12px;padding:15px 12px;margin:0;word-break:normal;display:block;overflow-x:auto;color:#333 ;背景： #f8f8f8}.markdown-body a{text-decoration:none;color:#0269c8;border-bottom:1pxsolid #d1e9ff}.markdown-body a:active,.markdown-body a:hover{顏色: #275b8c}. markdown-body table{display:inline-block!important;font-size:12px;width:auto;max-width:100%;overflow:auto;border:1pxsolid #f6f6f6}.markdown-body thead {背景:#f6f6f6 ;顏色:#000;text-align:left}.markdown-body tr:nth-child(2n){背景顏色:#fcfcfc}.markdown-body td,.markdown-body th{填充:12px 7px;line- height:24px}.markdown-body td{min-width:120px}.markdown-body blockquote{color:#666;padding:1px 23px;margin:22px 0;border-left:4pxsolid # cbcbcb; }.markdown-body blockquote:after{display:block;content:""}.markdown-body blockquote>p{margin:10px 0}.markdown-body ol,.markdown-body ul {padding-left:28px}. markdown-body ol li,.markdown-body ul li{margin-bottom:0;list-style:inherit}.markdown-body ol li .task-list-item,.markdown-body ul li .task-list-item {list-style:none}.markdown-body ol li .task-list-item ol,.markdown-body ol li .task-list-item ul,.markdown-body ul li. 任務清單項目ol,.markdown- body ul li .任務清單項目ul{margin-top:0}.markdown-body ol ol,.markdown-body ol ul,.markdown-body ul ol,.markdown -body ul ul{margin-top:3px}. markdown-body ol li{padding-left:6px}.markdown-body .contains-task-list{padding-left:0}.markdown-body .task-list- item{list-style:none}@media (max -width:720px){.markdown-body h1{font-size:24px}.markdown-body h2{font-size:20px}.markdown-body h3{font- size:18px}}在開發中，得是一個團隊一起開發一個項目，還是自己獨立開發一個項目。都少不了要和

git打交道。不同的開發場景，也許每個團隊都有自己的git工作流。在這裡，我想分享一下我的團隊目前正在使用的基於gitlab的git工作流程 。一起交流一下。

規範化的git流程能夠降低我們的出錯幾率，也不會常常遇到git問題，然後去一系列git高階應對。我們的六套git玩兒，其實只要會基本的git操作就行了，然後規範化操作，基本上不會遇到git問題，這樣大家就可以最終將時間用於業務上。，希望大家研究git的時候在感興趣的時候，當遇到問題時，緊急尋找答案的時候

##我們的這種git工作流程玩兒法呢，主要是分成下面幾個去分支：

master
• 分支最新的穩定程式碼
#vx.x.x
• 分支版本分支，x.x.x是此次開發的版本號。
feat-xxx
• #分支特性（新的功能）分支 ##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都交叉在一起，特別是那種涉及修改檔案還多的需求，這個時候處理起來就很麻煩，不只要看著別人的程式碼，還要警惕自己的程式碼別弄錯了。那這個時候，在我們流程裡就很簡單，直接刪除現有的版本分支就好了，再重新將需要上線的特性分支組合在一起就可以了。可以看到，版本分支是由特性分支組合起來的，也就是說，版本分支可以由不同的特性分支隨意組合。這樣處理起來就比較方便

第二個場景線上bug修復

我們以線上需要修復一個按鈕的點擊事件為例

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&A

Q：為什麼沒有使用dev、test等對應環境的分支，這樣也好實現push既部署

A：我們這個流程是放棄了使用這些固定的分支的。有幾個原因，

• 程式碼提測後從dev到test，甚至再到uat（預發布）環境，如果在不同的環境都有程式碼的變動，那麼為了保持這些分支程式碼一致的話，就需要將程式碼同步到各個環境分支，這點兒有些費事兒。而版本分支不存在這個問題，版本分支只有一個，可以對應到各個環境。

• 方便多版本並行開發。版本分支可以創建多個，並行開發的時候比較方便部署到不同的測試環境。如果版本之間的模組關聯性不大，還可以並行測試。

• 語意化。版本分支可以透過分支名稱就知道目前有哪些分支正在開發中。

Q: master分支有變動怎麼處理

A: master分支有變動的話，及時的合併到自己的功能分支上，以防和其他成員代碼有衝突

推薦學習：《Git影片教學》

#

以上是分享一個git工作流程優雅的玩法的詳細內容。更多資訊請關注PHP中文網其他相關文章！