# git 开发流程
(opens new window) (opens new window)
# Git 的作用
Git 是优秀的分布式代码管理软件，但是，代码分支的管理规范没有制定好，就会带来一系列的问题
- 每个人都从 master 分支拉代码进行修改，合并时出现各种冲突，解决起来一堆乱麻，无从下手。
- 每次发布一个功能就创建新的 feature 分支，各分支之间没有统一的规范，导致整个仓库分支繁杂混乱。
- 代码提交没有统一的 commit 规范，导致生产问题溯源无法找到对应的修改提交。
- 线上版本和测试版本甚至 bug 修复版本不能很好的、区别，经常出现测试环境的代码就发布到生产，出现各种生产事故，造成无可挽回的损失。
# 角色
首先，我们做一些分工，研发部门的人员分工大致可以分为：
- 项目组长 - Team Leader
- 需求开发研发 - Developer
- 系统集成测试人员 - SIT (System Integration Testing - 系统集成测试) Tester
- 系统用户故事测试人员 - UAT（User Acceptance Test - 用户验收测试） Tester
- 系统运维人员 - Operator
# 角色职责
- Leader 主管工程分支创建，分派需求功能开发，代码请求合并，代码 review，在出现合并冲突时，需安排对应开发解决冲突。
- sit 测试人员主要负责系统集成测试，在开发人员完成功能开发后，及时部署测试，完成相应的 api、异常值、边界值测试等。
- uat 测试人员是系统发布到生产的最后一环，需要在系统发布之前做整体业务流程性测试，各种业务规则场景下的测试，尽量避免出现业务规则缺陷。
- 运维人员主导生产环境的系统运维，出现系统问题时及时跟进处理。同时，由于运维人员是直接接触生产环境，需要做好权限管控和操作日志审计，谨防违规，避免出现 “删库跑路”。
# 环境
| 环境 | 权限 | 备注 |
|---|---|---|
DEV(开发环境) | Team Leader, Developer | 开发环境，保持最新功能代码部署 |
SIT(系统集成测试环境) | SIT Tester | SIT 测试环境，功能开发完成后部署测试 |
UAT(用户验收环境) | UAT Tester | UAT 测试环境，系统发布前的预生产环境，需与生产环境系统配置一致 |
PROD(生产环境) | Operator | 正式生产环境，只有运维人员有操作权限，并且有相应的操作复核，日志审计等管理 |
# Flow
- 一个新的项目需求立项后，初始化项目分支，默认创建 master 分支，然后从 master 分支 checkout -b develop 分支。 每位开发人员认领自己的功能需求，分别从 develop 分支拉取自己个人分支进行功能编码。敏捷开发强调功能小版本迭代，并行开发。
- 当研发人员每个 feature 分支完成，开发自测之后，提交 merge request，team leader 经过 code review 确定运行无缺陷后合并到 develop 分支。
- 此时, 从 develop 分支打包最新代码，并部署 sit 测试环境，同步进行功能及接口测试，强调敏捷中的 TTD(测试驱动开发)。
- 当所有 feature 都已合并并且 sit tester 打包测试无误后，从此时的 develop 分支拉取最新代码同步到 release 分支，并打包代码部署到 UAT 预生产环境进行 uat 测试，测试过程中的缺陷直接在 release 分支进行修复，研发及测试人员对修复的代码进行缺陷回归。
- release 分支代码回归测试无误后发布上线，同时合并到 master 分支。
- 此时，一个项目从最初的开发编码到发版上线，整个研发流程确保清晰明了。保证整个研发流程规范，可以大大减少生产事故。
- 当然，不可避免的也会有生产问题，如果此时出现生产问题，需要直接从 master 分支同步代码至 hotfix 分支，修复生产问题并复测回归。
这种流程下，比较容易出现冲突的场景及解决方案如下：
- 多 feature 分支并行开发，在提交测试合并至 develop 分支时，容易出现合并冲突。这就要求各研发人员尽量只修改个人功能代码文件。公共配置或公共依赖包应由单独开发人员维护，按需添加，修改合并后推送到各 feature 分支。
- Hotfix 分支修复的同时有 release 分支功能需要发版上线，合并 master 时容易出现合并冲突。这时按功能生产环境紧急性依次发布上线，发版上线后立即合并 master 并推送到另一分支 (hotfix/release)。