一、我們採用的管理策略（分支開發主幹釋出）   1. 主分支（master），用於釋出，每次釋出時打一個（tag），不做任何開發使用 拉取源：無 合併目標：無 修改：不允許 生命週期：持續   2. 開發分支（develop），每次有新需求時，從（master）拉取建立一個新分支，測試完成後合併到（master），合併後需要重新測試 拉取源：master 合併目標：master 修改：允許 生命週期：合併後刪除（上線穩定執行後再刪除）   3. 測試/預釋出分支（release），開發到某一階段時，建立一個（release）分支提供測試，如果測試期間，對應的開發分支（develop）有修改，則需要同步到（release）分支，或者直接使用開發分支（develop）覆蓋（release）分支 拉取源：develop 合併目標：無 修改：不允許 生命週期：測試完成後刪除   4. 問題修改分支（hotfix），用於修復線上問題，從對應線上版本的（tag）拉取，修改並測試完成後（merge）到（master），在（master）測試完成後，從（master）釋出，同時打一個新的（tag） 拉取源：tag 合併目標：master 修改：允許 生命週期：測試完成後刪除（上線穩定執行後再刪除）     二、GIT操作規範   1. 程式碼修改前，必須先從對應分支PULL最新程式碼   2. 完成程式碼編寫後，COMMIT到本地倉庫，建議經常COMMIT到本地倉庫，以防丟失或者被覆蓋   3. PULL最新程式碼，如果需要MERGE，原則上不允許覆蓋別人提交的程式碼，如果存在衝突的情況，如果不能百分百確定可以覆蓋，需要與相關開發人員共同MERGE   4. PUSH原生代碼到遠端倉庫   5. 程式碼開發階段，不建議頻繁PUSH，如果是公共程式碼或者被依賴的程式碼，完成測試後即可PUSH   6. 對於多人同時開發相同檔案，如果存在開發中但是必須提交的情況，可以先REVERT，修改後COMMIT，然後再從LOCAL HISTORY中將被還原的程式碼拉取出來     三、兩種主流的管理策略   1. 主幹開發分支釋出   得到一個穩定版本後，將此穩定版本放到一個新分支上，針對此穩定版本的修修補補就在這個分支上進行，新功能不在此分支上開發，而在主幹上進行新功能的開發。 這是業界採用較多的模式。 穩定分支上的有些修改，比如缺陷修復，需要合併到主幹， 但有些特定修改，是不需要合併到主幹的。這時需要千萬注意，合併準確的檔案到主幹。 對於不能合併到主幹的情況，常見的是再拉一個分支，這個分支專門為少數特定情況而用，但從全域性講，可能會導致太多分支，不同分支間混亂，所以這並不推薦。推薦寧願採用配置開關。   比如freebsd的釋出就是一個典型的例子。 freebsd的主幹永遠是current，也就是包括所有最新特性的不穩定版本。然後隨著新特性的逐步穩定，達到一個釋出的里程碑以後，從主幹分出來一個stable分支。freebsd是每個大版本一個分支。也就是說4.x，5.x，6,x各一個分支。每個釋出分支上只有bug修改和現有功能的完善，而不會再增加新特性。新特性會繼續在主幹上開發。當穩定分支上發生的修改積累到一定程度以後，就會有一次釋出。釋出的時候會在穩定分支上再分出來一個 release分支。以6.x為例，就會有6.0,6.1,6.2…等釋出分支。【此段摘自於網路 http://thinkernel.bokee.com/4518935.html 】   2. 分支開發主幹釋出   得到一個穩定版本後，拉出先鋒分支，在分支上開發新功能，在主幹上進行修修補補。當先鋒分支通過一定的測試之後，合併到主幹。可以同時有多個先鋒分支，不同的功能可以拉不同的分支，不同釋出時間點而又要同時開發的內容必須在不同的分支上。 從釋出的角度講，更推薦將肯定一起釋出的內容放在相同的先鋒分支上。 主幹上永遠是穩定版本，可以隨時釋出。bug的修改和新功能的增加，全部在分支上進行。而且每個bug和新功能都有不同的開發分支，完全分離。而對主幹上的每一次釋出都做一個標籤而不是分支。分支上的開發和測試完畢以後才合併到主幹。 這種釋出方法的好處是每次釋出的內容調整起來比較容易。如果某個新功能或者bug在下一次釋出之前無法完成，就不可能合併到主幹，也就不會影響其他變更的釋出。另外，每個分支的生命期比較短，唯一長期存在的就是主幹，這樣每次合併的風險很小。每次釋出之前，只要比較主幹上的最新版本和上一次釋出的版本就能夠知道這次釋出的檔案範圍了。 【此段摘自於網路 http://thinkernel.bokee.com/4518935.html 】     四、A successful Git branching model   簡單描述：   1.存在一條主分支（master）。所有使用者可見的正式版本，都從master釋出。主分支作為穩定的唯一程式碼庫，不做任何開發使用。 拉取源：無需。 合併目標：無需。 修改：不允許。 生命期：持續。   2.存在一條開發分支（develop）。這個分支維護了當前開發中程式碼的主線，始終保持程式碼新於master。持續整合、最新隔夜版本的生成等都是基於這個分支。由於當前版本迭代較快，開發分支只提供拉取，不進行實際開發。 拉取源：master。 合併目標：無需。 修改：不允許。 生命期：持續。   3.臨時性多個功能分支（feature）。從develop拉取。開發feature完成，merge回develop。為了降低對其他feature的影響，一般在提測前merge回develop分支。 拉取源：develop。 合併目標：develop。 修改：允許。 生命期：合併後刪除。   4.臨時性多個預釋出（測試）分支（release），用於QA測試。從develop拉取，測試完成merge回master和develop。如果測試期間，有其他版本合併入master，需要同步到release版本，並進行測試。 拉取源：develop。 合併目標：master & develop。 修改：允許。 生命期：合併後刪除。   5. 臨時性多個bug修復分支（fixbug），用於修復線上問題。從master拉取，修復並測試完成merge回master和develop。如果修復期間，有其他版本合併入master ，需要同步到fixbug版本，並進行測試。 拉取源：master。 合併目標：master，develop。 修改：允許。 生命期：合併後刪除。               參考資料： https://nvie.com/posts/a-successful-git-branching-model/ http://www.ituring.com.cn/article/56870 https://www.cnblogs.com/charlesblc/p/6051569.html