首先談談分支管理 ：
常用互聯網開發中的分支管理有如下對應關系：
develop ------> 常用開發分支，會頻繁變動
release ------> 測試環境分支， 即產品α版對應的分支，此分支須相對穩定
------> 預發布環境分支， 即產品β版對應的分支， β版與α版分支代碼相同，區別在於β版使用線上數據庫，α版使用測試環境
master ------> 正式環境分支，即產品正式版對應的分支。此分支需要特別穩定， 為正式生產級。
(以上可能各公司不盡相同，但大體是這樣的對應關系)
談完常用分支，談一下分支管理的原則：
盡可能消除merge 與 revert log記錄，盡可能使得git發布路線圖單一。
例如：
這樣的發布路線圖就是特別成功的分支管理實踐。
而下面：
這樣的路線圖關系特別混亂， 是非常不成功的。
接下來談下develop分支開發管理實踐：
開發某一特征或者修復某一bug時，
1先在develop分支（如本地沒有，須從本地remote分支checkout出本地的develop分支）進行git pull命令，或者git fetch； git rebase命令；
2然后進行代碼修改， 代碼修改完成后git commit（如需與上次未push commit合並，請執行git commit --amend）,此操作將修改提交到本地倉庫；
3執行git pull或git fetch ； git rebase；如有沖突解決沖突，然后git commit；
4git push將本地修改推到遠程倉庫；
如果集成了CI，此步操作會自動構建代碼到α版環境；
此時如果測試通過需要構建到 預發布β版環境，則
1切換到release分支（遠程release分支對應的本地分支），git pull;
2 git merge develop；(此操作建立在預發布最新commit與測試環境分支歷史某一刻base相同的情況)；
如果預發布分支最新提交與develop分支沒有任何關系，則考慮此最新提交是否要寫到develop分支，
正常是需要的， 正常開發預發布環境和測試環境代碼須保持一致；包括配置文件；配置文件可以寫多個，
部署時從其中選擇， 做到配置文件不影響代碼倉庫的整潔性。
如果這樣， 可以保證release分支代碼log中不包括merge的log，不包括merge的log可以使提交歷史一目了然，所以代碼管理的原則就是盡量減少merge以及revert等的log記錄。
3 git pull；確保此過程沒有別的用戶在release分支有操作。
4 git push；
如果此過程出現了問題： 比如產生了沖突，或者遇到了產生merge log 以及revert log的情況，筆者經常遇到這樣的情況 ：）. 需要做的是找到一個develop和release分支的base點：
如下圖：
圖中有release分支及develop分支， 最左側為master分支打出的tag。這種情況一定不能merge，需要很好地處理。
1找到圖中划線的基准點，確認基准點上的release分支上的所有提交在develop分支都存在，（如果不存在， 則須手動cherry-pick,一定要按提交順序，以保證不產生merge 和revert 的log， 操作完成后記得執行push操作，因為release分支修改的代碼， develop分支也是一定需要的）
2完成后， 在release分支上執行reset --hard <基准點commit的提交隨機串> （PS:你沒有看錯， 就是--hard，放心， 因為你的代碼在遠程倉庫上是有的， 所以大膽操作吧）
3 release 分支上執行 git push --force 此處一定需要--force，如果不這樣， 本地分支在提交到remote端時會被rebase或者merge而恢復原有release分支的代碼，或者產生merge操作的log， 這項操作就是為了使得遠程分支的代碼強制回退到基准點。
有人一定會問， 那這樣不是丟掉了分支上的代碼么， 對 ， 是的， 確實丟掉了， 但是別急， 因為develop 分支已經將release分支所有不一致的修改提交cherry-pick,所以代碼還是有的， 放心操作吧。
4 release分支上執行git rebase develop ；因為release分支現在最新提交是和develop分支的某一歷史提交， 所以直接執行git merge 操作不會產生任何問題（或者此時執行rebase操作也是可以的， 但是語義上來說git merge比較合適一點）。
5 git push 到remote(最好先pull一下以防release分支有別人的修改)
此時完成預發布環境的代碼構建。
再談一下master分支：
master分支是正式環境，線上環境的分支， 需要保持十分的穩定， 當出現bug時（包括緊急bug）， 不要直接在master上修改， 需要 在develop分支上改完，合到release驗證通過后， 方能合到master。
所以master分支一般情況都是release分支的某一基准點， 所以在master和代碼時，可以直接在master分支，進行git merge release操作。此時不會出現任何問題， 還可以保證代碼倉庫提交歷史的干凈整潔，只有功能和特征的描述；發布release notes時 ， 可以直接從commit messages提取。效果如下：
盡情享受干凈整潔的代碼倉庫帶來的好處吧！