Git作為我們日常開發程式碼的版本管理，開發分支的管理方面起著很大作用，我們開發過程中分支通常有生產、預發、測試、開發這幾個分支，我們會根據計畫進行的某個階段，將程式碼送出到某個版本上，正常流程是先開發 —>測試 —>預發—>生產，但是通常會有很多版本，有先後上線順序，並且我們的開發人員也會是多個，在各種因素下計畫的開發版本遠端分支，以及開發人員的本地分支管理就由為的關鍵。
一 普通開發流程
正常一個版本需要經過的幾個階段，分別是dev、test、uat、master，我們透過下面流程圖這麽做是沒什麽問題的，每個階段去將從master拉取的版本分支，push到對應的分支上進行釋出，正常預發和生產環境的程式碼應該保持一致，test分支由於會有多個版本並列開發，所以程式碼和預發和生產比起來會有一些不一樣。
二 多版本並列開發
在多個版本並非開發的時候，對分支的管理就不像上面那麽簡單了，涉及到多個version，這些版本的上線時間節點也是不同的，意味著上test和uat的時間節點也是不一樣的。
這裏涉及到多種情況
在後端開發人員較少的情況下，通常2-3人為例，完全可以從master拉取一個開發分支，分支格式已 服務名+上線時間，例如xxx_20230130這個本地分支，後端開發人員一起在這個分支上進行並列開發，開發階段將自己的本地分支merge到dev分支，因為只有2-3人所以沖突解決起來還好，有沖突解決沖突。
後端開發人員較多的情況，通常在5-8人為例，這時候從master分支拉取分支，分支格式就需要已 服務名+姓名縮寫+上線時間來命名，盡量每個人在自己命名的分支下進行開發，這樣在開發階段本地測試的時候，可以做到相互不影響，但是在merge到遠端分支的時候，解決程式碼沖突的時候需要認真仔細一些，這種活還是交給心細的人來做吧，測試的時候也需要根據版本上線的優先級進行測試。
版本比較多的情況，比如一個月會有4-5個版本的開發，那麽上線時間也是分4-5個節點，這樣就需要每次從先發上線的遠端分支，將程式碼merge到下個版本的本地開發分支上，以此類推。
三 Git merge
作為git 合並分支的命令，也是在日常開發過程中經常用到的一個命令，通常我們會將擁有最新程式碼的一個版本merge到較老的一個版本，實作版本同步。
大體就是這麽一個步驟，從剛開始的公共分支，變為master和feature分支， 透過git merge master 命令將master分支merge到feature分支。Merge命令會將前面featrue分支所有的commit送出全部合並為一個新的commit送出。⚠️這裏只有會在產生沖突的時候，才能產生新的commit記錄。
可以理解為git pull =git fetch +git merge，拉取最新的遠端分支，然後將這個分支合並到另一個分支。
在公司開發的時候，通常大家喜歡這個命令，因為簡單粗暴，直接將其他分支合並到自己分支，簡單好理解。
四 Git rebase
作為自己的個人喜好，比較喜歡rebase這個命令，核心理念就是「變基」。
由上圖可看見，透過reabse命令將feature分支延續到了master分支後面。
在多人開發過程中，如果其他人在master進行commit，這個時候你在feature分支送出了幾個commit，這時候你使用rebase命令，會將你的commit送出記錄放在master的commit記錄的後面，而merge就會將不同分支的commit合並成一個新的commit記錄，這就是merge和rebase的不同點。
本地feature分支和遠端的master分支如果是同一條分支的話，可以使用rebase，保證commit的記錄的清晰性，這個很關鍵！
⚠️不要在公共分支使用rebase命令，這樣會汙染公共分支，這樣公共分支就會存在你的commit記錄，別人拉取的時候會存在你的最新的commit記錄。
五 總結
在開發中不僅需要程式碼品質高，在版本管理上也是由為的重要，上線前漏掉程式碼的事情，相信大家都曾遇到過，但是這種事情是很危險⚠️的，希望此文章能給大家在日常程式碼版本管理中送出警惕，合理合並分支，最後祝大家在新的一年，少出bug、多多學習、多多進步。
來源：juejin.cn/post/7192823689426468919
>>
END
精品資料，超贊福利，免費領
微信掃碼/長按辨識 添加【技術交流群】
群內每天分享精品學習資料
最近開發整理了一個用於速刷面試題的小程式；其中收錄了上千道常見面試題及答案(包含基礎、並行、JVM、MySQL、Redis、Spring、SpringMVC、SpringBoot、SpringCloud、訊息佇列等多個型別)，歡迎您的使用。
👇👇
👇點選"閱讀原文"，獲取更多資料（持續更新中）
