Git_Rebase_Conflict_Resolution

Gerrit 变基（Rebase）与冲突处理指南

在 OpenHarmony FFmpeg 移植过程中，由于多人协同开发或远程分支更新，经常会遇到 Gerrit 上的Merge Conflict（合并冲突）。本文档详细记录了该问题的现象、原因、处理过程及最终结果。

1. 问题现象

1.1 Gerrit 网页端

在 Gerrit 提交页面，右上角显示红色的[Merge Conflict]标签。
提示信息：

“This change has merge conflicts. Download the patch and run ‘git rebase’. Upload a new patchset after resolving all merge conflicts.”

1.2 本地推送失败

在尝试使用git push更新补丁时，可能会遇到以下报错：

• ! [remote rejected] HEAD -> refs/for/xxx (no new changes)：提示没有新变化（因为 Commit Hash 没变，但父提交已落后）。
• 或者直接提示无法推送到该分支。

2. 根因分析

• 本地代码落后：本地分支的开发起点（Base）是旧的。在开发期间，远程目标分支已经合入了其他人的代码。
• 物理冲突：远程最新的代码与你修改的代码在同一个文件的同一行（或相邻行）发生了变动，Git 无法自动合并。

3. 处理流程图

同步远程->启动变基->手动解冲突->标记解决->继续变基->推送更新

4. 详细处理步骤

第一步：同步远程仓库

首先确保本地知道远程分支的最新的状态。

备注：这里的kaihong是本地配置的远程仓库别名（Remote Name），在本环境中它指向 Gerrit 服务器地址（ssh://gerrit.kaihongdigi.com）。在其他项目中，这个别名通常默认为origin。

gitfetch kaihong

第二步：启动变基 (Rebase)

将本地的提交“剪切”下来，暂时放在一边，然后将本地分支对齐到远程最新的提交，最后再把你的修改“贴”回去。

命令详解：git rebase <远程主机名>/<目标分支名>

1. Re-base 的含义：重新定义你的提交起点。它会将你当前分支的所有提交（Commit）临时移除，将分支指针移动到目标分支的最新位置，然后按照顺序逐个尝试重新应用（Apply）你的提交。
2. 为什么不使用 Merge：merge会产生一个新的合并提交记录，导致历史记录出现交叉分叉。而rebase能保持提交历史呈现为一条直线，这对 Gerrit 这种基于 PatchSet 评审的系统非常重要，方便 Reviewer 追溯单一功能的变化。
3. 操作结果：执行后，你的 Commit ID 会改变，但代码逻辑会被“嫁接”在最新的主干代码之上。如果在这个过程中发现同一行代码被别人改过，Git 就会产生冲突并停下来等你处理。

# 假设目标分支为 M_Feature_LiteosAArch64_20240820gitrebase kaihong/M_Feature_LiteosAArch64_20240820

第三步：手动解决冲突

如果在“贴回”过程中发生冲突，Git 会停下来并报错：
CONFLICT (content): Merge conflict in <文件名>

1. 打开冲突文件（如ohos_config.sh）。
2. 定位冲突标记：
   • <<<<<<< HEAD：远程最新的代码。
   • =======：分割线。
   • >>>>>>> <commit_id>：你本地写的代码。
3. 合并代码：根据业务逻辑，删掉标记行，保留正确的代码组合。

第四步：标记解决并继续

1. 标记文件已修复：

   gitaddohos_config.sh

2. 继续完成变基：

   gitrebase --continue

   注：此时会弹出编辑器让你确认 Commit 信息，直接保存退出即可。

第五步：推送新补丁集 (Patch Set)

变基完成后，本地的Change-Id保持不变，但Commit Hash会改变。

命令详解：git push <远程主机名> HEAD:refs/for/<目标分支名>

1. HEAD：指代你本地当前分支最新的那次提交。
2. refs/for/：这是 Gerrit 特有的虚拟引用路径。普通的 Git 推送是直接更新分支指针，而推送到refs/for/路径会告诉 Gerrit 服务器：“不要直接合并，请为我创建一个代码审核任务（Change）”。
3. 目标分支名：指定你的代码最终希望合并到服务器上的哪一个分支。
4. 推送结果：如果本地 Commit 包含与服务器上已存在的 Change 相同的Change-Id，Gerrit 会自动在该任务下生成一个新的Patch Set，而不是创建一个新任务。

gitpush kaihong HEAD:refs/for/M_Feature_LiteosAArch64_20240820

5. 处理结果

1. Gerrit 自动识别：由于Change-Id没变，Gerrit 会自动将此次推送识别为该任务的Patch Set 2。
2. 冲突消失：由于你在本地已经完成了变基并解了冲突，网页端的红色Merge Conflict标签会自动消失。
3. 代码对齐：你的代码现在是基于服务器上最新的代码开发的，处于Active状态，可以正常由审核人（Reviewer）合入。

6. 核心细节提示

• Change-Id vs Commit ID：Change-Id是 Gerrit 用来跟踪同一个任务的“身份证”，必须保持不变；Commit ID是 Git 的物理存档 ID，变基后必然会变。
• 不要使用 Merge：在 Gerrit 流程中，严禁在本地使用git merge来解决冲突，必须使用git rebase以保持提交历史的线性。