奇舞团-前端工程化

规范化、模块化、组件化、自动化
规范化：编写规范：脚本，样式、目录结构

Git

长期分支
1.主分支 master

master 只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
2. 开发分支develop

是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。

短期分支

1. 功能分支
2. 补丁分支
3. 预发分支

git-flow 模式会预设两个主分支在仓库中：master&develop

1. Develop 分支
   这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支

2. Feature 分支
   这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

3. Release分支
   当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

4. Hotfix分支
   当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

初始化: git flow init
开始新Feature: git flow feature start MYFEATURE,创建新分支
Publish一个Feature(也就是push到远程): git flow feature publish MYFEATURE
获取Publish的Feature: git flow feature pull origin MYFEATURE
完成一个Feature: git flow feature finish MYFEATURE 整合到develop分支中
开始一个Release: git flow release start RELEASE [BASE]

• 当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了

Publish一个Release:git flow release publish RELEASE

发布Release: git flow release finish RELEASE

1. 首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。
2. 然后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。
3. 为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。
4. 清理操作，版本分支会被删除，并且回到 “develop”。

别忘了git push –tags
开始一个Hotfix: git flow hotfix start VERSION [BASENAME]
发布一个Hotfix: git flow hotfix finish VERSION

参考：http://www.codeceo.com/article/how-to-use-git-flow.html

模块化
Scoped：为节点添加data-v-version属性
Css in js: 以脚本模式写css样式，
CSS modules：借助预编译使得样式成为脚本中的变量
BEM：手写css，并在模板中增加相应的class

组件化

1. ui 为主：将ui块封装成组件，脚本，样式，模板放在一个文件夹容易维护
2. 逻辑为主：逻辑功能封装成组件

自动化

自动初始（vue-cli），自动构建(webpack)，自动测试(karma)，自动部署(jenkins)