主分支，命名為master，版本分支發版后合并到該分支，只有生產部署權限可以合并其它分支到該分支；
版本分支，命名為release_版本號_發版時間，從master創建，版本發布使用，版本發布前或者發布后打tag標簽，也可以不打標簽看自己，版本發布后合并代碼到master，
功能分支，命名為feature_[需求編號|任務編號]，從版本分支創建，每個功能分支對應一個需求，功能分支是開發人員使用的分支，開發人員的代碼提交到功能分支后，在合并到版本分支之前先把版本分支代碼合并一次到自己的功能分支，然后再合并到版本分支，
缺陷分支，命名為bugfix_[缺陷編號]，從版本分支創建，每個缺陷分支對應一個bug，如果覺得分支太多可以不用缺陷分支，對于缺陷的修改可以放在功能分支上，
注意事項
- 功能分支合并到版本分支的權限控制，開發人員只能發起合并請求，開發經理審批合并請求，
- 版本分支發布后也只能由開發經理合并版本分支到master分支，
- 功能分支發起合并請求前開發人員一定先把版本分支合并一次到自己的功能分支上，再發起合并請求，
上面這套流程用于單個客戶的版本管理或者是自己公司產品的版本管理是最好的，對于版本的管控比較有力度，特別是結合jira可以清楚的看到每個版本的完成情況，可以清楚的看出哪個需求沒完成或者哪個缺陷沒修復，在版本上線后發現問題可以剔除有問題的功能，直接剔除有問題功能的分支或者缺陷分支即可，
在前期版本規劃的時候就可以知道每個版本包含哪些需求，包括后面發現的缺陷修復，而每個需求每個缺陷都有對應的負責人，管理起來非常方便，按照版本規劃走，預留一定的缺陷修改時間，不加班少扯皮，
如果是對應多個客戶的情況，一是復制一份代碼從新創建git庫，每個git庫對應一個客戶，另一個方案是同一個git對應多個客戶，分支命名上加上一個客戶表示，比如主分支名master_hw，版本分支名release_hw_版本號_發版時間，功能分支名feature_hw_[需求編號|任務編號]等，
當然每個git就是一個專案，專案一般會區分環境，一般是uat環境，fat環境，dev環境等；一般是功能分支部署到dev環境，便于開發人員自己測驗；用版本分支部署到fat環境，便于測驗人員測驗，
對于權限的控制，dev環境的開發人員有部署權限，fat測驗人員有部署權限，uat環境的只能由運維人員操作，
流程是死的人是活的，找到合適自己專案的流程就可以了，不必死套流程，合適自己的才是最好的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/547845.html
標籤：其他
下一篇：如何快速查出bug