软件开发的同学离不开代码管理，git提供了工作流支持，github提供了仓库&管理(当然还有其它一些免费或者收费的代码仓库)。
实际工作过程中，管理人员一般会根据项目实际需求来自定义一套适合协同开发的标准流程，以减少或者避免代码冲突和事故，把风险降到最低。与此同时，还要清晰地确定开发、测试与发布流程，敏捷开发、快速迭代，保证整个项目成功上线。
仓库代码的分支介绍
代码仓库：master主干分支
开发：dev分支、feature分支(临时性)
测试：test分支、hotfix分支(临时性)
发布：release分支、特别定义的发版分支(临时性)
仓库代码的架构设计
一般中大型项目(3人以上)，一层代码管理架构，建议设定四个分支：release-master-test-dev；二层代码管理架构，建议基于一层基础上增加临时性分支(可选择)：feature-hotfix-spec分支，如我现在正在进行的项目就采用了如下架构：
若是基于1~3人开发维护的小项目，则可以简化工作流(如下)，没有必要搞得那么繁琐，这样减少维护成本，提供工作效率。
1）首先，砍掉二层架构的临时性分支
2）其次，把开发分支与测试分支合并，完全可在本地编译、自测、联调通过后，再上传到dev分支
3）最后，再协同开发时，主要提交代码时开发人员间及时代码同步+冲突解决
若是1人开发并维护的个人项目，则可以超简化工作流(如下)，进一步把master与release分支合并，最终仅保留master+dev分支
代码仓库的CI&CD
代码最终要经过内部测试与上线公测来检验其好坏强弱，并通过不断进行地迭代、集成、发布才最终形成优秀的产品，这就需要进行持续的版本管理。
一般采用jenkins工具来做CI&CD，监控持续重复的工作并进行追踪管理。CI的触发原则上遵循以下条件：
1）发布分支(release/master)：强制在线触发CI，并附带tag+version迭代
2) 其它分支(dev、test...)：根据实际需要，可选择性手动触发CI，并附带comment
