因git cherry-pick导致分支不同步，如何重新同步？

1. 让Git认可当前代码一致，切换至特性分支合并流程 #

先确认两分支代码完全无差异：

git diff master stage

若输出为空，说明代码一致。执行ours策略合并，让Git标记Master已合并Stage的所有历史，同时保留当前代码（因两分支代码一致，最终代码无变化）：

git checkout master
git merge -s ours stage

这个操作会生成一个合并提交，消除Git对两分支的历史差异判定。后续统一采用特性分支流程：

• 新功能/修复在独立特性分支开发
• 完成后合并至Stage测试
• 测试通过后将特性分支合并至Master（或直接从Stage合并至Master，此时历史已同步，不会触发大量冲突）

2. 不重建分支同步两分支 #

基于上述合并操作，两分支历史已被标记为同步。若要让Stage完全对齐Master的HEAD（或反之），可执行硬重置（需团队全员配合，因会改写远程分支历史）：

# 让Stage指向Master的当前提交
git checkout stage
git reset --hard master
# 强制推送至远程（需确保团队成员已提交本地变更并拉取最新代码）
git push -f origin stage

可根据团队基准分支选择让Master对齐Stage，操作逻辑一致。

3. 将两分支指向同一HEAD #

硬重置操作直接实现该目标：执行git reset --hard <目标分支HEAD>后，当前分支的HEAD会完全指向目标分支的提交。例如：

# 查看Master的当前提交SHA
git rev-parse master
# 让Stage指向该SHA
git checkout stage
git reset --hard <Master的SHA值>
git push -f origin stage

完成后执行git log --oneline master stage，会显示两分支指向同一提交。

4. 其他替代策略 #

• git replace临时关联历史：在本地将Master的旧提交替换为Stage的对应提交，让Git认为两分支共享历史。但此方法仅对本地有效，团队所有成员都需执行相同操作，维护成本高，适合临时过渡场景。
• 逐步收敛历史：若团队无法接受强制改写历史，可后续每次合并时使用git merge -X theirs（或ours）批量解决冲突，多次合并后逐步消除历史差异。此方法耗时较长，但对现有流程影响较小。
• 流程强制规范：后续严格禁止直接从Stage cherry-pick至Master，所有代码变更必须通过特性分支流转，从根源避免历史分叉。

关键注意事项 #

所有涉及改写远程分支历史的操作（如git push -f），必须提前通知所有团队成员：

1. 提交本地所有未推送的变更
2. 执行git fetch origin后，用git reset --hard origin/<分支名>重置本地分支
3. 避免因本地历史与远程不一致导致代码丢失

内容的提问来源于stack exchange，提问作者Manish Paul