一、開發分支模型分類

目前所在部門使用是主要是四種：dev（開發）、test（測試）、uat（預發）、release（生產）

小公司可能就一個 dev、一個 master 就搞定了，測試都是開發人員自己來。

二、開發主體流程

1. 需求評審
2. 開發排期
3. 編碼開發
4. 冒煙測試（自檢驗）
5. 冒煙通過，提交測試，合並代碼到測試分支，部署測試環境
6. 測試環境測試，開發修 bug
7. 測試完成，提交預發，合並代碼到預發分支，部署預發環境
8. 預發環境測試，開發修 bug（修完的 bug 要重新走測試再走預發，這個下面會解釋）
9. 測試完成，產品驗收
10. 驗收完成，提交生產，合並代碼到生產分支，部署生產環境
11. 生產運營（客戶）驗收
12. 驗收完成，結項

三、具體操作

1. 拉取代碼

一般都會在本地默認創建一個 master 分支

git clone https://code.xxx.com/xxx/xxx.git

2. 初次開發需求前，要先拉取生產/預發分支，然後基於這個分支之上，創建自己的特性分支進行開發

git fetch origin release:release git checkout release git checkout -b feat-0131-jie

此時，在你本地已經有了一個 release 分支對應著遠程倉庫的 release 分支，還有一個內容基於 release 分支的特性分支，之後便可以在這個特性分支上進行需求開發了。

註意1：分支名稱是有規范和含義的，不能亂取。

推薦格式：分支責任-需求日期/需求號-開發人姓名，一般按部門規范來，常見的有以下幾種。

- feat：新功能 - fix：修補bug - doc：文檔 - refactor：重構（即不是新增功能，也不是修改bug的代碼變動） - test：測試 - chore：構建過程或輔助工具的變動

註意2：為啥拉取的是生產/預發分支

之所以要拉取 release/uat 分支而不是拉取 dev/test，是因為後者可能包含著一些其他成員還未上線或者可能有 bug 的需求代碼，這些代碼沒有通過驗證，如果被你給拉取了，然後又基於此進行新的需求開發，那當你需求開發完成，而其他成員的需求還沒上線，你將會把這些未驗證的代碼一起發送到 uat/release 上，導致一系列問題。

3. 需求開發完成，提交&合並代碼

首先先在本地把新的改動提交，提交描述的格式可以參考著分支名的格式

• 如果是新需求的提交，可以寫成 "feat: 需求0131-新增賬期"
• 如果是 bug 修復，可以寫成 "fix: 禪道3387-重復請求"

git add . git commit -m "提交描述"

此時，本地當前分支已經記錄了你的提交記錄，接下來進行代碼合並了

在代碼合並之前，我們先要梳理一下我們應該如何對分支進行管理（非常重要！）

1. 首先，我們需要認知到的是，每一個分支應該隻對應一個功能，例如當我們開發需求 01 時，那麼就創建一個 feat-01-jie 分支進行開發；開發需求 02 時，就另外創建一個 feat-02-jie 分支進行開發；修改生產環境的某個 bug 時，就創建 fix-jie-3378 進行開發，等等。
2. 這樣做的目的是，能夠把不同的功能/需求/修改分離開來。想象一下這樣一個場景，如果有某些緊急的需求是需要提前上線的，而此時你的分支裡既包含了這些緊急的需求，又包含了其他未開發好的需求，那麼這兩種需求就不能拆開來分別進行提測和上線了。
3. 其次，在合並代碼時，我們要將四種分支模型（dev、test、uat、release）作為參照物，而不是把關註點放在自己的分支上。比如我們要在 dev 上調試，那就需要把自己的分支合並到 dev 分支上；如果我們需要提測，則把自己的分支合並到 test 分支上，以此類推。
4. 即，我們要關註到，這四個環境的分支上，會有什麼內容，會新增什麼內容。切記不能反過來將這四個分支合並到自己的代碼上！！ 如果其他成員將自己的代碼也提交到 dev 分支上，但是這個代碼是沒有通過驗證的，此時你將 dev 往自己的分支上合，那之後的提測、上預發、生產則很大概率會出問題。所以一定要保持自己的分支是幹凈的！

接下來介紹合並代碼的方式：

第一種：線上合並，也是推薦的規范操作

git push origin feat-0131-jie

先接著上面的提交步驟，將自己的分支推送到遠程倉庫。

然後在線上代碼倉庫中，申請將自己的分支合並到 xx 分支（具體是哪個分支就根據你當前的開發進度來，如 test），然後在線上解決沖突。如果有權限就自己通過了，如果沒有就得找 mt 啥的

第二種，本地合並（前提你要有對應環境分支 push 的權限）

## 先切換到你要提交的環境分支上，如果本地還沒有就先拉取下來 git fetch origin test:test git checkout test ## 然後將自己的分支合並到環境分支上（在編輯器解決沖突） git merge feat-0131-jie ## 最後將環境分支推送到遠程倉庫 git push origin test

## 先切換到你要提交的環境分支上，如果本地已有該分支，則需要先拉取最新代碼 git checkout test git pull origin test ## 然後將自己的分支合並到環境分支上（在編輯器解決沖突） git merge feat-0131-jie ## 最後將環境分支推送到遠程倉庫 git push origin test

兩種方式有何區別？為什麼推薦第一種？

這是因為在團隊協作開發的過程中，將合並操作限制在線上環境有以下幾個好處：

1. 避免本地合並沖突：如果多個開發人員同時在本地進行合並操作，並且對同一段代碼進行了修改，可能會導致沖突。將合並操作集中在線上環境可以減少此類沖突的發生，因為不同開發人員的修改會先在線上進行合並，然後再通過更新拉取到本地。
2. 更好的代碼審查：將合並操作放在線上環境可以方便其他開發人員進行代碼審查。其他人員可以在線上查看合並請求的代碼變動、註釋和討論，並提供反饋和建議。這樣可以確保代碼的質量和可維護性。
3. 提高可追溯性和可回滾性：將合並操作記錄在線上可以更容易地進行版本控制和管理。如果出現問題或需要回滾到之前的版本，可以更輕松地找到相關的合並記錄並進行處理。

當然，並非所有情況都適用於第一種方式。在某些特定情況下，例如個人項目或小團隊內部開發，允許本地合並也是可以的。但在大多數團隊協作的場景中，將合並操作集中在線上環境具有更多優勢。

4. 驗收完成，刪除分支

當我們這一版的需求完成後，本地肯定已經留有很多分支了，這些分支對於之後的開發已經意義不大了，留下來隻會看著一團糟。

git branch -d <分支名> ## 如果要強制刪除分支（即使分支上有未合並的修改） git branch -D <分支名>

四、一些小問題

1. 前面提到，預發環境修完的 bug 要重新走測試再走預發，為什麼呢？

預生產環境是介於測試和生產環境之間的一個環境，它的目的是模擬生產環境並進行更真實的測試。 它是一個重要的測試環境，需要保持穩定和可靠。通過對修復的bug再次提交到測試環境測試，可以確保預生產環境中的軟件版本是經過驗證的，並且沒有明顯的問題。

當然，也不是非要這麼做不可，緊急情況下，也可以選擇直接發到預生產重新測試，隻要你保證你的代碼 99% 沒問題了。

2. 代碼合並錯誤，並且已經推送到遠程分支，如何解決？

假設是在本地合並，本來要把特性分支合並到 uat 分支，結果不小心合到了 release 分支（絕對不是我自己的案例，絕對不是。。。雖然好在最後同事本地有我提交前的版本，事情就簡單很多了）

首先切換到特性分支合並到的錯誤分支，比如是 release

git checkout release

然後查看最近的合並信息

git log --merges

撤銷合並

git revert -m 1 <merge commit ID>

• 這裡的 merge commit ID 就是上一步查詢出來的 ID 或者 ID 的前幾個字符

最後，撤銷遠程倉庫的推送

git push -f origin release

• 這個命令會強制推送本地撤銷合並後的 release 分支到遠程倉庫，覆蓋掉遠程倉庫上的內容。（即，得通過一個新的提交來“撤銷”上一次的提交，本質上是覆蓋）

3. 當前分支有未提交的修改，但是暫時不想提交，想要切換到另一個分支該怎麼做？

例如：你正在開發 B 需求，突然產品說 A 需求有點問題，讓你趕緊改改，但是當前 B 需求還沒開發完成，你又不想留下過多無用的提交記錄，此時就可以按照下面這樣做：

首先，可以將當前修改暫存起來，以便之後恢復

git stash

然後切換到目標分支，例如需求 A 所在分支

git checkout feat-a-jie

修改完 A 需求後，需要先切換回之前的分支，例如需求 B 所在分支

git checkout feat-b-jie

如果你不確定之前所在的分支名，可以使用以下命令列出暫存的修改以及它們所屬的分支：

git stash list

最後從暫存中恢復之前的修改

git stash pop

此時你的工作區就恢復如初了！

喜歡本文的話，可以點贊收藏呀~

如果有疑問，歡迎評論區留言探討~