这只是一份关于 Feature Branch Workflow 实践的建议。

Feature Branch 命名规则

采用 ^(feature|bugfix|hotfix)/\d+-[\w-]+$ 来命名分支，其中：

  • feature 新功能
  • bugfix 针对 master 主分支的 bug 修正
  • hotfix 针对特定标签版本的 bug 修正
  • \d+ Coding.net 上的项目讨论 id
  • [\w-]+ 具体的分支名

示例：

  • feature/123-new-user 一个新功能，讨论 id 是 123，功能是新用户；feature 理论上是相互独立的
  • bugfix/456-user-name 一个 bug 修正，讨论 id 是 456，修正用户名称相关的问题；bug 也会影响到其他 feature 分支
  • hotfix/789-server-config 一个热修复，讨论 id 是 789，修正服务器配置问题；需要优先处理

当团队出现超过十个并发分支进行开发时，规范的命名分支名称方便团队有效使用分支。 分支名以 hotfix 和 bugfix 开头更能提示团队成员优先处理（评审）相关分支，并且建议团队成员将其合并到各自当前工作的 feature 分支进行测试反馈。 分支名中的讨论 id 便于团队成员了解变更内容，具体的分支名需要简明扼要的描述变更。

使用 tag 标签发布正式版本

master 主分支默认使用 CI 部署到 staging 预发布服务器，以供内部人员（产品/测试）审阅。 正式的 production 生产服务器只部署 git tag 发布的版本。

正常的发布流程是在 master 上验收之后，使用 git tag 命令或在 Coding.net 网站增加标签。 标签使用 ^\d{4}\.\d{1,2}\.\d{1,2}(\.\d+)?$ 命名，其中前三个数字是当前发布时间的年、月、日，最后一个数字当天发布的累计次数，默认不需要。 如 2017.4.11、2017.4.11.1。

一般来说，中小型网站应用只需要维护一个生产版本。但实际的需要，如因为产品验收导致的预发布与生产环境分离，或者无法让使用者有效确认当前发布的版本等等。 就需要正式发布采用 git 增加标签来发布，并指明版本。

同时，若非必要，指明版本还可以支持生产环境发布的撤回与切换。

Hotfix 热修复

Hotfix 热修复与普通的 bugfix 不一样，bugfix 是针对 master 主分支，而 hotfix 是针对 git 标签。Hotfix 分支是从指定 tag 上检出。 虽然也需要提交合并请求到 master 主分支，但其在合并操作之前，评审通过之后，在其分支上直接增加 git 标签。

这样做的目的是避免 master 主分支上未正式发布的代码污染生产环境。

避免大的合并请求

项目的所有代码都需要经过合并请求中评审 review 过程。 最保守的方案也需要团队中有人对所有代码负责以便需要时能有人来解决问题。

激进的方案是团队中所有人都参与到评审中，各负其责，每个人评审的目的是不同的。 有的人可以通盘掌控，有的人需要仔细审查项目中的部分代码，有的人只需要检查代码注释与文档。

所以，要避免大的合并请求，代码、注释、讨论、合并请求说明乃至 git 提交日志都需要方便审核。

一般来说，Bugfix 分支的目的是解决问题，Hotfix 分支更为激进，甚至可以直接了当的通过删除代码来解决问题。 Feature 分支会相对复杂，但也不能过分复杂。

对于复杂或庞大的新需求，需要合理的拆解成多个小需求，转换成多个 feature 分支，多个合并请求。 因为 master 主分支已经与生产环境脱钩，所以每个小的 feature 分支都需要尽快建立合并请求， 尽快进行团队评审，尽快合并到 master，尽快发布给内部人员审阅。

团队协作

团队协作加快开发速度的关键在于合理的拆分需求到不同的 feature 分支，理想境地是不同分支互不干扰，齐头并进。但这几乎是不可能的。

基于避免大的合并请求理念，团队中每个人实际上分配到的都是多个小需求。 这其中包括一个完整功能开发的不同阶段分成多个 feature 分支，这些分支存在先后顺序，分别由团队中不同角色的成员去开启，去完成。

这些更加考校团队成员对需求的理解与相互之间沟通的能力。还好，我们有很好的评审渠道去加强沟通。

所以，增加团队成员是可以提高生产力，但不是绝对。但可以确定的是，一群好的团队成员不仅能提高生产力，更能带来更好的质量。

团队协作更注重于团队中成员的互补性，相互之间的配合。

实现大规模需求与重构

项目中很多时候都不得不迎来很大的新功能实现、变更甚至整个项目的重构。 这时候，我们需要一个新的主开发分支甚至一个新仓库。

有资源的团队最好是从主仓库派生一个新仓库来实现大的变更。

当然，也可以采用从 master 分支检出一个新的开发主分支。 这个分支既不是 feature 分支也不是 bugfix 或 hotfix 分支， 而是与 master 同等地位，直到它能通过合并请求合并进 master。

所以，该分支可以直接命名，比如 new-structure。

在合并进 master 分支之前，此分支和 master 一样也可以接受来自 feature 分支和 bugfix 分支的合并请求。 仍然使用我们已有的工作流，只不过换了对象。

需要注意的是，同时维持多个 feature 分支向两个不同的主分支提交合并请求是很危险的事情。 它会加大新的开发主分支回到 master 的风险。

在回到 master 之前，只对 master 分支做有限维护，比如 hotfix 是最好的。

一个人的评审

大多数项目实际都只有一个开发成员，但此时，评审仍然不可或缺。

所以，即使是一个人的项目，也要采用本工作流，老老实实的在合并请求中自己做评审。

你可以交替多个 feature 分支，分别开发，然后评审上一个提交的 feature 分支。

良好的评审习惯，会很快提高自己的代码质量。

而且，不管是对于个人还是项目来说，都是和团队开发一样的开发模式。