前提 此方法是在没有技术阻碍的前提条件下预估，如果有技术障碍，请先解决技术阻碍 此方法需要根据个人实际情况调整 这里以普通的以vue,element-plus,axios为基础技术的管理系统为例 这些

大厂的开发流程还是比较规范的，如果你来不及学习长篇大论的 git 文档，这篇文章够你入职时用一段时间了。

前端模块化作为前端必备的一个技能，已经在前端开发中不可或缺；而模块化带来项目的规模不断变大，项目的依赖越来越多；随着项目的增多，如果每个模块都通过手动拷贝的方式无异于饮鸩止渴。

随着Git的流行，越来越多的团队在往Git迁移或者转型，在团队建设初期或者中期转型优化，合适的Git分支管理策略方案能够较好的提高团队的效率，节约人员成本，降低代码版本管理带来的风险。笔者曾经历过因为分支管理策略不合适、人员操作不规范引发的代码版本混乱、线上版本与生产版本不一致…

我们在个人项目上使用 git 往往比较随心随意，下面记录一种团队开发时比较稳妥而且不需要太高超的git 技术的管理方式。 首先来模拟个场景 假设我们目前有一个项目 A 根据公司提供的开发资源，我们可以

随着项目的不断增加，急切需要统一每个项目的代码规范，将一些低级错误在萌芽状态下掐死。所以特此结合当前项目使用的一些规范，再根据社区推荐的规范，整合成这个repo。里面集成了React和Nodejs的编程规范，所有的规范都是基于airbnb，里面细分了js版本和ts版本，满足大家…

最近遇到了一个老项目，比较有意思的是这个项目集前后端的代码于一起，而后端也会去修改前端代码，所以就出现了后端用 IntelliJ IDEA 来开发前端项目，而前端用 VSCode 来开发前端项目的情况

本文从前端工程，团队协作，Git Flow，提交规范与校验，生产部署的角度，介绍架构人员需要掌握的 git 实践能力

团队项目自动风格格式化的各类技巧； 业务实战过程中发现了问题，通过以下工具一并解决 husky lint-staged eslint commitlint