git规范
项目命名规范
本机代码保存路径
首先在电脑某个分区命名改为文档，所有项目放到文档磁盘/project/根目录下。其他地方不应出现项目代码内容。项目命名
项目根目录使用小写字母+中划线命名，在最后一个中划线后面需加上主要使用的框架名称，如果有版本区别，需要加上版本数字。文件夹命名规范
项目内的文件夹，特别是根目录的文件夹应首先按照框架官方推荐的标准命名，其次也可按照行业流行标准命名。切勿按照自己标准，其他人学习成本大。
生产环境部署文件如非其他条件限制，应统一放到项目根目录下的devops文件夹内。项目README.md文档规范
文档内标题用'##'表示，应包含：项目介绍、主要框架版本、git提交和分支规范、测试服务器部署流程、项目注意事项、版本更新内容，也可以再增加其他标题。若标题暂时没有内容，也可以先写标题，内容后面再填充。项目依赖包规范
项目应尽量使用最新稳定版的第三方包，对不常见的包应给与注释使用目的，对作者维护力度不大和关注度不高的包应该谨慎使用，特别是近期没更新的包和不兼容新环境的包应当先讨论。在项目迭代期间，应关注第三方包的更新动态，合理进行同步更新。
git规范
git分支规范
git分支仅有两个长期分支：master和production。production分支仅用于生产环境发布，不建议直接在上面开发。 如果是一人独立开发项目，可以直接在master分支开发；如果是多人开发项目，需在master上新建开发分支进行开发，开发分支命名为：git关键字/本分支开发的主要目标。当开发分支合并代码确认完成工作后，应删除该开发分支。git提交注释规范
提交时注释格式为：git关键词(影响范围): 简单的内容描述，请注意使用英文冒号，并且后面有个空格。如果需要写详细内容，请回车后再空一行，继续写详细内容。git提交关键词
- feat: 新功能
- fix: 修复问题
- perf: 提升性能或体验等优化
- docs: 修改文档
- style: 修改代码格式，不影响代码逻辑
- refactor: 重构代码，理论上不影响现有功能
- test: 增加修改测试用例
- ci：持续集成相关
- cd: 持续部署相关
- build：编译相关的修改，例如发布版本、对项目构建或依赖的改动
- chore: 修改工具相关（包括但不限于文档、代码生成等）
- revert：回滚到上一个版本
git新建标签规范
production分支仅用于生产环境发布，每次提交需要打上正式版本标签，标签示例：v1.7.2。
第一个数字代表大版本号，第二个数字代表功能升级号，第三个数字代表补丁修复号。大版本号在研发迭代初期应为0，0代表项目功能未成型，还未完成服务对象的最基本需求；
每次功能升级或调整都需要增加一次功能升级号，并把补丁修复号归零；功能升级到一定程度导致与最初大版本功能差异过大时，需增加一次大版本号，并将功能升级号和补丁修复号归零。master分支上可以打测试版本标签，标签示例：v1.8.0b1，b代表beta，如测试没问题将b1去掉，合并到production打上标签v1.8.0 ，系统会自动部署到生产环境。项目协作系统使用规范
在项目协作系统中应合理规划需求，关联并规划迭代计划，关联并分解任务，在约定时间内迭代到production分支并打上版本标签。在发现版本功能缺陷时，在系统中正确的提交缺陷。小步快跑，逐步迭代。敏捷开发规范
项目研发初期应做好提交规范、分支规范、代码版本规范。在项目迭代过程中，production分支最晚在两个星期内发布一次代码，也可以在一个星期内发布多次，production分支应做好devops，需自动更新到生产服务器。
测试服务器可以本地环境运行，也可能远程环境运行，也可以使用IDE功能做devops，也可以通知管理员做好自动部署流水线。生产环境bug修复
尽量在master分支上修复完成，合并到production后并升级补丁号。如紧急情况需要在production修改，也需将修改内容同步更新到master分支。
部署规范
- 开发环境和正式环境的资源命名规范
前端项目OSS资源：正式环境的打包网页直接放到OSS的根目录，开发环境的打包网页放到OSS的dev目录内。
后端媒体OSS资源：正式环境的图片视频放到OSS的server_media目录下，开发环境的图片视频放到OSS的server_dev_media目录。
mysql数据库：正式环境的数据库命名不用加额外后缀，开发环境的数据库命名用dev结尾。
工作流程六步法
以下是推荐的工作流程，请按顺序来做。
- 服务对象提出工作需求（这里的服务对象可能是领导，可能是产品经理，可能是其他部门同事，可能是客户）
- 执行者确认需求，并整理出需求清单，也可以口述重复一遍由对方确认，确保需求理解正确。
- 执行者确认工期，如工作内容原因无法确认具体时间也要确认大概时间。
- 若工期时间较长，服务对象应在工期内至少主动参与一次工作进度的确认，或执行者主动再次与之沟通确认工作进度。确保需求理解到位，工作方向正确，如有偏差及时调整。
- 若工期需要延长，必须确保在75%的工期时间内与服务对象沟通来再次延长工时，比如项目计划一个月完成，如工期需要延长，需要在最后一个星期前沟通工期延长时间。
- （重要）请不要忘了工作约定时间，在约定时间内给与工作结果的回复。
五步工作法（供学习）
在做重要决策时，
- 确认需求后，要再次确认需求内容显得不是那么"愚蠢"
- 尝试删掉部件或步骤
- 优化阶段
- 加速迭代升级，这里重在加速（前三步没完成不要做加速）
- 做到自动化