當前開發代碼管理大部分使用的都是 git ，使用 git 一大原因主要就是 git 分支足夠靈活，但是當多個開發人員維護同一個專案的時候就需要考慮 git 分支的一些管理規范，下面是我個人對 git 分支管理的一些思考和建議，
專案分支一般包括 master(main) / test / develop / feature ，各分支的功能如下：
| 分支名稱 | 分支功能 |
|---|---|
| master(main) | 一般用于發布線上環境的代碼分支 |
| test | 一般用于測驗環境的代碼分支 |
| develop | 一般用于開發環境或者是冒煙測驗環境的代碼開支 |
| feature | 一般用于功能開發的代碼分支，并且每次新功能開發的 feature 分支都應該是從 master(main) 上新開分支 |
個人開發
常用的個人代碼分支管理如下（基于每次迭代的功能都是統一上線發布）：
如果每次迭代的功能并不能保證統一上線的話，就需要在一個迭代中創建多個 單一功能模塊的 feature 分支，將 單一功能模塊的feature 分支合并到 develop 冒煙測驗，合并 test 發布測驗，合并 master(main) 發布上線，
多人開發
多人開發，功能統一上線
當多人開發，并且能保證功能統一上線的話，這個時候依然可以用上面的分支管理方式：
這個時候每個 feature 實際上對應每個人的分支，開發完成后統一合并到 develop 分支進行冒煙測驗，再又 develop 合并到 test 分支 發布測驗，之后合并 master(main) 分支 發布上線，
多人開發，功能獨立上線
多人開發，功能獨立上線常用的代碼分支管理如下：
每個 feature 功能分支獨立開發，將獨立的 feature 分支合并到 develop 分支進行冒煙測驗，將獨立的 feature 分支合并到 test 分支進行測驗，將獨立的 feature 分支合并到 master 分支發布上線，
當然為了防止有些人合錯代碼，直接發布到線上，可以在 master(main) 分支前加一個 release 分支，將獨立的 feature 分支合并到 release 分支發布上線，再由專人將 release 分支合并到 master，
多人開發，有的功能相互依賴，有的獨立發布
在專案中更多的情況是有的功能相互依賴，有的可以獨立發布，這個時候常用的分支管理如下：
這個時候 feature-c 和 feature-d 都開發完了，要合并代碼到 feature-b 分支，feature-c 先合并，再合并 feature-d 就有可能有沖突，那這個時候沖突怎么解決呢？
總之遵守如下的思想去進行代碼管理：
- 保證代碼干凈，意思是不能把別人的代碼合并到你的分支，你的分支代碼可以獨立上線
- 分支是用來解決問題的，不要嫌分支多
以上是我個人針對專案分支管理的看法，有不同意見的歡迎評論，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/298674.html
標籤：其他