git的rebase操作

最新推荐文章于 2024-10-02 12:54:52 发布

我知道你是高手

最新推荐文章于 2024-10-02 12:54:52 发布

阅读量1.8k

点赞数 1

分类专栏： git

本文链接：https://blog.csdn.net/jerry010101/article/details/86291935

版权

git 专栏收录该内容

4 篇文章 1 订阅

订阅专栏

1. 产品经理和测试人员

产品经理和测试人员共同确定用户故事的验收标准（例如JIRA卡片：OPS-15），记录在JIRA卡片：OPS-15的验收标准字段

2.开发人员

为JIRA卡片 OPS-15 在相应代码库的dev分支创建名字为 feature_vn_OPS-15 的分支

$ git checkout -b <分支名>
# 例如：git checkout -b feature_vn_OPS-15

编写代码（如果有要求，还需编写自动化单元测试脚本）
研发自测
- 构建测试（开发人员本地构建、运行单元测试、运行阿里云插件）
- 部署至开发环境根据测试人员写的测试用例和产品经理写的验收标准自测
本地自测结束提交代码到本地代码库，提交信息务必遵守格式"<JIRA卡片ID> - <提交信息>"

$ git add <文件名 或 文件模式> # 例如: git add -A
$ git commit -m "<JIRA卡片ID> - <提交信息>" # 例如： git commit -m "OPS-15 - 首页新增加一个按钮"

每天下班前推送自己当天的代码到自己的远端分支

$ git push origin <远端分支名> # 例如：git push origin feature_vn_OPS-15

当电子卡片（例如：OPS-15）功能完全开发完成并本地自测结束，可以合并回dev分支时, 开发人员先rebase 代码， rebase on top of latest master

$ git pull --rebase origin dev

$ git pull --rebase origin dev

如果有冲突，按照以下步骤进行合并：

$ vi <有冲突的文件> # 例如： vi name_of_conflick_file.java
# 处理冲突
$ git add <有冲突的文件> # 例如：git add name_of_conflick_file.java
$ git rebase --continue
 
# 以上过程可能会重复多次，直到所有的冲突都已经解决
# 避免冲突：及时rebase，及时提交

如果你的feature分支（例如：feature_OPS-15）有超过一个commit （检查命令 git rev-list origin/dev..HEAD --count 或者 git rev-list origin/dev..HEAD | wc -l ）那么就squash（挤压）你的commit，将多个commit挤压成一个，命令为

$ git rebase -i origin/dev
# 在弹出的字符界面中进行 commit squash
# 仅保留第一个commit， 将其他commit前面的 pick  改为 s
# 保存修改(命令 :wq)
# 在第二个字符界面中，修改commit comment， 可以只保留一行干净的，针对feature说明的comment
# 保存修改(命令 :wq)

将已经squash（挤压）过的commit推送到你的远端分支，由于使用的是rebase, 所以此处需要强制推送：--force

$ git push origin <远端分支名> --force 例如：git push origin feature_vn_OPS-15 --force

在Gitlab上创建一个合并请求
指定的开发Leader 在通过 code review后，在GitLab的代码处上提交一个“同意合并的评论”，然后合并前先看看Jenkins代码库在dev分支的上一次构建状态是正常还是失败
- 如果正常（显示蓝色），将feature分支（例如：feature_vn_OPS-15）合并到 dev 分支;
- 如果失败（显示红色），不允许合并代码！！！通知相关人员修改代码，等Jenkins上的dev分支最近一次构建状态正常（显示蓝色），才可以将feature分支（例如：feature_vn_OPS-15）合并到 dev 分支;
通过Jenkins对dev分支进行构建，根据构建结果：
- 如果构建通过，开发人员通知指定的测试人员进行测试
- 如果构建失败，开发人员需要将dev分支上自己合并的上一次代码回退，然后通过Jenkins对dev分支构建，直到构建成功（构建状态显示蓝色），然后开发人员修改自己代码自测后，重新在GitLab提合并请求。

3. 测试人员

敏捷团队的测试人员将上一步Jenkins构建出的代码包部署到指定的测试环境，根据JIRA卡片的验收标准字段和相应的测试用例，进行黑盒测试
如果测试过程中发现的 bug, 在JIRA中创建bug类型的卡片，例如：OPS-16，并将卡片与对应的故事类型卡片进行关联
开发人员从dev分支创建 Bug Fix分支，命名为：bugFix_vn_OPS-16 ，修复Bug，然后合并回dev分支，触发Jenkins对dev分支的构建，通知测试人员测试
测试人员测试完卡片