前端工程化问题

1. Babel的原理是什么？

   1. Babel 的主要工作是对代码进行转译。(解决兼容，解析执行一部分代码)

   2. 转译分为三阶段：

      1. 解析(Parse)，将代码解析生成抽象语法树 AST,也就是词法分析与语法分析的过程

      2. 转换(Transform） ,对语法树进行变换方面的一系列操作。通过 babel-traverse，进行遍历并作添加、更新、删除等操作

      3. 生成（Generate），通过 babel-generator 将变换后的 AST 转换为 JS 代码

   3. 常见babel插件：

2. 公司的Git工作流

   1. 每个公司采用的Git 工作流都可能会有差别,有的比较规范,有的比较随意。 目前主要使用GitFlow 的 git 标准化操作流程。

   2. 在 GitFlow 标准下，我们的 git 仓库需要包含以下几个关键分支:

      1. Imaster：主分支

      2. develop:主开发分支。包含确定即将发布的代码

      3. feature：新功能分支。一个新功能对应一个分支

      4. release：发布分支。发布时用的分支，一般测试阶段发现的 bug 在这个分支进行修复

      5. hotfix：热补丁分支。用于修改在线上版本中发现的严重紧急 bug

3. Git的rebase和merge的区别是什么？

   1. git rebase 和 git merge 两个命令都用于从一个分支获取内容并合并到当前分支。

   2. merge 会自动创建一个新的 commit，如果合并时遇到冲突的话，只需要修改后重新 commit 。

      1. 优点:能记录真实的 commit 情况,包括每个分支的详情

      2. 缺点:由于每次 merge 会自动产生一个 merge commit ,因此在使用一些可视化的git工具时会看到这些自动产生的commit,这些 commit 对于程序员来说没有什么特别的意义,多了反而会影响阅读

   3. rebase 会合并之前的 commit 历史。

      1. 优点：可以得到更简洁的提交历史，去掉了 merge commit

      2. 缺点:因为合并而产生的代码问题,就不容易定位,因为会重写提交历史信息

   4. 建议

      1. 当需要保留详细的合并信息,建议使用 git merge ,尤其是要合并到master上

      2. 当发现自己修改某个功能时提交比较频繁,并觉得过多的合并记录信息对自己来说没有必要,那么可尝试使用 git rebase

4. Git 的 reset 和 revert

   1. reset => 回退到某个版本 git reset-hard 版本号

   2. revert => 撤销某个版本内容的内容修改git revert -n 版本号