工作流与规范化

在工作中，用一个分支来处理开发、测试、发布、线上hotfix等等流程是难以控制的：项目上线前你只想让其他人提交一个小修改，结果fetch下来的是另一个人为下次上线提交上来的几百个文件修改。

这里介绍利用git分支的特性避免这种情况的一种做法：

1.1.永久分支

首先，git远程版本库有两个永久分支，master与develop。 develop分支包含开发过程中最新的提交变更。有人会称之为“集成分支”。该分支是自动化每日构建的代码源。当develop分支上的源码到达一个稳定的状态时，就可以发布版本。所有develop上的变更都应该以某种方式合并回master分支，并且使用发布版本号打上标签。每次有变化被合并到master分支时，这就是一次新的产品版本发布。

1.2.临时分支

临时分支是开发或者发布过程中被创建、一段时间后再删掉的分支，同一时间内可能会有多个临时分支在并行工作。

1.2.1.feature

作用：开发新的功能
分支来源：develop
分支结束时合并到：develop

特性分支（有时也被称作topic分支）是用来为下一发布版本开发新特性。当开始开发一个特性的时候，该特性会成为哪个发布版本的一部分，往往还不知道。特性分支的重点是，只要特性还在开发，该分支就会一直存在，不过它最终会被合并回develop分支（将该特性加入到发布版本中），或者被丢弃（如果试验的结果令人失望）。特性分支往往只存在于开发者的本地仓库中。

1.2.2.release

作用：准备发布新版本
可能的分支来源：develop
分支结束时合并到：develop和master

发布分支为准备新的产品版本发布做支持。它允许你在最后时刻检查所有的细节。此外，它还允许你修复小bug以及准备版本发布的元数据（例如版本号，构建日期等等）。在发布分支做这些事情之后，develop分支就会显得比较干净，也方便为下一大版本发布接受特性。从 develop分支创建发布分支的时间通常是develop分支（差不多）能反映新版本所期望状态的时候。至少说，这是时候版本发布所计划的特性都已经合并回了develop分支。而未来其它版本发布计划的特性则不应该合并，它们必须等到当前的版本分支创建好之后才能合并。正是在发布分支创建的时候，对应的版本发布才获得一个版本号——不能更早。在该时刻之前，develop分支反映的是“下一版本”的相关变更，但不知道这“下一版本”到底会成为0.3还是1.0，直到发布分支被创建。版本号是在发布分支创建时，基于项目版本号规则确定的。

1.2.3.hotfix

作用：修复发行版bug
分支来源：master
分支结束时合并到：develop和master

热补丁分支和发布分支十分类似，它的目的也是发布一个新的产品版本，尽管是不在计划中的版本发布。当产品版本发现未预期的问题的时候，就需要理解着手处理，这个时候就要用到热补丁分支。当产品版本的重大bug需要立即解决的时候，我们从对应版本的标签创建出一个热补丁分支。使用热补丁分支的主要作用是（develop分支上的）团队成员可以继续工作，而另外的人可以在热补丁分支上进行快速的产品bug修复

This work is licensed under a CC A-S 4.0 International License.