工作中标准 git + gitlab 工作流模式

srq
srq
2025-02-16 / 0 评论 / 5 阅读
本文共522 个字,平均阅读时长 ≈ 2分钟

修复bug的完整流程

1 . 发现bug
测试人员或用户发现应用程序中的bug,并将其报告给开发团队。
开发人员查看bug报告,理解问题的本质,并确定修复所需的步骤。
2 . 创建修复分支
开发人员从主分支(例如main或master)创建一个新的修复分支。这个分支的名称应该包含bug的标识符或描述,以便于跟踪。

git checkout main

git checkout -b fh-test-v354-srq-<修复名> # 例如 fh-test-v354-srq-tj

3 . 初次修复并测试
在修复分支上,开发人员对代码进行修改以修复bug。
修改完成后,开发人员运行本地测试以确保修复有效。

git add buggy_code.py #假设你修改了文件buggy_code.py

git commit -m "fh - 描述Initial fix for bug "

运行本地测试...

4 . 提交修复分支(如果需要)
如果团队使用代码审查流程,开发人员可能会将修复分支推送到远程仓库,并创建一个合并请求(Merge Request, MR)或拉取请求(Pull Request, PR)。

git push origin fix-bug-

在GitLab上创建MR/PR

5 . 初次测试失败(可选)
如果在代码审查过程中或自动测试阶段发现修复无效或引入了新的问题,开发人员需要回到修复分支进行更多的修改。
6 . 多次修改同一个bug
开发人员继续在修复分支上进行修改,每次修改后都运行测试以确保问题得到解决。
bash

修改代码...

git add
git commit -m "Additional fix for bug - "

运行测试...

如果需要,重复上述步骤直到bug被完全修复。

7 . 最终测试通过
经过多次修改和测试后,开发人员确信bug已经被修复,并且没有引入新的问题。
8 . 合并修复分支
开发人员或测试人员将修复分支合并回主分支。

git checkout main # 切换到主分支

git merge fix-bug- ## 合并修复分支 解决可能的合并冲突(如果有)

git push origin main # 推送更改到远程仓库

9 . 删除修复分支(可选)
合并完成后,修复分支通常会被删除,因为它已经包含了在主分支中的更改。

git branch -d fix-bug-
git push origin --delete fix-bug- # 如果修复分支已经推送到远程仓库,也需要删除远程分支
0

评论 (0)

取消