Hello，大家好，今天跟大家分享下关于代码管理相关的内容。
你是否遇到过这样的情况：
1 你在一家软件公司工作，只有零星的两三个开发人员，你们创建了一个svn或git的代码版本管理系统。svn只有一个主干，所有人的代码都直接从主干上更新并提交修改。
1）当销售跟你要一份已发布的应用程序以推销产品时，你将一份已打包好的程序发送给他。
2）此时，测试人员又跟你要最新版的测试版本，你又从现有的开发环境中迅速打包了一份刚刚实现了新功能的测试版本，发给了测试人员。
3）而此时，实施人员又来给你报告了一个发布版的重大bug，需要快速修复。你不得不回退到对应版本以修复bug，而此时你的本地代码不得不先备份起来。
。。。
各种各样的关于版本管理的问题弄的你焦头烂额，你很想一走了之，但又觉得很可惜。虽然使用了svn或git，但却没有发挥其真正的作用。
对于以上这些情况，当一个团队发展到一定阶段时，必须要对应创立一套适合自己的代码版本管理体系，让每个人都能够很好的协同工作，发挥团队最大的效能。这也是团队leader需要特别重视的一个方面。
今天小豆君就来跟大家分享下我是如何管理代码的。
1 代码环境
首先，我们可以根据自己的情况选择git或svn，小豆君推荐使用git，因为git比 svn的分支管理强大太多了。
下图是我绘制的一套基本的环境，你需要根据当前项目及公司预算等条件进行合理选择。
环境部署
- 开发环境（可选）：用于开发新功能，调研新技术等；在开发环境代码提交到测试环境时，可以增加mock测试、基本的自动化测试，只有验证成功之后，才能提交，这也能增加开发的自测自觉性，而对于测试人员自己一定要把握好这个权限，否则自己是很累的。因为某些开发在开发或修改完bug后，觉得测试比较麻烦往往会直接丢给测试；
- 测试环境：给测试人员使用，主要进行日常测试、新功能测试、集成测试等。重要一点，当开发将新功能的代码从开发环境推送到测试环境后，新功能可能需要本地加入一些配置文件等操作，这时应以测试人员为主导，要求开发协助测试进行一次完整的环境配置。这样做的好处是，当测试将代码推送到生产环境时，由于其已经完成了一次环境配置，那他的发布速度就会很快且不容易出现错误，且可以相对的保持环境的一致性，我们看到太多的因为环境不一致而导致发布当天无法顺利进行的案例了，这是我的经验之谈；该环境推荐测试不要给开发分配权限；
- 预发布环境（可选）：预发布是可以由外网进行访问的，且和生产保持一致，但其数据仍是测试数据，以给测试人员进行发布前的最终测试；
- 生产环境：正式环境，也是客户使用的环境。不可轻易变更，必须要有严格的权限控制。
有时，在发布之前我们也可以进行灰度发布。所谓灰度发布，就是少数的一部分客户可以使用新功能，当客户发现产品缺陷后，可以快速回退，避免所有客户都受影响。如我可以先灰度10个客户，当10个客户没有问题后，再灰度100个，当100个没有问题后，再灰度1000个，最后全部放开。但有一点要注意，使用灰度发布时，要注意客户数据留存与回退的问题，所以这是在你选择发布策略时应该考虑的一个因素。
经验：可以根据自己情况合理选择使用几套环境。最基本的，开发和测试可共用一套环境，预发布环境根据情况进行选择。当团队规模扩大，功能不断增多，开发和测试环境又相互有比较大的影响时，可以选择将开发和测试环境分开。环境并不是越多越好，还要考虑到环境维护问题、数据完整性问题，每个环境因为临时修改而出现的数据一致性问题。例如开发环境，如果开发并没有及时维护好，或是没有足够的测试数据，开发就会借用测试环境。长此以往也就没有了维护开发环境的精力。
2 代码分支管理
2.1 名词定义
- feature分支：短期特性分支，某个功能、版本或bug修复的开发分支，开发环境从此构建；
- integration分支：长期集成分支，持续集成多feature的分支，测试环境从此分支上拉取代码构建；
- master分支：长期受保护的主干分支，预发布和生产环境从此分支上取代码构建。只接受合并代码，不能直接提交；
- tag：标签，发布版本后，使用tag打上标签；
- artifact（制品）： 即构建过程的输出物，软件包或镜像。
2.2 操作方法
分支管理模型
1）拉取分支
开发人员从master上拉取分支，分支可以以版本号为粒度，也可以以单独功能为粒度。我一般使用版本号作为分支粒度。命名如，f-{应用名}-{版本号}，例如 f-qq-1.2.0。
如果是修复bug，则可以命名为 f-bugfix-{git提交记录id}-{简述}
2）合并集成分支
feature开发自测完毕，合并feature分支到integration分支。测试进行集成测试，之后拉产品进行验收。
3）合并master
测试通过后，合并feature分支到master分支。开始进行预发布环境测试。
生产验证通过后打Tag
3 版本号管理
对于版本号的设定，我一般采用三位方式
版本号设定规则
主版本号：当应市场要求、或有重大功能发布，或有不兼容的功能需要强制升级时，一般对主版本号进行+1。例如竞品推出了全新的某2.0产品，我们为了在市场上相对好推广一些，可以升级主版本号。
次版本号：正常多个版本迭代时对该版本号+1，例如我们开发的软件每个月进行一次迭代，则可以使用该版本号进行控制
修复号：当我的产品出现bug后，为了修复bug紧急上线，我可以直接从master上拉取代码，使修复号+1，如2.3.1，然后进行发布。
有的可能还使用4位版本号，如带上svn或git的提交id，方便出问题时直接定位到时哪个版本，哪些改动出现的bug。
关于版本号的设定，没有硬性要求，只要合适即可。
4 控制迭代节奏
对于技术人员或技术管理者，每天会接到产品、实施或是上级等诸多的需求意见，需求池永远做不完。而对于提出需求的人来说，每个人都认为自己的需求最紧急，如果管理你管控不住，团队就会因为无穷尽的需求，不停的发布，无节奏的加班拖垮，代码质量更是无法保证。所以这个时候你如何来管控自己的版本迭代节奏，如何为团队创造一个良好有序的开发环境，这是作为领队的你必须要思考的一件事情。
我看到有的管理者是需求方提出一个需求，就响应一个版本，或是同时有多个版本在并行开发。这些都并不是太好的管理方法。
一般我建议，要控制好产品的迭代节奏。
1）控制好迭代周期：例如每两周发布一次或每月发布一次，团队要有一个固定的时间，发布节奏，这样每个组员都会适应并且知道什么时间应该做什么事情，否则组员无法安排自己的工作和生活，代码质量也有待考证。就像长跑运动员一样，如果没有调整好自己的呼吸频率，那很快就会跑不动的。
2）不是所有需求都接：当控制好自己的迭代周期后，那么你就可以根据时间来把对应的需求装入到这个迭代周期中，同时你也要和需求方达成一致，有的需求其实并不是那么紧急。
3）如何建立自己的版本控制体系，并不是照单全收，要根据实际的情况、合适的时间和预算，合理选择。例如在项目初期，并不是要建立完整的环境，有的甚至只有一套环境，适合的才是最好的。但是作为管理者应该提前设计好自己的系统，永远要记住，设计和实施是两个不同的概念，设计的成本是低很多的，提前做好设计，让自己的系统有很大的可扩展性，为客户创造价值是我们所追求的目标。
好了关于版本管理的话题就先分享到这里吧。
微信公众号：小豆君编程分享
头条号：小豆君编程分享
