如果git(icode)不加管理，可能出現枝節蔓生、四處開放的版本庫。到處都是分支，完全看不出主干發展的脈絡，造成下圖的局面：
為了降低合並和版本管理的成本，團隊引入一種值得借鑒的管理方式（link）
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。
修改：允許。
生命期：合並后刪除。
4. 臨時性多個bug修復分支（fixbug），用於修復線上問題。從master拉取，修復並測試完成merge回master和develop。如果修復期間，有其他版本合並入master ，需要同步到fixbug版本，並進行測試。
拉取源：master。
合並目標：master，develop。
修改：允許。
生命期：合並后刪除。
以上內容，參考了文章：
http://nvie.com/posts/a-successful-git-branching-model/
http://www.ruanyifeng.com/blog/2012/07/git.html