Erik

由于你的工作，让 call 表达式支持后，代码依旧小于14k，所以3.7.0暂缓，发3.6.11

支持的

@Dafrok 没想好怎么插，哪里能插。 所以这个例子，我在2天内给出答复

两天过去了，关于这个问题，我还是一脑袋浆糊

团队内部现在有脚手架，但是普适性还不够，就没open。要做的事情比较多，所以没赶上。

这货为啥不是在ecomfe/spec下的issue...

总的来说，我觉得： 1. 需要规范开发过程 2. 这个过程有点复杂 具体我的问题如下： 1. 分支name建议以`-`分隔，我们知道git会出现origin/master这样的分支代表远程分支的本地映射，用`/`分隔容易凌乱 2. 功能分支和开发分支是否有些职责重复，是否需要区分这么细？如果按照现在的说明，我们很可能`建立开发分支`-`建立功能分支`-`开发功能`-`切换开发分支`\- `合并功能分支`-`干掉功能分支` 3. 发布是否有些麻烦？现在看来，如果不发布到npm，没人用的话，bug也看不出来。如果有bug，要修复，npm也必须增加版本号。我觉得，发布后如果发现紧急的BUG，需要修正，也应该是up patch version。如果是这样，那现在的发布流程就有些不必要

### 关于功能分支 好吧，确实会有1和3这种情况出现，但是当多个feature同时开发时，如果有多个分支，可能会出现后来的分支需要手工merge的情况。2不是问题，我觉得2是每个开发者都需要保证的。 所以我觉得，这个可以有，但是需要对开发分支和功能分支的作用和使用场景，做一些简单的说明。比如什么场景需要用，什么场景就算了。 ### 关于release 我认同要保证的两点，不过我通常的做法是，dev测试充分后，打tag，master merge。这样就代表了一个发布。相比之下，我没看出一个release分支的好处？

1. 我认为这个不是理由，找不到tag就去找药 2. 从release分支接hotfix是从最近的release还是以前的release？

我其实一直没有完整的走过git flow，因为，感觉实在是有点重