你和几位朋友合写一本《家常菜谱》，主本放在客厅，谁研究出新菜就誊一页进去。小 A 的笔记本叫 feature/a，小 B 的笔记本叫 feature/b。这天，两人都看上了「红烧肉」页面里那句「糖 20g」——A 记了 25g，B 记了 15g。誊抄进主本时，两段字在同一行紧紧叠在一起，谁都没法替对方做主。这就是 Git 世界里的冲突。有人喜欢把两本笔记本直接缝进主本，保留分叉交汇的痕迹，这叫 merge；有人喜欢把自己的改动重新誊写到主本最新一页之后，让整本书的页码一路顺到底，这叫 rebase。读完这篇「厨房攻略」，你会明白冲突不是灾难，而是协作的常态；你也能带着清晰的头脑，把一团乱麻的提交历史整理成一本干净整洁的菜谱。

岗位关联

对 AI 从业者来说，掌握冲突定位、merge 与 rebase 的选择智慧，是多人协作开发的基本功——它能让你在模型代码、训练脚本的合并中少些恐慌，多些掌控，把「合并事故」变成日常小事。

目录
  1. 可视化演示
  2. 冲突的本质
  3. 分支合并基础
  4. 冲突定位排查
  5. 手工解决冲突
  6. Rebase 变基原理
  7. 策略选择与纪律
  8. 交互式 Rebase
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Git合并冲突的产生与解决流程、rebase变基操作原理、以及rebase与merge历史对比，切换模式查看版本控制核心机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Git合并冲突解决流程 红色为当前分支(HEAD)，绿色为传入分支，橙色为冲突区域 三方合并：base + A + B → resolved 当两个分支修改同一区域时产生冲突，需手动编辑冲突标记后提交合并结果

冲突的本质

周末，小 A 和小 B 同时打开了「红烧肉」那一页。主本原本写着「糖 20g」，A 在笔记本上记：试试 25g，甜一点；B 在另一本上记：试试 15g，咸一点。誊抄时间一到，两个人都把自己的版本誊进主本同一行——没有哪本笔记能同时写下两个「正确」答案。Git 不是算术老师，算不出 25 和 15 哪个更好，它只会高举双手：这里乱了，请你们自己裁决。

这个场面在 Git 中叫冲突。要理解它为什么发生，先要知道合并时 Git 会看哪几个版本。Git 不会只拿当前分支和对方分支硬碰，它会翻出两个分支共同的「老祖宗版本」，也就是分叉那一刻的内容，叫做共同祖先。举个例子：主本「糖 20g」是小 A 小 B 共同读到的版本，它就是 base。

三个版本放在一起比对：共同祖先 B、当前分支 O、对方分支 T。只有三个条件同时成立，这一行才会被标记为冲突：第一，O 和 B 不同，说明我们这边改过；第二，T 和 B 不同，说明对方也改过；第三，O 和 T 不同，说明两边改的不是同一个结果。只要有一边没动，Git 就直接采用动过的那一版，根本轮不到你出场。

理解了「立案条件」，下次看到冲突标记就不会慌：这页菜谱上重叠的不是错误，而是两个认真研究同一道菜的人留下的双重痕迹。条件不满足，Git 自己就消化了；条件满足，才轮到你上桌。

C=(O≠B)∧(T≠B)∧(O≠T)C = (O \neq B) \land (T \neq B) \land (O \neq T)
这是冲突的「立案条件」：我方、对方、祖先三方各持一词，Git 需要你亲自裁决。
  1. O ≠ B（我方有改动）当前分支的版本和共同祖先不同，说明「我们这边」在分叉后动过这一行。
    O≠BO \neq B
  2. T ≠ B（对方有改动）对方分支的版本也与共同祖先不同，说明「对方」同样在这行做过修改。
    T≠BT \neq B
  3. O ≠ T（两边改法不同）两个分支最终写下的内容不一样，Git 无法自动判断谁对谁错。
    O≠TO \neq T
  4. 三者同时成立三个不等式用逻辑与连接，只有同时满足，该行才被判定为冲突。
    C=(O≠B)∧(T≠B)∧(O≠T)C = (O \neq B) \land (T \neq B) \land (O \neq T)

分支合并基础

主本只有一本，但谁都想在本子上随便写、慢慢试。于是大家从主本撕了几页空白纸，各自装订成小笔记本——这就是分支。小 A 的笔记本独立演进，小 B 的也独立演进，谁也不干扰谁。等菜谱有了定论，再把这些页整体誊回主本，这一步就是 merge。

merge 有两种常见结局。第一种最简单，叫快进合并：主本自从分叉以来没有新增内容，书签还停在原地，Git 直接把主本书签推到小 A 笔记本的最后一页——不产生新页，也不会冲突。第二种是真正的三方合并：主本自己也长出了新页，两条线各自发展，合并时要把两边的修改融在一起，产生一个提交，叫合并提交。普通提交只有一个父提交，像一页笔记知道它来自哪一页；合并提交不一样，它同时指向两条历史线的末端。

这就像誊完新页后，你在书页脚注写一行小字：本页内容同时来自小 A 的笔记本和小 B 的笔记本。双亲记录让后来的人顺着页码纵线，能追溯到每一处协作的真实分岔。

P(M)={A,B}P(M) = \{ A, B \}
合并提交 M 同时拥有两个父提交 A 和 B，这是它与普通单亲提交最本质的区别。
  1. P(M) 表示父提交集合P 是 parent 的缩写，集合记录了这个提交所有历史来源。
    P(M)P(M)
  2. A 与 B 是两个分支末端合并发生时，主线的当前提交 A 与被合并分支的提交 B 都是新提交的「爹」。
    A,BA, B
  3. 花括号表示同时拥有集合符号说明 M 不止一个父提交，而是同时继承两条线。
    {A,B}\{ A, B \}

冲突定位排查

冲突发生后，主本不会自动告诉你哪一页出了问题。你得先巡视整本书：哪些页夹了红色纸签？git status 就是主本的自带巡检查，它会在「未合并路径」一栏列出清单，告诉你哪些文件处于冲突状态，等待处理。

拿到清单后，用 git diff 翻到那一页，逐行看两边的字迹。红色纸签通常藏在文件内部，被三行特殊符号包围：第一行是 <<<<<<< 开头的一串，下面是我们这版的修改；然后一行 ======= 作分隔线；最后是 >>>>>>> 开头的对方版本。这个结构把「我们的答案」和「对方的答案」清清楚楚分成两栏。git status 负责告诉你「哪几页有红签」，git diff 负责展示「红签两边分别写了什么」，两者配合，问题就定位完了。

红纸签不是来添乱的，它只是把难题摆到桌面上。先看清纸签上分成两栏的字迹，才谈得上下一步怎么裁——永远不要在没看清两边方案之前就动手删行。

Fc={l∈F∣vB(l)≠vO(l)∧vB(l)≠vT(l)∧vO(l)≠vT(l)}F_c = \{ l \in F \mid v_B(l) \neq v_O(l) \land v_B(l) \neq v_T(l) \land v_O(l) \neq v_T(l) \}
冲突行集合的判定：在一份文件 F 中，恰好那些三方版本互不相同的行，会被 Git 打上冲突标记。
  1. l ∈ F 表示文件中的每一行把文件想象成一页菜谱，逐行检查哪些字迹重叠了。
    l∈Fl \in F
  2. v_B(l) 是共同祖先版本分叉前主本里这一行原本的内容，是我们的参考坐标。
    vB(l)v_B(l)
  3. 三个不等式依次对比祖先与两边不同、两边彼此不同，三个条件记入集合。
    vB(l)≠vO(l)∧vB(l)≠vT(l)∧vO(l)≠vT(l)v_B(l) \neq v_O(l) \land v_B(l) \neq v_T(l) \land v_O(l) \neq v_T(l)
  4. F_c 收集所有冲突行大括号把满足条件的行号一一收进集合，形成冲突清单。
    Fc={⋯ }F_c = \{ \cdots \}

手工解决冲突

裁决权在你手里，不在 Git 手里。打开红纸签夹着的那一页，你有三种常见处置：保留小 A 的 25g，保留小 B 的 15g，或者自己写个新数字 20g——只要把 <<<<<<<、=======、>>>>>>> 三行符号删干净，只留最终想留的内容，这一页就算理完了。

理完内容后，Git 并不知道你已经裁决完毕。你需要用 git add 把这个文件加入暂存区，这一步的含义是：告诉 Git，这个文件的冲突我处理完了。所有冲突文件都 add 之后，执行 git commit 生成合并提交，合并才算真正画上句号。如果处理到一半后悔了，git merge --abort 可以把主本恢复到合并开始前的样子，就像把誊了一半的页全部撕掉重新开始。

撕掉红纸签、贴好新字句、重新缝回主本——完成这三步，菜谱页清爽如初。而 merge --abort 这枚「后悔药」，保证你即使裁歪了，也有机会把主本还原，重新誊一遍。

v′(l)∈{vB(l), vO(l), vT(l)}v'(l) \in \{ v_B(l),\ v_O(l),\ v_T(l) \}
最终版本的每一行，既可以沿用祖先原样，也可以取我方或对方的内容，还可以由你手动改写。
  1. v'(l) 是最终留下的内容裁决后这一行在菜谱里的最终形态。
    v′(l)v'(l)
  2. 三个候选版本共同祖先、我方修改、对方修改，三者都摆在桌面上供你挑选。
    vB(l), vO(l), vT(l)v_B(l),\ v_O(l),\ v_T(l)
  3. ∈ 表示允许从中选择你可以三选一，也可以都不选，直接手写一个新值。
    ∈{⋯ }\in \{ \cdots \}

Rebase 变基原理

merge 是把两本笔记本拼在一起，留着一处处「这里汇合过」的结点。有人觉得页码弯弯绕绕不好读，于是换了思路：与其把两本笔记缝起来，不如把你笔记本上的几页改动，全部重新誊写到主本最新一页的后面。誊完之后，整本书变成一条笔直的线——这就是 rebase。

rebase 的全过程可以看作「重放」：Git 找到你的分支与主本分开的那个点，从这个点以后你提交过的每个改动，都要一个接一个地应用到主本最新历史的末尾。每重放一个提交，都会生成一个新提交——内容大致一样，但页码（哈希）完全不同，因为它的上一页换了。这就是为什么 rebase 是在改写历史：历史事件的顺序没变，但装订的页码全变了。

誊写改变的是页码而非内容，所以 rebase 的本质是改写历史。这就带来一条铁律——黄金法则：不要对已经推到共享远程的分支执行 rebase。好比主本已印刷分发到每个人手里，你再重新装订页码，大家的目录就全对不上了。

Ci′=apply( Ci,  Hi−1′ ),H0′=HmainC'_i = \text{apply}(\, C_i ,\; H'_{i-1} \,),\qquad H'_0 = H_{\text{main}}
第 i 个新提交，是把原始提交 C_i 的内容，应用到新历史 H' 的上一页之上生成的结果。
  1. C_i 是原始提交你笔记本上第 i 条改动记录，内容在那里，但页码已过时。
    CiC_i
  2. H' 是新目标历史主本现在的最新一页及其全部前史，作为誊写的新底本。
    Hi−1′H'_{i-1}
  3. apply 表示重放操作把改动内容重新应用到新底本上，得到内容相似、哈希全新的提交。
    apply( Ci,  Hi−1′ )\text{apply}(\, C_i ,\; H'_{i-1} \,)
  4. H'_0 从主线开始第一页誊写前，底本就是主本当前的最新提交。
    H0′=HmainH'_0 = H_{\text{main}}

策略选择与纪律

既然 merge 保留分叉记录、rebase 整理直线历史，那到底该用哪个？答案藏在「这本菜谱谁在看」里。主本（main / release）是所有人的共读本，被反复誊抄、印刷、分发——对它使用 merge，让每一次真实协作的交汇都留下印记；自己的功能分支是草稿本，还没发给别人——对它使用 rebase，把灵光一闪整理成工整洁净的条目。

衡量标准可以写成一条安全准则：一个分支只要已被很多人拉取并基于它继续写笔记，它就是共享分支，不要对它变基；只要还没共享、只属于你自己，随便整理。团队还可以约定具体流程：每个功能分支合并前先 rebase 到最新 main，再通过 merge 合回 main；公共分支上严禁强推改写历史。这样既保证主线历史线性易读，又不破坏任何人的本地副本。

菜谱团队立规矩：草稿本随便涂改，印刷版盖棺定论。这套纪律执行下来，提交历史既真实又整洁，新成员翻开目录，一眼就能读懂这本书的来龙去脉。

safe=¬ shared(branch)\text{safe} = \neg\ \text{shared}(\text{branch})
rebase 的安全条件：当且仅当目标分支没有被共享时，变基才是安全的。
  1. shared(branch) 判断共享状态这条分支是否已经被其他人拉取并继续产生了提交。
    shared(branch)\text{shared}(\text{branch})
  2. neg 表示逻辑否定前面的小横线把「已共享」翻转为「未共享」。
    ¬\neg
  3. safe 为真才可变基只要分支不被共享，rewrite 历史不会影响别人，操作就安全。
    safe=⋯\text{safe} = \cdots

交互式 Rebase

基本功练熟后，你还可以在誊写时顺便整理草稿：把主题重复的两页合成一页、给标题写错的页换个名字、把写废的实验页直接抽掉。这就是交互式 rebase（git rebase -i）的魔力——在重写历史的过程中，加工你想加工的提交。

交互式 rebase 会打开一个任务列表，每个提交前面都可以写一个命令。最常用的四个：pick 表示保留这个提交原样不动；reword 表示保留内容，但修改提交说明；squash 表示把这个提交和它前一个提交合并成一页；drop 表示整页丢弃。列表编辑保存后，Git 按顺序逐个处理，全部完成，历史就按你的意图重排了。整个过程只作用于未推送的草稿分支，安全可控。

要注意，这些整理动作只能作用于还未共享的草稿。已经印发的菜谱，重新装订会引发混乱。先确认分支只属于自己，再放心地用这四把剪刀，把历史收拾成一本干净、清晰、让人愿意读下去的书。

R=(p1,p2,…,pn),pi∈{pick, reword, squash, drop}R = (p_1, p_2, \dots, p_n),\qquad p_i \in \{ \text{pick},\ \text{reword},\ \text{squash},\ \text{drop} \}
交互式 rebase 的本质，是把 n 个待处理提交依次标注一个操作命令，再按命令序列逐个执行。
  1. R 是命令序列整个整理计划，就是一个按照提交顺序排好的操作清单。
    (p1, p2, …, pn)(p_1,\ p_2,\ \dots,\ p_n)
  2. p_i 是每个提交的命令每个提交只会执行一种操作，不会同时做两件事。
    pip_i
  3. 四个合法命令pick 保留、reword 改名、squash 合并、drop 删除，这就是全部选项。
    pick, reword, squash, drop\text{pick},\ \text{reword},\ \text{squash},\ \text{drop}

AI 应用场景

模型配置文件冲突处理

阶段：多人协作开发与模型迭代

解决的问题：训练脚本里的 config.yaml 常被多人同时修改，learning_rate、batch_size 这些关键参数一旦被两个人改成不同值，git merge 就会报冲突。没有流程时，大家靠反复复制文件、口头沟通，极易丢失实验版本。

具体案例：两位研究者在同一份 config.yaml 里，一个把 learning_rate 改为 3e-4，另一个改为 1e-3。合并时 Git 在文件中标出两段冲突。研究者用 git status 定位文件，git diff 对比两边参数，最后保留其中一个值并 git add、git commit，完成一次干净的合并。

用交互式 rebase 整理实验提交

阶段：实验管理与代码评审前准备

解决的问题：一个人跑实验时，会在功能分支上留下大量「试一下」「改参数」「又改了」的琐碎提交，直接合并进主干，会让主干历史杂乱无章，reviewer 难以阅读。

具体案例：MLOps 工程师在 feature/tuning 分支上累计了 18 个实验提交。提 PR 前执行 git rebase -i HEAD~18，把相关的提交 squash 成「调优学习率」「增加数据增强」「更新评估脚本」三个干净提交，再 rebase 到最新 main，最后 merge 回主干。CI 流水线上的历史一目了然。

公共分支用 merge、个人分支用 rebase 的团队约定

阶段：团队协作规范与持续集成

解决的问题：AI 项目往往模型、数据、服务端代码在同一仓库共存，多人并行开发。如果不约定合并策略，公共分支反复被强推改写，会导致大家本地仓库历史错乱。

具体案例：团队规定：main 与 release 分支只接受 merge，禁止 rebase 和 force push；功能分支合并前必须先 rebase 到最新 main。这样一来，主干历史保留真实的汇合结点，个人分支干干净净，任何人的本地副本都不会突然「消失」提交。

Python 演示

python39 行
def three_way_merge(base, ours, theirs):    """模拟 Git 三向合并, 逐行比对三个版本"""    merged = []    conflicts = []    total = max(len(base), len(ours), len(theirs))    for i in range(total):        b = base[i] if i < len(base) else ""        o = ours[i] if i < len(ours) else ""        t = theirs[i] if i < len(theirs) else ""        if o == t:            merged.append(o if o else b)        elif b == o:            merged.append(t)        elif b == t:            merged.append(o)        else:            conflicts.append(i + 1)            merged.extend(["<<<<<<< ours", o, "=======", t, ">>>>>>> theirs"])    return merged, conflicts  def show(merged):    for no, line in enumerate(merged, 1):        print("%3d | %s" % (no, line))  def main():    base = ["糖 20g", "加水 500ml", "小火 30 分钟"]    ours = ["糖 20g", "加水 500ml", "小火 60 分钟"]    theirs = ["糖 30g", "加水 500ml", "小火 30 分钟"]    merged, rows = three_way_merge(base, ours, theirs)    show(merged)    print("冲突行号:", rows)    if rows:        print("请打开文件手动编辑冲突区域后再提交")  if __name__ == "__main__":    main()
目的：用一个小型 Python 脚本模拟 Git 三方合并的核心逻辑，逐行比对共同祖先、我方、对方三个版本，输出合并结果与冲突行号，帮你直观理解冲突产生的条件。
  1. for i in range(total)逐行扫描三个版本，长度不足的行按空字符串处理，保证每个位置都能比对。
  2. if o == t:两边改的内容一样，直接采用，这是最理想的无冲突情况。
  3. elif b == o:我方没改而对方改了，自动采用对方版本。
  4. elif b == t:对方没改而我方改了，自动采用我方版本。
  5. conflicts.append(i + 1)三方各不相同，记下这一行的行号，等待人工裁决。
  6. merged.extend(["<<<<<<< ours", ...])在输出中插入冲突标记块，模拟 Git 写入文件的实际格式。
  7. if __name__ == "__main__":保证脚本被直接运行时执行 main，被导入时只提供函数。

常见误区

误区我刚对一个分支执行 rebase，原来的提交哈希全都不见了，Git 是不是把我的提交删除了？那些辛苦写的代码还能找回来吗？

正解rebase 并没有删除提交，而是生成了一批内容相似、哈希全新的提交，并把分支指针指向新提交。原提交依然静静地躺在仓库里，只是不再被任何分支引用，就像你重新誊写笔记后，旧笔记本还放在抽屉里。只要没执行垃圾回收，随时可以找回。所以不必恐慌，rebase 是「誊写」而不是「撕毁」。

为何常见：人眼看到哈希变化，很容易误以为内容消失；加上 Git 的底层对象模型对初学者不透明，就形成了「提交被删」的错觉。

误区反正 rebase 能把历史变直，我直接对 main 分支 rebase 再 force push，大家拉取后历史不就干净了吗？

正解这正是黄金法则明令禁止的操作。main 已经被所有人共享，你改写它的历史，等于把已印刷的书重新编页码。其他同事基于旧 main 的提交会突然「消失」，下次 pull 时出现大量重复结点和冲突。干净属于你，混乱却蔓延给所有人。共享分支应当用 merge，让它原封不动地记录真实交汇。

为何常见：人容易只从自己视角看问题，觉得本地历史乱就全局乱，忽略了团队成员各自的本地副本。

误区一打开文件看到 `<<<<<<<` 和 `>>>>>>>` 就手心冒汗，觉得代码被 Git 弄坏了，是不是整个项目都废了？

正解冲突只是 Git 在说「两边改了同一处，我无法自动替你决定」。文件并没有损坏，标记只是把两版内容隔开展示的提示符。你只需删掉标记、选择要保留的版本，再 git add、git commit，一切照常。冲突越多，只能说明改动的重叠点多，而不是项目出了大事故。

为何常见：恐惧来自未知。初学者第一次看到满屏标记符号，不知道它们的语义，便默认是灾难信号，而忽略了 Git 只是把决策权交还给你。

误区听说 rebase 会改写历史，风险太高，所以任何时候都用 merge，绝对不用 rebase，这样最保险。

正解危险的不是命令本身，而是你对共享历史的态度。merge 保留分叉记录，但会让历史出现大量「合并结点」；rebase 整理线性历史，让提交序列清爽易读。在个人未推送的分支上 rebase 完全安全，在公共分支上 merge 才是纪律。把 merge 当作万能药，只会让主干历史越堆越乱，反而增加后续冲突概率。

为何常见：人倾向于把抽象风险归因于工具，却忽略真正决定风险的是操作对象和团队约定。rebase 的「危险性」被口口相传放大，成了条件反射式的偏见。

误区我把冲突文件改好了，也执行了 `git add`，Git 应该已经认同我了，直接 push 就能完成合并了吧？

正解git add 只表示「这个文件的冲突已解决完」，它把文件放入暂存区，但合并还没有正式提交。必须再执行 git commit 生成合并提交，把双亲历史钉在仓库里，push 才有意义。少了 commit，本地只是暂存了改动，远端根本不会知道这次合并的存在。红纸签撕掉后，你还得把这一页真正缝进主本。

为何常见：人们对暂存区（index）和提交（commit）的职责区分模糊，以为 add 就等于完成，忽略了 Git 的提交环节是不可跳过的最终落笔。

面试题

Q1. Git 产生合并冲突的根本条件是什么？

单选题 · easy

  • A.只有一方改动而另一方原样
  • B.两边都对文件的同一行做了修改← 正确答案
  • C.两个分支的提交信息完全相同
  • D.本地仓库和远程仓库没有关联

答案：B。冲突要求共同祖先 B、我方 O、对方 T 三者之间三个不等式同时成立。B 选项完整描述了「两边都改了同一行且改法不同」的立案条件。A 情况不会被判定为冲突，C、D 与冲突判定无关。记住菜谱里 25g 对 15g 的故事，两边都动了同一行，才是麻烦的开始。

Q2. 冲突文件中 <<<<<<< 和 >>>>>>> 这两个标记的作用是什么？

单选题 · easy

  • A.提示该文件已经被人删除
  • B.提示文件需要重新命名
  • C.把两边修改隔开供人裁决← 正确答案
  • D.标记代码里的注释区域

答案：C。冲突标记把「我方版本」和「对方版本」隔成两个区块，中间用 ======= 分隔，等待开发者人工选择。它就像菜谱页里夹着的红纸签，把重叠的两段字迹分栏展示，而不是表示删除或重命名，更与注释无关。

Q3. 什么是 Git 的快进合并（fast-forward）？

单选题 · easy

  • A.合并操作必定会产生冲突
  • B.两个分支的历史完全无关
  • C.对方分支已经被强制删除
  • D.主线没有新增分叉提交← 正确答案

答案：D。快进合并发生在当前主线自分叉后没有任何新提交时，Git 只需把分支指针直接向前移动到被合并分支的最新提交。主线这页没人动过，书签直接推到最新页，既无冲突也不产生合并提交，因此选项 A、B、C 都不成立。

Q4. 解决完冲突文件后，下列哪个操作才能完成这次合并？

单选题 · mid

  • A.只需执行 git add 标记暂存
  • B.执行 git commit 生成合并提交← 正确答案
  • C.执行 git pull 拉取最新代码
  • D.执行 git status 查看一下状态

答案：B。git add 只是把解决好的文件标记为「已暂存」，合并的最终落笔是 git commit，它会生成一个带有双亲提交的合并提交。git pull 是拉取远端，git status 只是查看状态，都不能完成合并。就像撕掉红纸签后，还要把这一页重新缝进主本才算数。

Q5. 下列哪些情况适合使用 rebase？

多选题 · mid

  • A.从未推送的本地功能分支← 正确答案
  • B.多人共享的公共主干分支
  • C.已经推送到远处的旧分支
  • D.团队约定的独立个人分支← 正确答案

答案：AD。rebase 的核心约束是「只改写未共享的历史」。A 与 D 都是不与他人共享的分支，可以放心整理；B 和 C 已经暴露给其他人，rebase 会让同事的本地历史错乱，违反黄金法则。草稿本随便誊，印刷本不能动。

Q6. 为什么 rebase 之后提交哈希会发生变化？

单选题 · mid

  • A.提交内容被完整改写复制
  • B.父提交变化导致哈希重算← 正确答案
  • C.文件内容被自动全部清空
  • D.时间戳被强制归零重置

答案：B。提交哈希由父提交、提交信息、内容快照等共同计算。rebase 把提交重放到新底本之上，父提交必然改变，即使内容一字不差，哈希也会随之更新。这就像重新装订后的菜谱，页码一定和原来不同。时间戳与内容清空都不是哈希变化的本质原因。

Q7. 下列哪些做法符合安全的 rebase 纪律？

多选题 · hard

  • A.只对未推送的提交进行变基← 正确答案
  • B.变基前先跑测试保证稳定← 正确答案
  • C.对公共分支直接强推变基
  • D.向团队确认好自己的分支← 正确答案

答案：ABD。安全变基的三要素：对象未共享、操作前验证、团队知情。A、B、D 分别覆盖这三条；C 恰恰是黄金法则的反面教材，公共分支直接强推会让所有协作者本地历史错乱，必须禁止。

Q8. 在交互式 rebase 中，给提交标注 drop 会发生什么？

单选题 · hard

  • A.从提交历史中移除该提交← 正确答案
  • B.保留待提交并修改其消息
  • C.把当前提交合并到前一个
  • D.将本地提交强制推到远程

答案：A。drop 表示整页丢弃，该提交会从重放序列中消失，不再出现在新历史里。reword 才是修改提交消息，squash 是把当前提交并与前一个合并，push 与本地历史整理无关。丢弃前要确认改动内容确实不需要，因为后续若想找回，只能去仓库底层翻找。

Q9. Git 三方合并会比对哪三个版本？

多选题 · easy

  • A.共同祖先版本的历史记录← 正确答案
  • B.当前分支版本的完整内容← 正确答案
  • C.对方分支版本的完整内容← 正确答案
  • D.代码评审记录里的修改意见

答案：ABC。三方合比拼的是共同祖先 B、当前分支 O、对方分支 T 三个版本。共同祖先是分叉那一刻的底本，当前分支和对方分支是各自演进后的结果。代码评审意见只是人为沟通，不参与 Git 的自动合并算法。菜谱里那行「糖 20g」就是三个版本共同的起点。

Q10. 团队成员 B 在共享分支 main 上执行 rebase 并 force push 后，同事 A 基于旧 main 继续开发，接下来 A 最可能出现什么？

单选题 · extreme

  • A.A 的提交会与远端反复冲突← 正确答案
  • B.A 的本地仓库会自动跟随变基
  • C.A 的所有提交哈希变得相同
  • D.A 的分支历史完全不会受影响

答案：A。A 的本地位于旧 main 之上，远端 main 已被 B 改写，两条线再次分叉。A 执行 pull 时，Git 会尝试把本地提交合并到全新的远端历史上，出现大量重复提交与冲突，甚至需要重新手工合并。本地仓库不会自动跟随变基，哈希也不会因此变得相同。这就是黄金法则禁止共享分支 rebase 的原因——你以为在整理自己的菜谱，实际把别人的目录全打乱了。