如果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。
修改：允许。
生命期：合并后删除。
