目前公司配置管理在策略上采用的是不稳定主干（unstable trunk） 模式，所有的项目都在同一主干上进行修改，在每次上线后并没有明确的stable分支版本，基本上是靠测试人员TAG代码来管理维护的。

问题

1）、多个项目组开发人员都可能并发对同样代码进行修改，造成了严重的代码冲突问题。例如张三修改了a.java并上QA测试服务器，在QA测试过程中，

2）、由于没有明确stable分支版本，导致上QA、上生产只能采用增量更新，上QA、上生产出问题后的代码回滚很麻烦，严重影响了测试、上线效率。对于生产环境运行的代码的具体版本并没有明确的管理，导致生产系统出问题后要排查问题也很难查。

3）、由于核心基础包没有与上层应用隔离，导致大家都会对核心包进行修改，修改后代码质量并没有有效控制。于是出现因为修改基础包影响整个系统功能等现象

如何避免，至少要从如下几个方面来：

  • 1）、分支管理策略：采用适当的分支管理策略来保证开发库、测试库、发布库的隔离
  • 2）、适当引入每日编译、持续集成、Code Review等敏捷开发的最佳实践
  • 3）、采用自动化脚本完成上QA、上生产的部署工作，避免人工失误
  • 4）、对核心框架、后台应用、前端页面开发采用不同的配置管理策略

版本管理的策略：不稳定主干策略、稳定主干策略、敏捷发布策略。

下面是对这几种策略的摘录：

不稳定主干策略

image.png

  1. 使用用主干作为新功能开发主线，分支用作发布。
  2. 被广泛的应用于开源项目。
  3. 比较适合诸如传统软件产品的开发模式，比如微软的office等。
  4. bug修改需要在各个分支中合并。
  5. 新代码在主干上开发，因此如果主干不能达到稳定的标准，就不可以进行发布。
  6. 这种策略的好处是没有分支合并的工作量，因此比较简单。


稳定主干策略

image.png

  1. 使用主干作为稳定版的发布。
  2. bug的修改和新功能的增加，全部在分支上进行。
  3. 不同的修改或新功能开发以分支隔离。
  4. 分支上的开发和测试完毕以后才合并到主干。
  5. 主干上的每一次发布都做一个标签而不是分支。
  6. 每次发布的内容调整起来比较容易。
  7. 缺点是分支合并所增加的成本。


敏捷发布策略

image.png

  1. 敏捷开发模式的项目中广泛采用，敏捷开发的项目具有固定的发布周期。
  2. 为每个task建立分支。
  3. 为每个发布建立分支，每个周期内的task分支需要合并到发布分支发布。
  4. 在完成发布后，发布分支的功能合并到主干和尚在进行的任务分支中。
  5. 一种稳定主干策略的变体。
  6. 团队成员要求较高。

团队当前情况

  1. 负责互联网产品的开发，发布更新较为频繁。
  2. 有固定的发布周期，同时也存在比较多的hotfix。
  3. 修改任务通常比较小，改动范围通常不大，时间通常较短。
  4. 不同的功能页面有不同的小组负责，耦合度相对较低。
  5. 团队目前没有采用分支策略，开发人员协商进行增量更新，出现错误的几率较高。
  6. 已使用SVN版本控制工具。

初步实践
参考上述策略，结合当前团队的现状，初步设计了下面的版本控制解决方案。
image.png
此方案已稳定主干策略为主结合了一些敏捷发布策略的思路，具体实施方案如下：
1、主干时刻处于稳定状态，随时可以发布。设SCM人员对主干代码进行管理，普通开发人员只读。
2、SCM为开发任务建立开发分支。常规的可以以小组为单位建立分支，较大的任务可以建立专门的分支。
3、在发布日，从主干复制一个测试分支，需要在本发布日发布的各开发分支向此测试分支合并。
4、对测试分支代码进行测试，出现bug在测试分支上更改，无误后发布。
5、测试分支代码发布后，合并入主干，并在主干上进行标记。
6、对紧急修复（Hotfix）的情况，可以从主干复制出测试分支，在测试分支上进行紧急修改，并在测试后发布，发布后同样将代码合并会主干，做标记。
7、 Hotfix仅限于可以很快解决的小问题，如果更改时间过长，则需采用常规方法完成。
8、如果在测试分支测试过程中需要hotfix工作，则在复制一个新的测试分支进行hotfix，测试后发布。然后同时合并入原测试分支和主干，并在主干上做标记。此过程未在上图中画出。
9、测试分支发布后，开发分支可以删除；测试分支合并入主干后，测试分支可以定期删除。

方案的优缺点
方案优点
1、解决了没有实施分支策略时，代码不能经常签入的问题。
2、主干代码始终处于稳定的状态随时可以发布，降低了风险。
3、可以基于一个完整的测试分支进行测试及发布，而不是以口口相传的方式增量更新。
方案缺点
1、建立分支、合并分支增加了工作量。考虑实际情况，以及版本控制工具的辅助，增加的工作量应该可以接受。
2、如果某些开发分支工期跨越多个发布周期，修改过于剧烈，合并分支时可能工作量较大。可以考虑分解任务，避免过大的任务出现。
3、在同一时间最好只有一个测试分支，因此建立测试分支的权限需要限制，除hotfix场景外应当避免。

最佳实践

介绍
每个人使用 Git 有不同的使用习惯，无所谓对错，但是涉及团队协助，必须有一个统一的规范。
参考了TBD、GitHub Flow、git-flow 以及 AoneFlow 等不同分支管理策略，我们制定了此规范，特点如下：

  • 操作简单，不要像 GitHub Flow 这么复杂；
  • 可以确认任何时间发布的版本；
  • 如果有重大 bug，可以快速回滚到上一个稳定版本；
  • 修复紧急 bug，可以快速修复，而不用发布不该发布的内容；

分支
每个项目的有且只有 master 和 release 两个永久分支，开发中会用到 feature 和 hotfix 临时分支。
master分支
开发分支，所有开发的代码都须合并到此分支。
release分支
产品发布分支，主要用于发布产品版本。
feature分支
特性分支，每当开发新功能从 master 分支拉出。为了不重名，feature这么命名：feature/用户代号-模块名-子模块（如果有的话）
hotfix分支
bug修改分支，发布版本有bug的时候，可以从 master 拉出分支进行修正。每一个bug都要提交到工单中，工单都有一个数字的id，hot分支可以这么命名：hotfix/issue-工单id

tag 命名

  1. tag 只针对 release 分支，别的分支不需要打 tag。
  2. 客户端程序（如 App、小程序）遵照 major.minor.patch 的命名，如 2.3.1。
  3. 服务端程序（如 Api 接口、后台管理系统）以发布的日期命名，如 2018.5.20。
  4. 如果有 bug 修正，第 2 条直接最后发布号+1，如果上一个 tag 是 2.3.1，这个 tag 应该是 2.3.2，如果是日期命名，在后面增加小写字母，如 2018.5.20 后是 2018.5.20a，然后是 2018.5.20b。

新功能开发流程

  1. 从 master 分支创建 feature 分支；
  2. 开发调试完将 feature 分支提交到远程版本库；
  3. 提交 pull request 请求合并到 master 分支；
  4. 相关负责人 code review 后如果同意合并后，删除远程 feature 分支，如果不同意，重新修改后再上传 feature 分支请求 pull request。

发布流程

  1. 确保所有要发布的 pull request 已经 merge 到 master；
  2. 使用 master branch 的代码进行测试，如果发现 bug，把对应的 bugfix merge 到 master；
  3. 从 master 分支 git cherry-pick 过来新功能的 commit或者直接从 master 拉出（具体取决于 master 分支是否有不在本次 release 的commit，如果没有，直接 merge，如果有，就 cherry-commit）；
  4. 测试并发布 release；
  5. 发布完成后打上版本 tag。

Bugfix 流程
这里的 bugfix 指的是修复已经发布的程序（release branch）中的缺陷。master 里的 bug 请直接 merge bugfix 到 master。
如果发现 bug，请先提交到工单系统。

  1. 如果此缺陷在 master 中还存在，请先 merge bugfix 到 master，否则跳到下一步；
  2. 在 release branch 从 master cherrypick 修复该缺陷的一个或多个 commit；
  3. 发布当前 release branch；
  4. 发布完成后在当前的 release branch 打上递增的 tag。

、