前言
- 最近工作中發現，很多開發人員連最基本的Git怎么使用都不知道，比如什么時候切分支，什么時候合并代碼，代碼遇到沖突怎么辦，經常出現掉代碼，代碼合并后丟失的情況。
- 以下為個人總結的常規Git開發工作流程的使用，每個公司使用不一致，僅供參考。
分支分類
- dev（開發）
- test（測試）
- uat （預發布）
- master （生產）
研發流程
- 需求評審
- 開發排期
- 編碼開發
- 冒煙測試（單元測試）
- 冒煙通過，提交測試，合并代碼到測試分支，部署測試環境
- 測試環境測試，開發修 BUG
- 測試完成，提交預發，合并代碼到預發分支，部署預發環境
- 預發環境測試，開發修 bug
- 測試完成，產品驗收
- 驗收完成后，基于生產分支進行TAG
- 提交生產，合并代碼到生產分支，部署生產環境
- 生產運營（客戶）驗收
- 驗收完成，結項
實際操作
代碼拉取
git clone https://code.xxx.com/xxx/xxx.git
- 查看本地分支：
git branch - 查看遠程分支：
git branch -a
創建版本分支
- 本地創建版本分支：
git branch fix-20240223-order - 本地切換版本分支：
git checkout fix-20240223-order - 本地推送版本至遠程倉庫：
git push origin fix-20240223-order:fix-20240223-order
分支名稱是有規范和含義的，不能亂取
推薦格式：分支責任-需求日期/需求號-業務類型，一般按部門規范來，常見的有以下幾種：
- feat：新功能
- fix：修補bug
- doc：文檔
- refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
- test：測試
- chore：構建過程或輔助工具的變動
- 為啥拉取的是生產/預發分支
之所以要拉取 master 分支而不是拉取 dev/test，是因為后者可能包含著一些其他成員還未上線或者可能有 BUG的需求代碼，這些代碼沒有通過驗證，如果被你給拉取了，然后又基于此進行新的需求開發，那當你需求開發完成，而其他成員的需求還沒上線，你將會把這些未驗證的代碼一起發送到 uat/master上，導致一系列問題。
需求完成，提交代碼
- 提交代碼：
- 首先先在本地把新的改動提交，提交描述的格式可以參考著分支名的格式
如果是新需求的提交，可以寫成 “feat: 需求20240111-新增導出”
如果是 bug 修復，可以寫成 “fix: 禪道3387-重復請求處理”
- 提交本地代碼至遠程倉庫
git add .
git commit -m "提交描述"
git push origin fix-20240223-order:fix-20240223-order
- 提交之前可能需要更新，因為該分支是一個版本分支，可能開發人員有幾個人同時在這個版本分支進行開發，這個時候可能同一種業務就可能存在代碼沖突，需要解決。
版本需求完成，合并代碼
- 首先，我們需要認知到的是，每一個分支應該只對應一個版本，例如當我們開發01版本時，那么就創建一個 feat-01-order 分支進行開發；開發版本 02 時，就另外創建一個 feat-02-member 分支進行開發；修改生產環境的某個 bug 時，就創建 fix-bug-3378 進行開發，等等。
這樣做的目的是，能夠把不同的功能/需求/修改分離開來。想象一下這樣一個場景，如果有某些緊急的需求是需要提前上線的，而此時你的分支里既包含了這些緊急的需求，又包含了其他未開發好的需求，那么這兩種需求就不能拆開來分別進行提測和上線了。
- 其次，在合并代碼時，我們要將四種分支模型（dev、test、uat、master）作為參照物，而不是把關注點放在自己的分支上。比如我們要在 dev 上調試，那就需要把自己的分支合并到 dev 分支上；如果我們需要提測，則把自己的分支合并到 test 分支上，以此類推。
我們要關注到，這四個環境的分支上，會有什么內容，會新增什么內容。「切記不能反過來將除了 master 之外的三個分支合并到自己的代碼上！！」 如果其他成員將自己的代碼也提交到 dev 分支上，但是這個代碼是沒有通過驗證的，此時你將 dev 往自己的分支上合，那之后的提測、上預發、生產則很大概率會出問題。「所以一定要保持自己的分支是干凈的！」 而 master 分支對應的是生產環境，一般是最新的穩定版本，所以合并到自己的分支以獲取最新的更改也是沒什么問題的。
- 前面我們已經把本地的版本分支推送至遠程倉庫后，在本地進行分支合并至 dev或者test
- 把 本地版本分支 fix-20240223-order 更新至最新的代碼，如合并至dev分支，更新dev分支至最新代碼
- 切換至 dev 分支：
git checkout dev - 版本分支合并至dev分支(沖突解決)：
git merge fix-20240223-order - 環境分支推送至遠程倉庫：
git push origin dev
常見問題
預發環境修完的 bug 要重新走測試再走預發，為什么呢？
預發布環境是介于測試和生產環境之間的一個環境，它的目的是模擬生產環境并進行更真實的測試。它是一個重要的測試環境，需要保持穩定和可靠。通過對修復的BUG再次提交到測試環境測試，可以確保預發布環境中的軟件版本是經過驗證的，并且沒有明顯的問題。
當然，也不是非要這么做不可，緊急情況下，也可以選擇直接發到預生產重新測試
代碼合并錯誤，并且已經推送到遠程分支，如何解決？
- 假設是在本地合并，本來要把特性分支合并到 uat 分支，結果不小心合到了 master分支
- 切換到特性分支合并到的錯誤分支，比如是 master：
git checkout master - 查看最近的合并信息（按 q 退出查看）：
git log --merges - 撤銷合并：
git revert -m 1 <merge commit ID>
【這里的 merge commit ID 就是上一步查詢出來的 ID 或者 ID 的前幾個字符】 - 撤銷遠程倉庫的推送：
git push -f origin master
【這個命令會強制推送本地撤銷合并后的 release 分支到遠程倉庫，覆蓋掉遠程倉庫上的內容。（即，得通過一個新的提交來“撤銷”上一次的提交，本質上是覆蓋）】
cherry-pick 指令
- 作用：選擇某些提交的變更并將其應用到當前分支
- 與 merge 的區別：如果你需要另一個分支的所有代碼變動。那么就采用 merge；如果你只需要部分代碼變動（某幾個提交），那么就采用 cherry-pick
場景：有時候分支不一定是完全按照需求號來開發的，可能按照周期來進行開發，那當前版本內的分支上，可能就會包含著很多需求的提交，這時候，如果產品要求你只上某一個需求，但是其他的暫時還不能上，那就需要使用到 cherry pick 的操作，將該需求囊括的所有提交應用到對應環境分支上。「一定要注意梳理清楚被拆分需求是由多少 commit 組成的，不要有遺漏和多選。」
【更多參考：https://www.ruanyifeng.com/blog/2020/04/git-cherry-pick.html】
寫在最后
-
在團隊內部使用規范的 Git 工作流程，可以幫助我們提高協作效率，減少混亂和沖突。比如規定好分支結構和命名規范，將使得代碼庫的分支結構更加清晰明了，更易于管理。反之，開發者可能會按照自己的喜好隨意創建分支，導致代碼庫分支結構混亂。
-
除此之外還有很多好處，降低錯誤風險、增加代碼可追溯性、簡化發布流程、促進持續集成與持續交付等等。
-
參考資料：https://blog.csdn.net/u010800804/article/details/109594867
