如圖步驟1， master對開發者只有讀許可權，開發者從master拉取並新建feature_***x分支進行開發
如圖步驟2，開發完成後，提測時，基於feature_***x分支新建release_1_0_0分支，並把其它feature分支合併到release_1_0_0分支中。
如圖步驟3，release_1_0_0分支測試完成後，設定分支寫保護。發布完成後。將release_1_0_0分支合併/覆蓋回master,並在master中建立標籤release_1_0_0
如上面所示，開發中遇到線上bug, 則基於release_1_0_0建立hotfix_1_0_0_關於***的修復。合併到release_1_0_0中並發布，發布完成後要合併到master中並建立標籤[release_1_0_0_with_hotfix_關於***的修復]
然後，如圖中release_2_0_0已經提測，那麼就要將hotfix也合併到該分支中。如果release_2_0_0還未提測，即該分支不存在。那麼要將hotfix合併到【feature 下一迭代需求集】的至少乙個分支中。即保證下一代分支中包含了該hotfix.
jenkins中拉取的每個迭代的release分支進行測試、生產環境的部署。所以每次提測，發布，需要修改jenkins中拉取的位址。
少部分人員擁有master的管理許可權，對分支進行寫保護操作的許可權。在生產發布後，要對release分支進行寫保護，並對master分支進行合併，打標籤操作。
乙個迭代在測試中時，不能進行另乙個新的迭代的開發，即迭代無法並行。因為master是基於上一版本的release建立的，是新一版本的基準。
在該模式中，master扮演了當前生產執行版本與下一迭代基準版本的角色，並在其中打標籤的操作，也保證了master記錄下了整個版本歷史。如同乙個備份。
release_1_0_0, release_2_0_0…分支累積的過多時，可以將過久的一些加以清除。
git分支實踐
本文基於這樣乙個場景 有多個新功能並行開發，按先後順序上線，但是偶爾會出現正在測試的版本暫停上線，另外乙個緊急功能需要優先上線。本文分享乙個用git分支來管理這樣的場景。本文基於 主要分支 倉庫中有兩個長期的分支 master用作生產分支，裡面的 是準備部署到生產環境的。develop是可交付的開發...
Git分支最佳實踐
本文介紹我一年前在自己的專案 包括工作專案和私人專案 中引入的git分支模式，這個模式很成功。主要分支 倉庫中有兩個長期的分支 master develop master用作生產分支，裡面的 是準備部署到生產環境的。develop是可交付的開發 也可以看成是用於整合分支，每晚構建從develop獲取...
git 分支管理
一 遠端倉庫有master和dev分支 1.轉殖 git clone 這個git路徑是無效的，示例而已 2.檢視所有分支 git branch all 預設有了dev和master分支，所以會看到如下三個分支 master 本地主分支 origin master 遠端主分支 origin dev 遠...