主分支，命名為master，版本分支發(fā)版后合并到該分支，只有生產(chǎn)部署權(quán)限可以合并其它分支到該分支；

版本分支，命名為release_版本號_發(fā)版時間，從master創(chuàng)建，版本發(fā)布使用，版本發(fā)布前或者發(fā)布后打tag標簽，也可以不打標簽看自己，版本發(fā)布后合并代碼到master。

功能分支，命名為feature_[需求編號|任務(wù)編號]，從版本分支創(chuàng)建，每個功能分支對應(yīng)一個需求。功能分支是開發(fā)人員使用的分支，開發(fā)人員的代碼提交到功能分支后，在合并到版本分支之前先把版本分支代碼合并一次到自己的功能分支，然后再合并到版本分支。

缺陷分支，命名為bugfix_[缺陷編號]，從版本分支創(chuàng)建，每個缺陷分支對應(yīng)一個bug，如果覺得分支太多可以不用缺陷分支，對于缺陷的修改可以放在功能分支上。

注意事項

• 功能分支合并到版本分支的權(quán)限控制，開發(fā)人員只能發(fā)起合并請求，開發(fā)經(jīng)理審批合并請求。
• 版本分支發(fā)布后也只能由開發(fā)經(jīng)理合并版本分支到master分支。
• 功能分支發(fā)起合并請求前開發(fā)人員一定先把版本分支合并一次到自己的功能分支上，再發(fā)起合并請求。

上面這套流程用于單個客戶的版本管理或者是自己公司產(chǎn)品的版本管理是最好的，對于版本的管控比較有力度，特別是結(jié)合jira可以清楚的看到每個版本的完成情況，可以清楚的看出哪個需求沒完成或者哪個缺陷沒修復(fù)。在版本上線后發(fā)現(xiàn)問題可以剔除有問題的功能，直接剔除有問題功能的分支或者缺陷分支即可。

在前期版本規(guī)劃的時候就可以知道每個版本包含哪些需求，包括后面發(fā)現(xiàn)的缺陷修復(fù)，而每個需求每個缺陷都有對應(yīng)的負責(zé)人，管理起來非常方便。按照版本規(guī)劃走，預(yù)留一定的缺陷修改時間，不加班少扯皮。

如果是對應(yīng)多個客戶的情況，一是復(fù)制一份代碼從新創(chuàng)建git庫，每個git庫對應(yīng)一個客戶，另一個方案是同一個git對應(yīng)多個客戶，分支命名上加上一個客戶表示，比如主分支名master_hw，版本分支名release_hw_版本號_發(fā)版時間，功能分支名feature_hw_[需求編號|任務(wù)編號]等。

當然每個git就是一個項目，項目一般會區(qū)分環(huán)境，一般是uat環(huán)境，fat環(huán)境，dev環(huán)境等；一般是功能分支部署到dev環(huán)境，便于開發(fā)人員自己測試；用版本分支部署到fat環(huán)境，便于測試人員測試。

對于權(quán)限的控制，dev環(huán)境的開發(fā)人員有部署權(quán)限，fat測試人員有部署權(quán)限，uat環(huán)境的只能由運維人員操作。

流程是死的人是活的，找到合適自己項目的流程就可以了，不必死套流程，合適自己的才是最好的。