# 珠海智城Git使用规范

![](./imgs/使用流程.png)

## **一、基本规范**  

1.1 主仓库必须由团队管理员建立团队仓库，即主仓库建在团队里，由管理员处理合并请求及合并代码；

1.2 团队中建立管理组(admin)和设计组(dev)，设计组成员对仓库只读，设计组成员必须派生主仓库做为个人远程仓库，本地仓库基于远程个人仓库克隆到本地开发，并生成自已的版本分支进行开发；

1.3 当确定一个版本或需要提交至主库的功能时需向主仓库提交合并请求，主库管理员及时做代码合并处理，本地仓库采用及时提交及时推送的习惯，确定版本后需要及时提交，不允许长期不做提交、不合并，需要保证多副本，多备份机制；

1.4 对于个人调试的工具类或推荐的资料、不涉及公司机密的，可以采用公共方式发布自已的仓库，本着开源精神，由本人负责代码的完整性和有效性，也鼓励大家开发开源项目，但不允许将涉及公司业务的代码开源；

1.5 对于完全开源的项目，大家需谨记不可在代码中保留有公司服务器连接的相关信息，如地址、端口、密码等。

## **二、目录结构规范**  

针对于每个项目保证目录统一，以方便代码管理，其中目录主要包括：Management、Document、Code、UI

Management：该项目团队出开发以外的资料

Document：整个项目实施过程中的文档，包括（需求，开发，测试）

Code：项目源代码

 UI：项目UI部分资料

## **三、代码提交规范**  

### 3.1 设置用户名为姓名全拼，邮箱为公司邮箱地址。

### 3.2 代码提交流程

(1) 代码修改完成后，首先进行编码规范检查，注释检查，自我测试，单元测试、编译测试等。

(2) 测试通过后提交至本地，提交过程中检查修改的文件是否正确，有无遗漏文件等，注明修改说明后提交代码。

(3) 拉取服务器上的代码，如果本地代码是最新的提交，则直接推送到服务器。如果拉取到别人提交的代码，则需合并服务器的代码到本地，并仔细检查代码合并结果，如有冲突则需要找到相应的编码人员一起解决冲突。问题解决后，重新编译本地代码，并测试，通过测试后提交本地代码。

(4) 推送本地提交至服务器。服务器检测到有代码推送后会自行构建所有代码。

### 3.3 日常工作流程

(1) 每天早上开始工作前，请先拉取服务器代码，并编译，检查服务器代码是否有错误。检查无误后即可开始自己的工作。如果有误，请通知最后的代码提交者及项目负责人。

(2) 理论上没修改一个完整的功能点都可以提交代码并推送至服务器（参考代码提交流程）。

(3) 每天工作结束后或者下班前，请提交本地代码，并推送至服务器（代码提交流程）。

### 3.4 代码提交说明规范

(1) 使用中文或英文说明提交内容，但必须是正常人可以理解的。

(2) 提交的说明包括两部分，动作类型: 简要说明，以英文的“: ”进行区分。

(3) 动作类型使用英文大写

(4) 理论上一次提交仅包含一个功能点修改，如果功能过大，则需要注明功能点进度。如果一次提交包含多个功能修改，则每个功能点提交描述作为单独一行，每行以英文分号";"作为行尾结束符。

(5) ADD: [PluginFramework], 提交的内容信息。

| **动作** | **说明**                                                     | **示例**                                                     |
| -------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| ADD      | 新加功能、文件等                                             |                                                              |
| DEL      | 删除功能、文件等                                             |                                                              |
| MOD      | 修改功能                                                     |                                                              |
| FIX      | 修复问题等，如果修复的为BUG，请标注BUG编码                   | FIX: BUG#123, bug's description;  FIX: BUG#124, bug's description; |
| MERGE    | 合并代码，自动合并时一般不需要修改说明文字                   |                                                              |
| REVIEW   | 代码审核注释，需注明审核结果(需使用中括号括起)、@被审核者、被审核模块名称、文件名 | REVIEW: [PASS], @zhanxy, for excel operation model           |
| REFACTOR | 代码重构，需注明重构模块，及说明。一般重构需要使用新的独立分支处理。 |                                                              |
| DOC      | 文档                                                         |                                                              |

规范说明：

1.用一空行分隔标题与正文。

2.标题使用大写字母。

3.标题不超过50个字符。

4.标题使用祈使语气。

5.标题不要使用句号结尾。

6.正文在72个字符处换行。

7.正文解释是什么和为什么，而不是如何做。



示例：

新增开放平台验证接口，Token支援多种调用方式，修复短信问题及删除废弃类

 

1.Add 开放平台验证接口, /OAuth/access_token,/OAuth/refresh_token

2.Mod Token类，修改为使用子类继承，支援多种Token调用

3.Mod Timer类增加ACCESS_TOKEN_TIMER常量

4.Fix 验证码短信文字乱码问题

5.Del Model/UserType.php



国际知名项目 angularjs 提交历史

![](./imgs/示例1.png)

我的提交历史：

![](./imgs/示例2.png)

纳尼？？？我都写了什么？？？



## **四、分支管理规范**  

开发过程主要存在以下分支：

·     **master**

·     **dev**

·     hotfix-[问题名称 | bug编号]

·     feature-[功能名称]

·     bugfix-[bug编号]

·     refactor-[重构名称]

### 4.1 master 主分支

```
- master主分支始终保持稳定的可发布版本
- 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主程操作）
```

### 4.2 dev 开发分支

```
- dev开发分支为不稳定版本，可能存在功能缺失，但已有的功能必须是完整的
- 原则上不允许直接在dev分支上进行功能开发，必须新建feature分支进行开发
```

### 4.3 hotfix-[问题名称 | bug编号] 紧急热修复分支

```
- 从master分支创建，横线后面跟上问题名称或者对应的bug编号，仅仅适用于**生产线问题紧急修复**！！！！
- 修复完成，测试通过，合并到master和dev分支上，然后将此分支删除
```

### 4.4 feature-[功能名称] 功能开发分支

```
- 从dev分支创建，横线后跟功能名称，用于新功能开发，每天下班前push提交到远程
- 开发完成以后，在远程发起向dev分支的合并请求，由指定的CodeReview人员审查通过以后进行合并，并删除该分支
```

### 4.5 bugfix-[bug编号] 问题修复分支

```
- 从dev分支创建，用于修改测试提出的bug，横线后跟bug编号
- 修复以后，在远程发起向dev分支的合并请求，并指定提交者自身（或其他人）作为CodeReview，合并以后删除该分支
```

### 4.6 refactor-[重构名称] 重构分支

```
- 从dev分支创建，用于代码的**重大规模重构**（小规模重构创建feature分支即可）
- 重构以后，必须经过严格测试通过，才能向dev分支合并。
```

![](H:\开发环境部署\Git\Git使用规范.png)