Git 协作

merge 把两条分支的最新提交做一个三方合并，生成合并提交，历史呈真实网状，安全不改写既有提交，但长期小分支会让历史交错难读。rebase 把当前分支的提交摘下来依次重放到目标分支之后，得到线性整洁历史，但改写了提交哈希，已推送到共享分支的提交一旦 rebase 再强推会破坏他人历史。常见约定是个人特性分支拉取主干更新时用 rebase 保持自身线性，合入主干时用 merge 或压缩合并；绝不对多人共享分支 rebase。答题时提「变基黄金法则」与解决冲突时 rebase 需逐提交处理、merge 只需一次处理，能体现实操深度。

git fetch 只把远端的新提交与分支引用下载到本地远端跟踪分支（如 origin/main），不动工作区与本地分支，因此可以先 diff 审查再决定怎么合，是更安全的操作。git pull 等价于 fetch 之后立即执行一次 merge（默认），配置 pull.rebase 后则变为 fetch 加 rebase。差异的本质是「只同步引用」与「同步并合并到当前分支」。实践建议先 fetch 再 rebase 或 merge，避免 pull 带来的意外合并提交；CI 与脚本中应显式使用 fetch 以免工作区被改动。能讲清 refspec 与远端跟踪分支的对应关系是加分项。

HEAD 是指向当前检出位置的符号引用，通常指向某个分支名，分支再指向最新提交，提交后分支随之前移。当 HEAD 直接指向某个提交哈希而非分支时就处于分离头指针状态，常见于检出历史提交、tag 或 rebase 中途；此时新提交不属于任何分支，切走后容易被垃圾回收。找回「丢失」提交的方法是用 git reflog 查看 HEAD 的移动轨迹，找到目标哈希后用 branch 或 cherry-pick 固化到分支。要点是理解 Git 的快照与引用模型：提交不可变、分支只是可移动指针，reflog 是本地后悔药。大 refactor 前建分支是最便宜的保险。

冲突文件中的标记将区域分为三段：HEAD 侧是当前分支的改动，中间分隔线，另一侧是被合入分支的改动，理解两边意图后手工决定保留或融合，删除标记后 git add 标记为已解决，最后继续 merge 或 rebase。高效实践包括：小步快跑频繁同步主干减少冲突面；先跑测试确认语义正确而非只求文本合并；用 git checkout --ours/--theirs 处理明确取某侧的文件；冲突复杂时用 mergetool 三方对比界面。rebase 冲突会逐个提交出现，可用 git rerere 记录解法让重复冲突自动复用。答题时强调冲突本质是三方合并中基线与两侧同时改动同一区域，Git 无法替你做语义决策。

三者都涉及提交级操作但语义不同。cherry-pick 把任意提交复制应用到当前分支，生成新哈希，适合把修 bug 提交挑到发布分支或反向移植。revert 生成一个内容相反的新提交来撤销历史提交，历史向前演进，是共享分支上唯一安全的撤销方式，支持区间撤销。reset 移动分支指针到目标提交，配合 --soft 保留暂存、--mixed 保留工作区、--hard 全部丢弃，适合清理尚未共享的本地提交。核心判断标准是该提交是否已被他人获取：未推送可 reset，已共享必须 revert。混用强推与 reset 是协作大忌，能把边界讲清并通过 reflog 兜底即是好答案。