Babel 的原理是什么?

参考回答：

babel 的转译过程也分为三个阶段， 这三步具体是：

o 解析 Parse: 将代码解析生成抽象语法树( 即 AST)，即词法分析与语法分 析的过程

o 转换 Transform: 对于 AST 进行变换一系列的操作， babel 接受得到 AST 并通过 babel-traverse 对其进行遍历， 在此过程中进行添加 、更新 及移除等操作

o 生成 Generate: 将变换后的 AST 再转换为 JS 代码, 使用到的模块是 babel-generator

如何写一个 babel 插件?

参考回答：

Babel 解析成 AST， 然后插件更改 AST， 最后由 Babel 输出代码

那么 Babel 的插件模块需要你暴露一个 function， function 内返回 visitor

module.export = function(babel){

return {

visitor:{

}

}

}

visitor 是对各类型的 AST 节点做处理的地方，那么我们怎么知道 Babel 生成了的 AST 有哪些节点呢？

很简单， 你可以把 Babel 转换的结果打印出来， 或者这里有传送门:AST explorer

这里我们看到 const result = 1 + 2 中的 1 + 1 是一个 BinaryExpression 节点， 那么在 visitor 中， 我们就处理这个节点

var babel = require('babel-core');

var t = require('babel-types');

const visitor = {

BinaryExpression(path) {

const node = path.node;

let result;

// 判断表达式两边， 是否都是数字

if (t.isNumericLiteral(node.left) && t.isNumericLiteral(node.right)) {

// 根据不同的操作符作运算

switch (node.operator) {

case "+":

result = node.left.value + node.right.value;

break

case "-":

result = node.left.value - node.right.value;

break;

case "*":

result = node.left.value * node.right.value;

break;

case "/":

result = node.left.value / node.right.value;

break;

case "**":

let i = node.right.value;

while (--i) {

result = result || node.left.value;

result = result * node.left.value;

}

break;

default:

}

}

// 如果上面的运算有结果的话

if (result !== undefined) {

// 把表达式节点替换成 number 字面量

path.replaceWith(t.numericLiteral(result));

}

}

};

module.exports = function (babel) {

return {

visitor

};

}

插件写好了， 我们运行下插件试试

const babel = require("babel-core");

const result = babel.transform("const result = 1 + 2;",{

plugins:[

require("./index")

]

});

console.log(result.code); // const result = 3;

与预期一致， 那么转换 const result = 1 + 2 + 3 + 4 + 5;呢?

结果是: const result = 3 + 3 + 4 + 5;

这就奇怪了， 为什么只计算了 1 + 2 之后， 就没有继续往下运算了?

我们看一下这个表达式的 AST 树

你会发现 Babel 解析成表达式里面再嵌套表达式。

表达式( 表达式( 表达式( 表达式(1 + 2) + 3) + 4) + 5)

而我们的判断条件并不符合所有的， 只符合 1 + 2

// 判断表达式两边， 是否都是数字

if (t.isNumericLiteral(node.left) && t.isNumericLiteral(node.right)) {}

那么我们得改一改

第一次计算 1 + 2 之后， 我们会得到这样的表达式

表达式( 表达式( 表达式(3 + 3) + 4) + 5)

其中 3 + 3 又符合了我们的条件， 我们通过向上递归的方式遍历父级节点

又转换成这样:

表达式( 表达式(6 + 4) + 5)

表达式(10 + 5)

15

// 如果上面的运算有结果的话

if (result !== undefined) {

// 把表达式节点替换成 number 字面量

path.replaceWith(t.numericLiteral(result));

let parentPath = path.parentPath;

// 向上遍历父级节点

parentPath && visitor.BinaryExpression.call(this, parentPath);

}

到这里， 我们就得出了结果 const result = 15;

那么其他运算呢:

const result = 100 + 10 - 50>>>const result = 60;

const result = (100 / 2) + 50>>>const result = 100;

const result = (((100 / 2) + 50 * 2) / 50) ** 2>>>const result = 9;

你的 git 工作流是怎样的?

参考回答：

GitFlow 是由 Vincent Driessen 提出的一个 git 操作流程标准 。包含如下几个关键分支： master 主分支 develop 主开发分支， 包含确定即将发布的代码

feature 新功能分支，一般一个新功能对应一个分支，对于功能的拆分需要比较合理， 以 避免一些后面不必要的代码冲突

release 发布分支， 发布时候用的分支， 一般测试时候发现的

bug 在这个分支进行修复hotfixhotfix 分支， 紧急修 bug 的时候用

GitFlow 的优势有如下几点：

并行开发： GitFlow 可以很方便的实现并行开发： 每个新功能都会建立一个新

的 feature 分支， 从而和已经完成的功能隔离开来， 而且只有在新功能完成开发 的情况下， 其对应的 feature 分支才会合并到主开发分支上 (也就是我们经常说 的 develop 分支) 。另外，如果你正在开发某个功能， 同时又有一个新的功能需 要开发，你只需要提交当前 feature 的代码，然后创建另外一个 feature 分支并完 成新功能开发 。然后再切回之前的 feature 分支即可继续完成之前功能的开发。

协作开发： GitFlow 还支持多人协同开发， 因为每个 feature 分支上改动的代码

都只是为了让某个新的 feature 可以独立运行 。 同时我们也很容易知道每个人都 在干啥。

发布阶段： 当一个新 feature 开发完成的时候， 它会被合并到 develop 分支， 这

个分支主要用来暂时保存那些还没有发布的内容， 所以如果需要再开发新 的 feature， 我们只需要从 develop 分支创建新分支， 即可包含所有已经完成 的 feature 。

支持紧急修复： GitFlow 还包含了 hotfix 分支 。这种类型的分支是从某个已经发

布的 tag 上创建出来并做一个紧急的修复， 而且这个紧急修复只影响这个已经

发布的 tag， 而不会影响到你正在开发的新 feature。

然后就是 GitFlow 最经典的几张流程图， 一定要理解：

feature 分支都是从 develop 分支创建， 完成后再合并到 develop 分支上， 等待发布。

当需要发布时， 我们从 develop 分支创建一个 release 分支

然后这个 release 分支会发布到测试环境进行测试， 如果发现问题就在这个分支直接进 行修复 。在所有问题修复之前， 我们会不停的重复发布->测试->修复->重新发布->重 新测试这个流程。

发布结束后， 这个 release 分支会合并到 develop 和 master 分支， 从而保证不会有代码 丢失。

master 分支只跟踪已经发布的代码， 合并到 master 上的 commit 只能来自release 分支 和 hotfix 分支。

hotfix 分支的作用是紧急修复一些 Bug。

它们都是从 master 分支上的某个 tag 建立， 修复结束后再合并到 develop 和 master 分 支上。

rebase 与 merge 的区别?

参考回答：

git rebase 和 gitmerge 一样都是用于从一个分支获取并且合并到当前分支.

假设一个场景,就是我们开发的[feature/todo]分支要合并到 master 主分支,那么用 rebase 或 者 merge 有什么不同呢?

o marge 特点： 自动创建一个新的commit 如果合并的时候遇到冲突，仅需 要修改后重新commit

o 优点： 记录了真实的 commit 情况， 包括每个分支的详情

o 缺点： 因为每次 merge 会自动产生一个 mergecommit， 所以在使用一些 git 的 GUI tools， 特别是 commit 比较频繁时， 看到分支很杂乱。

o rebase 特点： 会合并之前的 commit 历史

o 优点： 得到更简洁的项目历史， 去掉了merge commit

o 缺点： 如果合并出现代码问题不容易定位， 因为re-write 了 history

因此,当需要保留详细的合并信息的时候建议使用gitmerge，特别是需要将分支合并进入 master 分支时； 当发现自己修改某个功能时， 频繁进行了 git commit 提交时， 发现其实 过多的提交信息没有必要时， 可以尝试 git rebase.

git reset 、git revert 和 git checkout 有什么区别

参考回答：

这个问题同样也需要先了解 git 仓库的三个组成部分： 工作区 ( Working Directory) 、 暂存区 (Stage) 和历史记录区 ( History) 。

o 工作区： 在 git 管理下的正常目录都算是工作区， 我们平时的编辑工作 都是在工作区完成

o 暂存区： 临时区域 。里面存放将要提交文件的快照

o 历史记录区： git commit 后的记录区

三个区的转换关系以及转换所使用的命令：

git reset 、git revert 和 git checkout 的共同点： 用来撤销代码仓库中的某些更改。 然后是不同点：

首先， 从 commit 层面来说：

o gitreset 可以将一个分支的末端指向之前的一个 commit。然后再下次 git 执行垃圾回收的时候，会把这个 commit 之后的 commit 都扔掉。gitreset 还支持三种标记， 用来标记 reset 指令影响的范围：

1 --mixed： 会影响到暂存区和历史记录区 。也是默认选项

1 --soft： 只影响历史记录区

1 --hard： 影响工作区 、暂存区和历史记录区

注意：因为 gitreset 是直接删除 commit 记录，从而会影响到其他开发人员的分 支， 所以不要在公共分支 (比如 develop) 做这个操作。

1 git checkout 可以将 HEAD 移到一个新的分支， 并更新工作目录。 因为可能会覆盖本地的修改， 所以执行这个指令之前， 你需要 stash 或者 commit 暂存区和工作区的更改。

o git revert 和 gitreset 的目的是一样的， 但是做法不同， 它会以创建新的 commit 的方式来撤销 commit，这样能保留之前的 commit 历史，比较安 全 。另外， 同样因为可能会覆盖本地的修改， 所以执行这个指令之前， 你需要 stash 或者 commit 暂存区和工作区的更改。

然后， 从文件层面来说：

o gitreset 只是把文件从历史记录区拿到暂存区，不影响工作区的内容，而 且不支持 --mixed 、--soft 和 --hard。

o git checkout 则是把文件从历史记录拿到工作区， 不影响暂存区的内容。

o git revert 不支持文件层面的操作。

webpack 和 gulp 区别 (模块化与流的区别)

参考回答：

gulp 强调的是前端开发的工作流程，我们可以通过配置一系列的task，定义 task 处理的 事务 (例如文件压缩合并 、雪碧图 、启动server 、版本控制等) ， 然后定义执行顺序， 来让 gulp 执行这些task， 从而构建项目的整个前端开发流程。

webpack 是一个前端模块化方案， 更侧重模块打包， 我们可以把开发中的所有资源 (图 片、js 文件、css 文件等) 都看成模块，通过 loader (加载器) 和 plugins (插件) 对资源 进行处理， 打包成符合生产环境部署的前端资源。