前言本文属于《前端工程化系列》的标准规范介绍。本系列主要介绍我们一整套的前端工程解决方案。文章将从浅到深介绍如何实现前端工程，以及一套开箱即用的开源前端工程解决方案。文章主要针对中小型团队和新手。我们希望我们的一整套工程道路和解决方案能够帮助团队和开发者提高效率。审核标准提交审核前，请务必仔细阅读您修改的模块以及设计对相关业务的影响。不要将未经开发者自检的代码提交给review。如有必要，请写清楚评论。审稿人需要清楚地理解它。如有需要，请在commit中标注具体需求的开发任务。请参考评论#issue_ident。请务必在提交评论前运行测试，或完成自测，以减少重复提交评论的次数。请不要选择超过4个如果能尽量保持2个高级+1个初级，高级程序员可以为你的代码提供建议，初级程序员可以从review中快速成长和成长熟悉项目Codereview是绝对优先考虑的。我们提倡的原则是，当团队中发生代码审查时，往往是团队成员需要发布某个功能或其他紧急情况。请保持reviewShowpriority在你收到reviewCode之日起的半天内我们建议在每周的周会上抽取本周最好的codereview和badcase。直面问题，会让团队的每一位成员快速成长。分支管理版本管理前后端分离Releasesmaster分支受到保护，只从发布分支release作为发布分支，并且只接受日常分支代码合并发布hotfix可以作为紧急发布分支，这发布后需要审核并合并到发布分支。daily用于日常/版本功能开发，每次迭代需要从master签出一个新版本。daily分支代码来自于dev分支的mergedev分支，可以从daily分支上切下来，作为一个迭代函数。多个开发者可以互相reviewCommit。你可以使用one-cli的cz命令为项目一键配置git-commitizen。建议手动提交，按照以下规则为每条commit信息提供代码规范。如果你想直接拥有一套严格但不严格的编码规范，那么我推荐你使用umi-fabric，它是一个包括prettier、eslint和stylelint的配置文件集合。在开箱即用的同时，您还可以自定义规则以满足自己的习惯。npmi@umijs/fabric--save-devyarnadd@umijs/fabric-Deslint配置#.eslintrc.js文件配置module.exports={extends:[require.resolve('@umijs/fabric/dist/eslint')],rules:{//你的规则},};stylelint配置#.stylelintrc.js文件配置module.exports={extends:[require.resolve('@umijs/fabric/dist/stylelint')],rules:{//yourrules},};prettierconfiguration#.prettierrc.js文件配置constfabric=require('@umijs/fabric');module.exports={...fabric.prettier,};延伸阅读前端工程(a):工程的开始
