版本管理规范
|
文档编写中 |
|
先来一张典中典 |
分支生命周期
以上生命周期仅作参考，不同开发团队可能有不同的规范，可自行灵活定义。
例如我们团队在开发时，至少需要保证以下流程：
develop 分支和 hotfix 分支，必须从 master 分支检出
由 develop 分支合并到 test 分支
功能测试无误后，由 test 分支合并到 release 分支
UAT测试通过后，由 release 分支合并到 master分支
对于工作量小的功能开发（工时小于1天），可以直接在devolop 分支进行开发，否则由 develop 分支检出 feature 分支进行开发，开发完后合并到develop 分支
develop 为开发环境分支，始终保持最新完成以及bug修复后的代码，用于前后端联调。一般开发的新功能时，feature分支都是基于develop分支创建的。
开发新功能时，以develop为基础创建feature分支。
分支命名时以 feature/ 开头，后面可以加上开发的功能模块， 命名示例：feature/user_module、feature/cart_module
线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。修复完成后，需要合并到 master 分支和 develop 分支。
分支命名以hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
release 为预上线分支（预发布分支），UAT测试阶段使用。一般由 test 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
|
细分分支: Pre-SIT SIT UAT PROD 环境所有hotfix和feature首先上到Pre-SIT/SIT，cherry-pick到其他分支 |
在编写文档时，应遵循正式、简洁且易于理解的语言规范。文档不仅应具备专业性和准确性，还应确保内容清晰明了。
feat: 新增功能
fix: 修复bug
docs: 仅文档更改
style: 不影响代码含义的更改（空白、格式设置、缺失 分号等）
refactor: 既不修复bug也不添加特性的代码更改
perf: 改进性能的代码更改
test: 添加缺少的测试或更正现有测试
chore: 对构建过程或辅助工具和库（如文档）的更改
除此之外，还有一些常用的类型：
delete：删除功能或文件
modify：修改功能
build：改变构建流程，新增依赖库、工具等（例如webpack、gulp、npm修改）
test：测试用例的新增、修改
ci：自动化流程配置修改
revert：回滚到上一个版本
提交问题必须为同一类别
提交问题不要超过3个
提交的commit发现不符合规范，git commit --amend -m "新的提交信息"或 git reset --hard HEAD 重新提交一次
|
.gitignore是一份用于忽略不必提交的文件的列表，项目中可以根据实际需求统一.gitignore文件，减少不必要的文件提交和冲突，净化代码库环境。 |
下面提供一份通用配置，可自取：
|
Bash |
在Git中，README.md 文件通常用来描述项目的概要、安装和使用方法、贡献指南等。它是项目的门面，帮助其他开发者理解和使用你的项目。下面是一个典型的 README.md 文件结构示例：
|
Bash |
