前端Git使用约定，如何为一个不超过30个字？

前端 Git 使用约定 背景 开发前端项目，有以下困惑： 使用哪个分支开发，哪个分支发布 修复线上bug的流程是什么，如何避免修复完了下次却又出现了 cms分支有十多个，是否都有用 如何快速找到之前某次功能开发，或某次bug修复 为了减轻上述困扰，引入 gitflow 规范，并根据公司情况做适当调整。 gitflow GitFlow 是一种基于 Git 的工作流程设计，它是由 Vincent Driessen 在2010年提出的。是一种分支管理模型。请看下图： 从右往左一共5个分支。 首先是 master 主分支，也就是线上代码。不应该直接修改，只需要合并其他分支。 其次是 develop 开发分支，从master拉取，也不应该直接修改。 现在有两个版本的需求需要开发，一个是下一个版本 1.0 的（Major feature for next release）的需求，另一个是下下个版本2.0（Feautre for future release）的需求，时间更长。所以直接从 develop 分支拉取两个 feature 功能分支。 其他人也在持续的推进 develop 分支的前进 现在 1.0 的需求开发完成，于是将 feature 分支合并到 develop 中，然后从 develop 中拉取一个 release 分支，用于发布前的测试，这个 release 分支就不在开发新功能，只做bug修复（Only bugfixes），同时修复的bug也需要同步到 develop 分支，最后测试通过，则将 release 分支合并到 master 分支，同时将 release 分支合并到 develop。 线上有了问题，需要紧急处理，于是从 master 拉取 hotfixes 分支，修复完成后将 hotfixes 合并到 master 分支和 develop 分支，避免后续 develop 还有这个问题。 其中 master 分支和 develop 分支是一直存在的，其他分支都是临时的。master 分支用于存放稳定的生产版本代码，而 develop 分支则用于集成各个功能分支最新的开发成果。 分支和环境对应关系： feature develop release hotfix master 开发环境 测试环境 预发布环境 线上 线上 分支流程： feature -> develop -> release -> master 小建议 保持 develop 分支和 feature 分支同步：如果 develop 变动比较频繁，建议每天上班就将 develop 分支合并到 feature，这样避免两个分支差别太大，造成 feature 不能合并到 develop分支，或者需要很长时间解决冲突。 feature 分支也要时刻提交代码。万一机器坏了... 提交信息规范 Conventional Commits 是一种提交消息的规范格式 <类型>[可选的作用域]: <描述> [可选的正文] [可选的脚注] 例如： /* <类型>[可选的作用域]: <描述> */ feat(login): add login form validation /* <类型>[可选的作用域]: <描述> [可选的正文] */ fix(注册): 修复用户注册时的验证逻辑错误 之前的逻辑判断漏掉了对用户名长度的限制，导致用户可以注册过长的用户名，现在已经修复了该问题，并增加了相应的验证逻辑。 修复了一个潜在的安全漏洞。 /* <类型>[可选的作用域]: <描述> [可选的正文] [可选的脚注] */ feat(auth): 增加JWT认证 - 实现 JWT 生成和验证 - 更新认证中间件 关闭问题 #12345 类型有如下： feat：表示引入新的功能（feature）的提交，即添加新的功能特性。 fix：表示修复 bug 的提交，用于修正代码中的错误或问题。 docs：表示文档变更的提交，指示与文档相关的修改，比如更新文档或注释。 style：表示代码样式（style）的修改，通常是不影响代码含义的调整，比如空格、格式化等。 refactor：表示重构代码的提交，即对现有代码结构进行非修复性的修改。 test：表示增加或修改测试的提交，用来新增或调整单元测试、集成测试等测试代码。 chore：表示其他零碎的提交，通常包括构建工具、辅助工具等的修改，比如更新构建脚本、任务管理等。