转Git仓库分支(Branch)和标签(Tag)

仓库的分支(Branch)规范，影响到每一个团队的工做流的一致性；标签(Tag)便于开发团队、测
试团队和其余团队识别每一个项目的版本，特别是在协同处理线上问题的时候，你们能够很是清楚
地知道线上运行版本和代码库的对应关系。所以咱们在制做的时候，主要考虑几个因素：

• 一是要有必定的规则，方便持续集成CI（自动化构建、测试、分布等）
• 二是要有必定的自由度，以适应不一样团队的内部协做灵活性
• 要清晰规整，不要良莠不齐难以识别

基于咱们当前团队的协做能力和提交代码的质量水平，并考虑方便持续集成CI（自动化构建、
测试、发布），咱们约定下列常驻Branch：

• develop 分支：顾名思义即持续开发的分支，咱们但愿每一个开发组都在这个分支上保
  持线性的持续小步迭代，正常的CodeReview WorkFlow和开发级的自动CI也在这里进行。
  当开发完一个迭代(Sprint)，开发小组有信心转测时，就将代码合并到 release 分支，
  并要求打一个alpha级的Tag(如5.2.0-alpha)
• release 分支：顾名思义即用于发布过程的分支，包括开发转测(实际上咱们认为这里的测试集成测试)、测试和BugFix以及发布上线的过程，当发布成功时要打一个发布beta Tag(如
  5.2.1-beta)，并将代码合并到 master 分支
• master 分支：即有质量保证的、可安全运行的分支，禁止直接代码提交，避免被污染，仅用
  于代码合并和归集，在这个分支上的代码应该永远是可用的、稳定的。当须要拉一个特别的开发分时，
  应该基于 master。

当须要fix线上的一个问题是，应该基于上线时的那个beta Tag作hotfix。当出现线上Bug须要hotfix时，咱们须要在上次上线的Tag处拉一个临时的 hotfix 分支进行
修正，或者在未被其余开发迭代污染的release分支上直接hotfix上线并合并到master和
develop，而后打一个新的Tag(如5.2.2-beta）

这个分支体系是咱们指望长期持续迭代的分支规划，其它临时分支的删除、建立、命名，都由团队本身
决定，保持必定的灵活性。但每一个团队都应该努力避免对上述常规状况形成破坏的状况发生，若是有特
殊状况（若有两个并行的开发分支同步进行），须要由各组Leader和QA团队协商提供临时方案，这会
影响到团队协同中的转测、CI基准分支等。

关于打 Tag 的规则 ：

鼓励开发和QA团队共同对勤于打Tag，这便于真正的版本管理，避免有rollback须要或者须要查看和
对比历史版本的时候的混乱和低效局面。但同时也要求必定的规范性，让人一看便知。

Tag格式为： MajorVersion.MinorVersion.FixVersion-TypeLabel，其中TypeLabel
为 alpha、 beta、 devel。具体参见下图举例，其中devel是留给开发过程当中
使用的。

分工上，开发团队负责打 tag-alpha，测试团队负责打 tag-beta。

可是，本身决定并不意味着胡乱命名，你们仍然要以 语义明（白）（准）确 的原则
来管理本身的分支和标签名，由于全部这些都是为了提升协做效率。

这是一个参考示意图：

事实上，上图和经常使用的 Git 分支实践是比较类似的，只是为了方便自动化工做，咱们将 release 分支常驻并配合 tag 管理了，其余工做的 workflow 基本类似，以下图：