Git分支已分叉：选择merge还是rebase
这些代码块对应不同情况，不是一个完整脚本。请选择适合仓库的情况，并替换分支名、路径和VERIFIED_COMMIT。中止命令只适用于对应的正在进行的操作，不要执行两种备选方案。
简短答案
分支diverged表示本地与upstream各有对方不包含的提交。先fetch，审查两侧，再选择整合方式。merge保留历史；rebase把本地提交重放到upstream并改变ID。警告描述图的关系，并不证明文件丢失。
示例与前提
例子是跟踪origin/main的main，有两个本地提交和一个远程提交。确认实际分支与upstream。fetch更新远程跟踪引用，不会自行合并到当前分支。remote改名或没有upstream时，要调整命令名称。
修改前检查状态
先看status与branch -vv，再fetch origin。HEAD...origin/main的左右计数显示各侧独有提交数，还要读图和补丁。两比一不能说明是否改了同一函数。不要用过期的远程引用或单独计数作出诊断。
git status --short
git branch -vv
git fetch origin
git rev-list --left-right --count HEAD...origin/main
git log --oneline --graph --decorate HEAD origin/main保留引用或独立检出
整合前，在本地末尾创建rescue/before-sync，未提交更改单独保存。分支保留已提交历史；stash对跟踪、新文件和忽略文件的覆盖不同。确认保存结果。带着无关编辑做整合会让冲突与恢复更难理解。
git branch rescue/before-sync HEAD第一种操作
应保留现有历史时，尤其本地提交已共享时，选择merge。merge origin/main整合取得的upstream与当前分支，分叉时通常记录两个父提交。发布前审查diff和项目检查。成功完成merge不保证组合代码正确。
git merge origin/main有意选择另一种结果
仅对团队允许重写的本地提交选择rebase。rebase origin/main重放本地工作，通常产生新ID。其他人可能依赖旧ID。更线性的图不等于获得重写共享分支或绕过保护规则的授权。
git rebase origin/main限制与例外
merge冲突时读status、解决并暂存相关文件，再完成；符合条件时merge --abort可取消。rebase中解决当前冲突再rebase --continue，可能停多次。rebase --abort取消正在进行的rebase。不要混用两种流程。
git status
git merge --abortgit rebase --abort冲突与清理
reset --hard origin/main不是通用答案：它从当前分支移除独立本地历史，还可能覆盖跟踪文件。这是有意放弃工作的另一种决定，本指南要组合所需历史。若想丢弃，先检查提交并在专门流程中保存必要副本。
验证结果
检查最终图、状态、相对origin/main的差异和项目测试。fetch后远程可能再次推进，普通push因而被拒绝。重新获取并审查新状态，不要自动改用force push。整合及影响审查完成前保留救援引用。
git status --short
git log -8 --oneline --graph --decorate
git diff origin/main HEAD常见问题
pull为何要求策略？它包含fetch与可能不明确的整合选择。merge不会永远避免冲突，rebase也会冲突。没有一种方法永远更好；提交是否共享和团队历史政策比普遍偏好更重要。
在FluxGit中审查操作
使用FluxGit的可视历史与差异视图审查操作及相关提交。保留本例中的分支、共享历史和本地文件检查。下载页面列出当前提供的版本及平台。