开发分支的管理
- 先确定各开发分支feature发布的先后关系。
- 无法确定先后的两个开发分支，应该从相同的分支节点，新建分支进行开发。
- 开发分支管理人员，应确认当前开发分支所依赖分支，即那个分支开发完成发布后，然后紧接当前分支开发完成后发布。那个分支是当前分支的依赖分支。
例如，feature2需要在feature1发布后，紧接着发布。feature1是feature2的依赖分支。
依赖分支可以有多个。
例如，feature1需要在feature2和feature3发布后，紧接着发布。那么，feature1，feature2是feature3的依赖分支。 - 依赖分支有新提
交时，管理人员应及时合并到当前开发分支。
根据依赖程度（两分支的交叉程度），以适当的频率来合并。 - 当依赖分支完成发布后，应立即将代码合并至主分支，依赖分支结束生命周期（不能往该分支提交代码）。全部依赖分支都发布，合并到主分支后，依赖分支变成主分支。
- 当依赖分支为主分支时，主分支有任何提交应立即合并到当前开发分支。
- 当依赖分支为主分支时，需要一个紧急版本，并该版本优先发布，这时依赖分支由主分支变为该紧急分支。
单一依赖
多依赖
这种多分支管理方式优点：
- 合并到主分支代码无冲突，确保主分支都是发布的代码。
- 冲突解决在各自开发分支，确保每次代码变动都会被测试到。
- 减少开发分支管理干扰，只关心自己依赖的分支。
成员分支的管理：
1，开发成员请求代码合并时，管理人员将该开发人员的个人分支合并到当前项目分支。该开发成员停止提交代码到远程。
2，管理人员合并代码完毕后，通知到该成员拉取最新代码并开始可以提交代码到远程。
3，该成员接收到合并代码完成的通知后，应拉去项目分支代码。并将个人分支rebase到项目分支，并推到远程。然后继续开发和维护个人的本地和远程分支。
集中式
这种成员分支管理方式优点：
- 项目管理人员在合并代码和解决冲突，会有简单的Code Review。
- 加强了项目管理人员的整体把控。
- 代码的可追溯性更强了。
具体各分支变化可以参考keynote《git代码管理方案》。
