Skip to content

Commit

Permalink
feat: 添加文档协同规约、代码提交规约
Browse files Browse the repository at this point in the history
  • Loading branch information
XiaoLFeng committed May 15, 2024
1 parent 7b333b9 commit 7add7bc
Show file tree
Hide file tree
Showing 2 changed files with 142 additions and 0 deletions.
32 changes: 32 additions & 0 deletions docs/开发文档/代码提交规约.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# 代码提交规约

本项目采纳 DevOps 方法,致力于提高开发效率,加强团队之间的协作与沟通,以及快速响应操作。

## 流程规定

开发流程设计旨在确保每个功能点都能够得到充分理解和有效实施,同时保证项目整体进度符合预期。

- **工单管理**:项目管理者将根据功能需求创建工单,并分配给相应的开发者。每个工单都详细描述了功能点的需求,开发者应仔细阅读并理解工单内容。如有疑问,应及时在工单中提问或请求帮助。「新任务接收到后,请各位开发者回复确认!避免遗漏任务点」
- **开发与代码审查**:开发者在完成对工单的理解后,开始在feature分支进行代码编写。编码完成后,通过创建Pull Request来请求将代码合并到master分支。项目管理者或指定的代码审查员将对代码进行审查,确保代码质量和功能实现符合要求。
- **自动化部署**:master分支的更新将触发自动化部署流程,通过Jenkins等CI/CD工具自动部署到测试环境,以便进行集成测试和性能测试。这一流程确保了代码的稳定性和可部署性。
- **漏洞修补与补丁更新**:在项目开发过程中发现的任何漏洞都将通过创建新的fix/patch分支来进行修补。修补工作完成后,同样需要经过Pull Request和代码审查流程,确保补丁的正确性和稳定性。

## 分支规定

该部分内容前端与后端规定一致

> 项目定义了三条主要分支:master, feature, fix/patch。
- **主分支(master)** :代表项目的当前稳定版本,用于生产部署。
- **功能开发分支(feature)** :用于新功能的开发。每个新功能应在单独的feature分支上进行开发,待功能完成并通过审查后,再合并回master分支。
- **修补分支(fix/patch)** :用于修复发现的漏洞或进行必要的补丁更新。分支命名需遵循fix-工单ID或patch-工单ID的规则,以便追踪和管理。

其中 master 分支禁止开发者直接推送至仓库。对于所有的新业务代码请在 feature 分支编写,业务逻辑完成后,使用仓库功能 Pull Request(合并请求) 将代码往 master 分支合并;若在 master 分支下出现漏洞情况,按需创建 fix/patch 分支(该部分分支有命名要求),修补完成后提交 Pull Request(合并请求) 至 master 分支。

除此之外,请注意,feature 分支和 fix/patch 分支不可随意合并,避免后期造成代码混淆难进行业务状态跟踪。

## 问题处理

对于开发过程中遇到的问题,鼓励开发者首先尝试在工单内解决。如果问题超出了单一工单的范围,或者是跨功能点的,开发者可以创建新的工单来描述这些问题。新工单应明确问题的性质、影响范围,并指定负责人或相关协作者。

问题请各位开发者务必描述清楚!!!
110 changes: 110 additions & 0 deletions docs/开发文档/文档协同规约.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,110 @@
# 文档协同规约

> 请注意,以下内容只作为参考,符合一定规范即可,写下内容为方便开发者进行文档编写
## 1. 目的

本文档旨在规范开发过程中如何引入和记录自定义标准库及新功能,以确保团队成员对新增内容的使用和理解一致。

## 2. 范围

本文档适用于所有在开发过程中引入的影响全局或者在全局范围内可用的新内容。

## 3. 定义、缩写和缩略语

- **API**: 应用程序接口
- **SDK**: 软件开发工具包

## 4. 引入新内容的步骤

### 4.1 新内容的定义

每当在开发过程中引入新内容(如自定义标准库、全局可用的组件等)时,应提供以下信息:

- **名称**: 新内容的名称
- **版本**: 新内容的版本(如适用)
- **描述**: 新内容的功能描述
- **用途**: 新内容在项目中的用途
- **使用示例**: 新内容的代码使用示例
- **依赖关系**: 新内容所依赖的其他库或组件

### 4.2 文档更新流程

1. **编写**: 按照上述定义,编写新增内容的文档。
2. **审核**: 提交给团队内相关人员审核,确保准确性和完整性。
3. **合并**: 审核通过后,将文档合并到项目的正式文档中。
4. **通知**: 通知团队成员,确保所有人了解新内容及其使用方法。

## 5. 模板

### 5.1 新内容模板

```markdown
## 新内容名称
- **版本**: [版本号]
- **描述**: [简要描述新内容的功能]
- **用途**: [新内容在项目中的具体用途]
- **使用示例**:
```kotlin
// 使用示例代码
```
- **依赖关系**: [新内容所依赖的其他库或组件]
```

### 5.2 示例

```markdown
## 自定义日志库
- **版本**: 1.0.0
- **描述**: 一个用于统一项目日志记录的自定义库
- **用途**: 该库用于在项目中记录各种日志信息,提供便捷的日志记录接口,并统一日志格式
- **使用示例**:
```kotlin
// 初始化日志库
val logger = CustomLogger.getInstance()

// 记录信息日志
logger.info("This is an info message")

// 记录错误日志
logger.error("This is an error message")
```
- **依赖关系**: 无
```

## 6. 发布与通知

### 6.1 发布流程

- 将更新后的文档发布到项目的正式文档库中

### 6.2 通知流程

- 通过邮件、即时通讯工具等方式通知团队成员
- 确保所有相关人员知晓并了解新内容的使用方法

## 7. 附录

提供支持文档编写和审核的附加信息,如代码样例、相关链接等。

### 7.1 代码样例

提供更多代码示例以便于理解和使用新内容。

### 7.2 相关链接

提供与新内容相关的链接,便于团队成员查阅参考资料。

## 8. 版本管理

### 8.1 修订历史

记录本文档的修订历史,包括版本号、修改日期、修改人和修改内容。

```markdown
## 修订历史
- **版本**: 1.0.0
- **日期**: 2024-05-15
- **修改人**: 李四
- **修改内容**: 初始版本
```

0 comments on commit 7add7bc

Please sign in to comment.