前言
Git是一個很方便的版本管理工具，我所認識的大部分開發者都在使用Git，也正是由於其方便性，如果團隊沒有一個統一的分支管理策略，那么分支可能會非常混亂，開發者將因此花費額外的時間處理這方面的問題。在搜索引擎上搜索分支管理策略，大部分都指向Vincent Driessen提出的策略。我這里也記錄一下，萬一以后讓公司讓我寫規范文檔或者面試中問到，能夠說的清楚系統一些。
介紹
這個策略將分支分為了兩個部分:
主要分支
主要分支有兩個，長期存在。
Master
Master是用於部署生產環境的分支，有且只有一條。一般由develop分支合並，任何時間都不能直接修改代碼。
Develop
develop 為開發分支，始終保持最新完成以及bug修復后的代碼；
當develop分支的源碼到達了一個穩定狀態待發布，所有的代碼變更需要以某種方式合並到master分支，然后標記一個版本號（TAG）。所以，每次變更都合並到了master，這就是新產品的定義。在這一點，我們傾向於嚴格執行這一點，從而，理論上，每當對master有一個提交操作，我們就可以使用Git鈎子腳本來自動構建並且發布軟件到生產服務器。
輔助分支
輔助性分支有三個，用后即刪。
Feature：
開發新功能時，以Develop為基礎創建feature分支，開發完成后，要再並入Develop。
分支命名: feature/ 開頭的為特性分支；
命名規則: feature/user_module、 feature/cart_module；
Release：
release 為預上線分支，發布提測階段，會release分支代碼為基准提測；Release分支可能從develop分支分離而來，但是一定要合並到develop和master分支上，一般命名方式為：release/*。
當有一組feature開發完成，首先會合並到develop分支，進入提測時，會創建release分支。如果測試過程中若存在bug需要修復，則直接由開發者在release分支修復並提交。當測試完成之后，合並release分支到master和develop支， 此時master為最新代碼，用作上線。
Hotfix ：
分支命名: hotfix/ 開頭的為修復分支，它的命名規則與 feature 分支類似，線上出現緊急問題時，需要及時修復，以master分支為基線，創建hotfix分支，修復完成后，需要合並到master分支和develop分支；
規則的一個例外是： 如果一個release分支已經存在，那么應該把hotfix合並到這個release分支，而不是合並到develop分支。當release分支完成后， 將bugfix分支合並回release分支也會使得bugfix被合並到develop分支。（如果在develop分支的工作急需這個bugfix，等不到release分支的完成，那你也可以把bugfix合並到develop分支）。
總結
這個管理策略的已經非常好了，可以直接拿來用，但是也沒有必要完全照搬照抄，可以在此基礎上或增或減，適合自己的項目和團隊的才是最好的。用好分支管理，能夠有效的提高版本管理的質量和效率，同時培養開發者思維習慣，讓開發過程更優雅。