Git 在公司内部的使用规范

Git 在公司内部的使用规范

目录

• Git 在公司内部的使用规范
• 1. 版本定义
• 2. 系统开发环境
• 3. 分支定义
• 4.Commit 日志规范
• 5. 开发工作流程：
  • 5.1. 常规分支 debug 流程：
  • 5.2. 紧急 debug 流程：
  • 5.3. 研发经理：
    • 5.3.1. 常规分支 debug 流程：
    • 5.3.2 紧急 debug 流程：

1.版本定义

版本号使用 x.x.x.x 进行定义.

• 第一个 x 代表大版本只有在项目有重大变更时更新；
• 第二个 x 保留；
• 第三个 x 代表常规版本有新求会更新；
• 第四个 x 代表紧急 Bug 修正；
  一个常见的版本号类似于：0.0.10.11

2.系统开发环境

简称	全称	作用
DEV	Development environment	用于开发者调试使用
FAT	Feature Acceptance Test environment	功能验收测试环境，用于测试环境下的软件测试者测试使用
UAT	User Acceptance Test environment	用户验收测试环境，用于生产环境下的软件测试者测试使用
PRO	Production environment	生产环境

3.分支定义

分支	名称	作用
master	主分支	用于生产部署，最新稳定版本，一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。
release	预上线分支	预上线分支，是 develop 与 master 之间的一个缓冲，始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。（UAT）
hotfix	紧急修复分支	紧急分支，名规则为 hotfix- 开头，从 master 生成，bug 修正后自动合并到 master 和 develop 并且生成 tag；
develop	测试分支	功能验收测试环境，用于测试环境下的软件测试者测试使用，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。，FAT，如果开发工时 <1d，直接在 develop 开发，如果开发工时> 1d，那就需要创建分支，在分支上开发。
feature	需求开发分支	用于开发新需求和需要较长时间的 BUG 修改，(正式环境) 测试通过后，研发人员需要删除 feature- 分支。

4.Commit 日志规范

提交信息一定要认真填写！

建议参考规范：(scope)：

比如：fix(首页模块)：修复弹窗 JS Bug。

type 表示 动作类型，可分为：

fix：修复 xxx Bug
feat：新增 xxx 功能
test：调试 xxx 功能
style：变更 xxx 代码格式或注释
docs：变更 xxx 文档
refactor：重构 xxx 功能或方法
scope 表示 影响范围，可分为：模块、类库、方法等。

subject 表示 简短描述，最好不要超过 60 个字，如果有相关 Bug 的 Jira 号，建议在描述中加上。

5.开发工作流程：

git flow feature start xxxxx（开始新需求）
在 feature/xxxxx 分支下进行开发
git flow feature finish xxxxx（开发完成后等待研发经理确认可以完成时执行）
git push origin develop（发布 develop 分支）
每天工程师都需要 git pull origin develop 来更新 develop 分支，然后将 develop 分支合并到你正在开发得 feature/xxxxx 分支上来保持代码最新
切记不能直接在 develop 上进行开发

5.1常规分支 debug 流程：

---

1. 由研发经理通知相关工程师 release 版本 x.x
2. git fetch
3. git checkout -b release/x.x origin/release/x.x（拉回 release 版本）
4. git pull release/x.x（更新该分支）
5. 修改测试中发现的 BUG
6. git push origin release/vx.x（修改完后提交分支）
7. 循环 4-5

5.2紧急 debug 流程：

---

1. 由研发经理通知相关工程师 hotfix 分支名称 x.x.x
2. git fetch
3. git checkout -b hotfix/x.x.x origin/hotfix/x.x.x（拉回 hotfix 分支）
4. git pull hfx.x（更新 hotfix 分支）
5. 在热修复分支下修改 bug
6. git push origin hfx.x（修改完成，提交分支）
   在日常工作中不能修改 master 分支下得代码

5.3研发经理：

---

开发和 DEBUG 流程同工程师流程

5.3.1常规分支 debug 流程：

1. git pull origin develop（更新 develop 分支为最新）
2. git checkout develop（切换到 develop 分支）
3. git flow release start x.x（生成一个 release 分支）
4. 通知测试和相关得工程师分支名称
5. git pull origin release/x.x（最终测试完成后拉回分支最新代码）
6. git flow release finish x.x（最终修改和测试完成后，结束 release 版本以供发布）
7. git push origin develo (发布最新的 develop)
8. git push origin master（发布最终得 master 分支）

5.3.2紧急 debug 流程：

1. git pull origin master（更新 master 分支为最新）
2. git checkout master（切换到 master 分支）
3. git flow hotfix start x.x.x（生成一个 hotfix 分支）
4. 通知相关得工程师和测试人员 hotfix 分支名称
5. git pull origin hotfix/x.x.x（最终测试完成后拉回分支最新代码）
6. git flow hot fix finish x.x.x（最终修改和测试完成后，结束 hot fix 以供发布）
7. git push origin master（发布最终得 master 分支）
   在全部的流程中，工程师必须维护自己的 feature 分支保证代码最新，减少合并时的冲突。

研发经理必须维护 release 分支，将最新的 hotfix 都合并进去，保证代码最新，减少合并时的冲突。

在提交代码时还要注意判断对代码的修改是否是自己的，多用 diff 工具，多查看 log，防止代码回溯