前端又要打tag了，tag真可怜

有很多同学都问过我，每次上线时前端打tag是在干嘛？

现在教育产品部的前端组有着上百个公共组件、模块，被大约6条业务线、共十几个工程使用。这些公共组件、模块并不是一成不变的，它们的代码、彼此间的依赖关系在每个业务线的迭代中都发生着变化。必须要有一个方案，来保证：

其他业务线迭代上线后，自己业务线的线上代码不被影响。因为发生变化的代码意味着不可预测的风险，必须要经过测试验证才能让他们背锅

因此，tag机制应运而生。

1 基础知识

tag

Git 可以对版本库打上标签，形成快照，将来无论什么时候，取某个标签的版本，就可以把打那个标签的时刻的历史版本取出来。对某个时刻打TAG，实际上是对该时刻最新的一次commit提交打上标签，因此TAG就是指向某个 commit 的指针，跟分支很像但是它是不可变的分支。

bower

每个后端同学都经历等待bower update执行的漫漫漫长时间吧。bower是前端的一个包管理工具，可以通过指定包的版本、分支来使用对应的代码。

EDU组件池的每个组件、模块都有一个自己的GIT工程，结合tag和bower，管理它们就变得简单起来了。

2 开发流程

先来设想下，如果只有一个组件，各个业务线之间时怎样协作管理它的呢。

• 多个业务线，通过固定版本号来保证线上代码不受影响

当存在多个组件、且组件之间互相依赖时，协作管理就变得稍微复杂了一些。 大图请戳

• 当组件本身未被修改、且依赖的组件也未修改时，不对它做版本更新。
• 最终上线前，业务工程依赖的所有组件版本都会更新到最新版本。
• 组件本身修改，升级大版本号：0.0.0—>0.1.0
• 组件依赖的组件修改，升级小版本号：0.0.0—>0.0.1
• 当开发过程中，其他业务线上线，在他们上线后，应当将master代码合并到当前分支

整个开发过程中，组件池的主要操作流程在组件池工具的readme中已经写的非常详细。总的来说，在上线前更新组件的版本号并在业务线工程中指定版本号的过程就叫做打tag

3 hotfix流程

注意事项：

1. 从当前业务线线上使用的tag来手动拉取hotfix分支
2. 使用hotfix分支上线，是为了保证其他组件的tag不变，即其它组件的代码不变
3. hotfix分支该怎么拉怎么用，其唯一标准就是上线的代码必须全部通过测试验证

hotfix流程总结如下，假设组件1存在bug需要fix:

1. 确定业务工程使用的组件1的tag，如0.1.0
2. 从该tag下拉取hotfix：git checkout v0.1.0，git branch hotfix/xxx
3. 业务工程的bower.json中，组件1使用#hotfix/xxx

如果组件2依赖了组件1，此时bower update会发生冲突，因为组件2此时使用的时组件1的0.1.0的版本号。需要在resolution中指定组件1使用#hotfix/xxx分支（除了这种情况，业务工程里不应该有任何resolution）

4 组件池工具

在开发流程中，鉴于组件池已经有上百个组件，拉分支、合并代码、打TAG都通过自动化工具来进行。注意事项如下：

• 合并代码

  • 从master合并到开发分支：一般只会发生bower文件冲突，组件池工具会默认解决冲突使用当前分支的bower文件，并提交代码。如果还有其它冲突，需要手动解决。
  • 从一个开发分支合并到另一个开发分支：这种情况一般发生在两个迭代合并上线的时候，有个小问题要注意。合并分支有两个命令"merge:master": "node command/merge.js -f master -m" "merge:compx": "node command/merge.js -c"，迭代合并分支时使用merge:compx，这个命令没有使用-m参数，不会自动解决bower.json冲突，运行的时候记得手动加一下。

• 业务线组件池

组件池中的组件包括公共组件和各个业务线的私有组件： 假设公共组件A、K12私有组件B都引用了公共组件C，某次云课堂的上线，更新了组件C，打tag的时候会更新公共组件A的小版本，并把它依赖列表中的C的版本号更新。但是因为组件B是K12私有组件，对云课堂不可见，此时B的依赖还是旧版本的C。当K12的业务工程同时依赖了A和B的时候，它们所需要的C的版本号不同，则会发生冲突。这种情况只会在打完TAG以后才会发现，需要在TAG上手动更新下组件B对组件C的依赖。

本文来自网易实践者社区，经作者曹阳授权发布。