分支管理
参考：
分支命名
常见操作
创建开发分支
此操作在项目初始化时进行操作
- 由
master分支检出 push到远程
git branch develop
git push -u origin develop
或者 安装 gitflow 工具，进行 gitflow init 操作，同样也能达到该效果，同时也会将hotfix、bugfix、release等分支策略进行设置
新功能开发
- 开发人员从
develop分支检出对应功能分支，如：feature/CP-329 - 开发人员在对应的
feature分支上进行开发、提交等工作 - 开发完成后，合并到
develop分支 - 删除对应功能分支
# 1. 从 develop 切出 feature/CP-329 分支，并进入新分支
git checkout -b feature/CP-329 develop
# 2. 开发过程中，勤提交
# 查看当前git状态
# 将文件从工作区提交到暂存区
# 将本地暂存区的文件提交到本地版本库
git status
git add
git commit
# 3. 开发完成后，进行分支合并并删除分支
# 拉取代码库代码，确保develop分支是最新
git pull origin develop
# 切换到develop分支
git checkout develop
# 将feature/CP-329合并到当前分支（develop）
git merge feature/CP-329
# 将代码推动到代码仓库
git push
# 删除feature/CP-329分支
git branch -d feature/CP-329
此过程可以通过 gitflow 工具完成
版本发布准备
按上线计划，在各项工能开发完成后，进行提测，提测需要从 develop 分支检出 release 分支
- 从
develop检出release分支 - 基于
release分支构建测试镜像 - 测试人员进行测试
- 测试有
bug，测试人员将bug提交至JIRA - 开发人员基于
release分支进行bug修复 - 修复完成后，重新部署，并通知测试人员进行回归测试
- 测试完成后，由测试人员出具测试报告或记录
- 开发负责人或开发人员更新上线文档（发布日志、功能列表等）
# 1. 从develop 检出 release/v1.0.0 分支，并进入新分支
git checkout -b release/v1.0.0 develop
# 2. 基于release发布测试镜像并部署到测试环境
# 3. 测试介入
# 4. 测试提交BUG至 JIRA
# 5. 开发人员在 release 分支上进行修复
# 6. 完成bug修复，重新部署并提测
版本发布
- 在测试人员测试完毕后，开发人员和开发主管进行再次确认和验证
- 开发人员和开发主管进行相关文档的编写（上线记录、发布日志、功能说明等）
- 开发主管将
release合并到develop分支与master分支（这里可进行PR和Code Review） - 合并完成后，开发主管在
master分支打发布标签 - 将
release分支删除 - 开发主管构建版本镜像
- 开发人员和开发主管进行上线文档、脚本的编写并验证，验证完成后，交由运维人员
- 运维人员根据上线脚本和说明进行版本更新
- 开发人员和开发主管进行线上验证
- 完成版本发布
# 1. 达到上线标准后，合并 release 至 develop 与 master，注意，这里可以根据规则进行 Pull Request，这是 Code Review 的理想时机
# 切换到master分支
git checkout master
# 将 release/v1.0.0 合并到当前分支（master）
git merge release/v1.0.0
# 将代码推动到代码仓库
git push
# 切换到master分支
git checkout develop
# 将 release/v1.0.0 合并到当前分支（develop）
git merge release/v1.0.0
# 将代码推动到代码仓库
git push
# 在 master 上打版本 tag
# 给master打上v1.0.0的标签，并加上标签说明
git tag -a v1.0.0 -m "Version 1.0.0 published" master
# 将本地标签推动到代码仓库
git push -tags
# 删除 release/v1.0.0 分支
git branch -d release/v1.0.0
线上环境发现BUG
线上BUG分为紧急类型和非紧急类型，对应的处理方式不同
紧急BUG
影响用户正常使用，此时需要进行紧急处理
- 相关人员在
JIRA上提交线上BUG记录 - 对应开发人员认领
BUG - 从
master分支上检出hotfix分支进行修复 - 提交修改，并针对该
BUG进行测试（如果需要测试，此时可直接基于此分支代码打镜像推向测试环境） - 测试通过后，将
hotfix分支合并到master和develop分支上 - 删除
hotfix分支 - 在
master分支上对应位置增加tag标签（bug修复，版本号尾部+1）
# 1. 从 master 切出 hotfix/CP-300 分支，并进入新分支
git checkout -b hotfix/CP-300 master
# 2. 进行正常的代码提交、测试
# 3. BUG修复后，合并到 master
# 切换到master分支
git checkout master
# 将hotfix/CP-300合并到当前分支（master）
git merge hotfix/CP-300
# 将代码推动到代码仓库
git push
# 4. 再将hotfix合并到develop分支
# 切换到develop分支
git checkout de velop
# 将hotfix/CP-300合并到当前分支（develop）
git merge hotfix/CP-300
# 将代码推动到代码仓库
git push
# 5. 删除 hotfix 分支
git branch -d hotfix/CP-300
# 6. 在 master 上打 tag
# 给master打上v1.0.1的标签，并加上标签说明
git tag -a v1.0.1 -m "Version 1.0.1 bug repair" master
# 将本地标签推动到代码仓库
git push -tags
非紧急BUG
不影响用户正常使用，可将该BUG规划到后续版本进行修复，此时可参考正常开发流程
其他问题&方案
定制版本如何维护？
采用单仓库、多分支方案：从交付客户时，从master检出对应分支
分支命名规则：公司名称/develop、公司名称/master
定制开发：在对应公司的 develop 上进行开发、测试，稳定后，合并到对应的 master 上进行迭代，同时打tag
有一些公共缺陷、公共需求等需要在主分支进行修改，待提测通过后使用cherry-pick命令推送这个修改到所有的定制版本（develop）分支上
提测：单独进行提测
评论区