简单项目的开发
先回顾一下简单项目的开发。放松点，咱们随便聊聊
如果项目很简单，当然不需要用这几个概念，只知道trunk就行了，拿SVN做个文件备份的机器而已。
这里“项目很简单”指的是：
1）通常由一个人开发。
2）瀑布式开发很明显，稳步推进。在现有需求的开发过程中，不会突然插入一个需求急于上线 。
3）即使上线出问题，有时间修复，并不是要求软件7*24小时高可用
下面讨论“复杂点儿的项目”**
什么是复杂点儿的项目呢？
1）通常由多人协作开发
2）迭代很频繁，比如2周一次
3）在第一次上线后经常面对bug线上修复和主干分支开发同时进行！
4）公司项目和产品线很多，回头这个项目的一些需求和细节靠个人记忆力都忘了
5）公司对软件质量有一定要求。出现质量问题要严查负责人。
假如你的项目的某个版本（例如1.0版本）已经完成开发、测试并上线了，接下来接到新的需求，新需求的开发需要修改多个文件中的代码，当需求已经开始开发一段时间的时候，突然接到用户或测试人员的反馈，项目中有个重大bug需要紧急修复，并且要求bug修复后要立即上线；此时应该怎么修复bug呢？是在当前已经开发新需求的基础上进行修复吗？答案是否定的，原因是：如果是在已经开发新需求的基础上进行修复bug，那么新需求还没开发好，更没有测试，怎么立刻（或最可能快的）上线？！再次如果新功能的开发和bug修复的代码都涉及到同一段代码冲突了怎么办 。很显然不能在当前开发的代码基础上进行bug修复工作完美的解决方案是：在当时完成的那个版本中进行bug fix，这样带来的好处是： 1：bug修复好之后可立即上线，不会因为新需求还没有完成或测试而延迟上线时间
2: bug修复是在原来上线的那个版本进行修复的，引起新bug的风险小，如果是在新需求的基础上修复bug, 那么新功能可能会带来新的bug
关于trunk/branch/TAG的概念
trunk(****主干|主线) branchs(分支) tags(标记)
truck(主干|主线|主分支)：是用来做主方向开发的，新功能的开发应放在主线中，当模块开发完成后，需要修改，就用branch。 branch(分支)：分支开发和主线开发是可以同时进行的，也就是并行开发，分支通常用于修复bug时使用
tag(标记)：用于标记某个可用的版本，可以标记已经上线发布的版本，也可以标记正在测试的版本，通常是只读的
所以，我们怎么活用活用呢？
1. 严格项目开发流程，定好迭代周期
项目是可以分阶段的。
每个阶段，例如1.1版本做什么，项目起止日期是多少？ 是要书面写文档规定下的。而且项目例会通过的。
2. 明确发布时点并开branch
在发布之前，本阶段开发内容基本完成后。要从trunk中branch出来，把branch测试并发布。例如，要发1.1版本了，从trunk出先branch个1.1出来。
这里什么时候branch出来是个技术活和沟通活。如果branch早了会发生什么呢？branch做不少改动，都要merge会trunk。 而trunk有些特性也要merge回相关所有branch。很累并且容易出错是不？ 我们认为，在这方面没有银弹(Silver Bulets,《人月神话》所提及)，它依赖于项目组成员的智慧和沟通。
3. 上线版本必打TAG
凡是测试后上线的版本，必打TAG,这里TAG还不如认为个Snapshot(快照)呢。 因为一旦线上出问题，第一个事是直接去翻看TAG,看源码，测试，而不是去branch去翻看log, 猜测哪个是我们发布的（如果万一没写好log，那是分不出来的）
TAG这件事，让我们在软件发布时，很有仪式感，仪式感是无言的沟通。
当然，不仅上线可以打TAG,提交内部质量部门测试也可以打TAG. 这是灵活的。工具是死的，人是活的。
4. trunk继续开发
trunk是一直支持最新特性的。是最新版本但未必是最稳定的版本。
5. 外部问题碎碎念
1）市场说，请给我赶快发布一个最新版本
请注意，不要上当。并不是把trunk编译个，简单一测试，就给市场了。
我们应该自我翻译好，市场的意思应该理解为，给我一个最新并稳定的版本。当然，需要质量部门测试的。否则出了质量问题，有你好看。
2） 产品经理说，这个功能马上实现
我们当然需要冷静一下，一切按程序来。但按程序并不是消极，而是要有章法。
我们把产品经理提的需求分解，细化设计，并根据发布周期决定要投入到哪个版本。例如现在线上版本是1.1. 如果新加的需求很急，可能在1.1的branch上先改，然后内测。测试基本没问题了，就打TAG出来发布。 最后呢，把branch上的改动merge回trunk里
THE END