Git · XB 现场笔记

merge 与 rebase 画出的历史线不同

Tue, 18 Jan 2028 00:00:00 +0000

merge 与 rebase 都能整合工作，却对提交身份和祖先关系产生不同影响。合并通常保留既有提交并连接历史，变基则把选定变化移到另一基线。选择不只是图形看起来是否整齐，还影响评审引用、冲突处理、签名，以及已经依赖旧提交的协作者。应依据仓库流程与真实分支关系决定，而不是把“线性一定更好”或“有合并提交就一定安全”当成通用判断。

合并记录什么

两个末端已经分叉时，普通双分支合并创建以这两个末端为父级的新提交，并记录结果目录树；既有提交保持原身份。图保留的是祖先关系，不是所有活动的完整时间排序。提交日期与界面展示顺序也不能替代父级关系，否则可能把并行工作误读成严格前后发生的一串事件，进而错误判断某项修改究竟基于什么版本。

如果当前末端是传入末端的祖先，合并可以直接快进分支，不创建额外合并提交。要求始终创建合并提交，是通过相应选项表达的另一项流程规则。反过来，即便结果保留两个父级，也不能证明双方预期行为都正确保留。仍需审阅内容并运行集成测试，不能用提交拓扑替应用接口、数据规则或发布依赖完成验收。

变基改变什么

普通变基识别选定提交，再把它们的变化重新应用到新基线。重新创建的提交只要父级不同，对象标识就不同，即便补丁看起来相同。原作者信息通常保留，但新对象仍需自己的验证，以及流程要求的签名。指向旧对象的评审链接，也不会自动变成指向新对象的链接；后续说明需要让读者能够找到实际接受审阅的结果。

并不是每次变基都会重写所有提交：分支已经更新时可能无需重放；上游等价变化或应用后的空结果，也会影响哪些提交留下。普通变基从重放序列中省略合并提交，让选定工作趋于线性；明确启用重建合并的模式，则会尝试恢复分支结构。因此，“变基永远得到直线”同样过度概括，具体结果取决于参数和输入历史。

合并协调的是分支末端，变基通常逐个处理提交，所以冲突出现的位置与次数可能不同，同一种取舍还可能需要多次执行。完成后应比较最终目录树及重放变化，并重新运行相关测试。补丁相似，不证明新基线上行为完全相同；依赖、接口和上下文已经改变时，文本能够落地只是审查的开始。

坏掉的样子

重写其他工作已经依赖的提交，会产生协调成本。私人且未发布的分支，通常比共享集成分支更适合变基。明确协商过的共享历史重写并非不可能，但必须识别受影响引用及消费者。偏好线性历史，不等于获得替换别人已发布工作的权限；是否应该执行，需要独立于工具是否支持来判断。

变基本身并不必然要求强制推送。新的远端分支可以普通创建；远端末端仍是本地结果祖先时，也可以正常快进。需要替换已被重写的远端提交，才属于非快进情况。即便使用租约，它也只是根据预期远端值作并发检查，不代表已经批准替换，也不能证明所有协作者都已被考虑。发布前应先确定真实引用关系，而不是机械套用强推命令。

变基冲突中，合并后端所称的本方，是目前已构建的变基历史，包含上游基线；对方则是正在重放的提交。这可能与开发者按原功能分支理解的“我的版本”相反。应检查实际文件版本和目标契约，再决定如何解决；暂存具体文件后继续。跳过会丢弃当前补丁，并不是自动修好这次冲突，不能为了让过程继续就忽略它的业务含义。

决定放弃操作时，中止变基会恢复起初的分支状态。--quit 则只停止管理变基，保留当前 HEAD、索引与工作文件，并不是等价的撤销命令。需要恢复起点时，不能因为两者都会结束流程就随意替换。从干净工作区开始，有助于明确恢复结果。不要把中止当成在过程中保存任意无关编辑的通用备份，也不要用强制清理作为常规冲突处理方式。应先理解当前序列、索引与文件中有哪些有效成果，再选择与操作意图匹配的恢复路径。

快速验证

在 POSIX 系统上使用 Python 3 与 Git 2.28 或更新版本运行下面实验。它在临时仓库中使用示例身份，关闭钩子与签名，没有远端，并排除继承的 Git 路由及个人配置。两个分支从同一个主题提交起步，以不同方式整合一项独立上游变化；第三个分支有意制造新增同名文件的冲突，检查中止恢复，而不碰当前项目的实际历史。

import os
import subprocess
import tempfile
from pathlib import Path

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-merge-rebase-") as directory:
 root = Path(directory)
 def git(*args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=History Example",
 "-c", "user.email=history@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=root, env=env, text=True, capture_output=True, check=check,
 )
 git("init", "-q", "-b", "main")
 git("commit", "--allow-empty", "-qm", "base")
 git("switch", "-qc", "topic")
 (root / "topic.txt").write_text("feature\n")
 git("add", "topic.txt")
 git("commit", "-qm", "feature")
 original = git("rev-parse", "HEAD").stdout.strip()
 git("branch", "merge-case")
 git("branch", "rebase-case")
 git("switch", "-q", "main")
 (root / "main.txt").write_text("upstream\n")
 git("add", "main.txt")
 git("commit", "-qm", "upstream")
 upstream = git("rev-parse", "HEAD").stdout.strip()
 git("switch", "-q", "merge-case")
 git("merge", "--no-edit", "main")
 merged = git("rev-parse", "HEAD").stdout.strip()
 print("merge-keeps-two-parents:", git("rev-parse", "HEAD^1").stdout.strip() == original
 and git("rev-parse", "HEAD^2").stdout.strip() == upstream)
 git("switch", "-q", "rebase-case")
 git("rebase", "main")
 rebased = git("rev-parse", "HEAD").stdout.strip()
 print("rebase-changes-commit:", rebased != original
 and git("rev-parse", "HEAD^").stdout.strip() == upstream)
 print("same-result-tree:", git("rev-parse", f"{merged}^{{tree}}").stdout
 == git("rev-parse", f"{rebased}^{{tree}}").stdout)
 print("original-topic-retained:", git("rev-parse", "topic").stdout.strip() == original
 and git("merge-base", "--is-ancestor", original, rebased, check=False).returncode == 1)
 git("switch", "-qc", "conflict", "topic")
 (root / "main.txt").write_text("topic alternative\n")
 git("add", "main.txt")
 git("commit", "-qm", "alternative upstream file")
 before = git("rev-parse", "HEAD").stdout.strip()
 stopped = git("rebase", "main", check=False)
 print("rebase-conflict-stops:", stopped.returncode != 0 and bool(git("ls-files", "-u").stdout))
 git("rebase", "--abort")
 print("abort-restores-branch:", git("rev-parse", "HEAD").stdout.strip() == before
 and git("symbolic-ref", "--short", "HEAD").stdout.strip() == "conflict"
 and (root / "main.txt").read_text() == "topic alternative\n"
 and not git("status", "--porcelain").stdout)

六个判断都应为真。合并具有两个准确父级，变基则在上游末端创建新的主题提交。这个故意不冲突的样例中，两者结果目录树相同，原主题提交也仍由独立分支保留。之后新增同名文件的冲突让变基停止，中止恢复该分支准确的末端、文本和干净状态。实验没有执行或暗示任何远端更新，局部成功不能被解释成共享历史替换已经获批。

来源

Git rebase 参考，重放选择、重建合并、冲突两侧和中止行为，已核验 2026-10-15。
Git merge 参考，父级关系、快进及结果目录树，已核验 2026-10-15。

git merge 用一个新的提交把分叉的两条线接起来

Wed, 29 Dec 2027 00:00:00 +0000

合并连接两段历史，并记录项目的结果快照。普通的双分支分叉合并，会创建同时把两个原末端作为父级的新提交。这些父级关系让更早的提交仍然可达，却不能证明最终文件保留了每一项预期行为。合并既是图上的连接，也是内容上的决定；只检查其中一面，会漏掉另一面真实存在的错误，不能把“两个父提交都还在”当作功能没有丢失的证据。

父级保留历史，不把它改写成单线

如果当前末端是传入末端的祖先，快进可以直接移动当前分支引用，不需要额外合并提交。当两侧各自拥有新提交后，普通合并才产生双父级结果：第一个父级是合并前的当前末端，第二个是传入末端。图中依然包含两条历史线，并没有把它们重新写成一串线性提交。阅读历史时，应区分分支名字的变化与提交图本身的形状。

Git 通常借助合并基点协调两侧末端；更复杂的历史可能涉及多个基点。相对共同祖先比较，可以区分某一侧确实修改的内容和保持不变的上下文。但文本结果干净，只表示选定合并机制找到了一种组合文件的方法，不代表 Git 理解了应用接口、业务规则或发布依赖。这些含义仍需通过源码关系、约定和测试来判断。

记录连接之前先审阅结果树

开始前应明确并保留当前工作状态。未提交修改可能阻止合并，也可能让失败后重建原状态变得复杂。不能假定中止操作能够恢复任意在合并前或合并期间发生的编辑。还应记录真正被连接的分支末端对象，让审阅和后续检查针对稳定对象，而不是继续变化的名称；否则两次观察可能根本不是同一组输入。

如果流程要求显式审阅合并提交，可以让 Git 在记录提交之前暂停。但不提交选项无法阻止快进，所以即使线性情况也要求生成合并提交时，需要同时关闭快进。暂停后检查暂存变化，把候选结果与两个父级分别比较，并运行任意一侧所影响的测试。下面的实验正是在这个暂停点发现行为不兼容，先修复再记录合并，而不是把有问题的组合直接当成成功。

压缩合并是另一种选择：--squash 准备组合内容，但不记录 MERGE_HEAD，之后普通提交也不会把传入末端记作父级。因此，即便最终文件看起来相同，祖先关系以及未来合并的判断基础也可能不同。需要保留双父级证据时，不能把压缩提交误认为普通合并的等价记录。

坏掉的样子

文本冲突不限于两边改动同一行。删除、重命名、二进制变化及其他不兼容操作，都可能需要人工决定。应使用工作区状态及索引中的未合并条目识别未解决路径。普通文本冲突中的标记方便查看双方内容，但没有发现这些字符串，不能证明所有冲突已经解决，更不能代替对二进制文件或路径结构的检查。

解决应遵循组合后程序的真实契约，再暂存具体路径并继续或提交。删除标记、执行暂存，只是在告诉 Git 已经提供了解法，不是在证明解法正确。生成文件应先协调权威输入，再通过生成器重建；不能把两个生成结果拼成看似合理的输出，否则下次构建还会覆盖人工拼接，甚至与输入表达的规则不一致。

更隐蔽的是文本干净却行为损坏。一条分支可能收紧函数参数形式，另一条同时增加仍按旧形式调用的代码。它们修改不同文件，各自测试都可以成功，组合后却失败。因此，集成测试必须覆盖这次组合新形成的调用关系，不能只是把两份分支测试摘要并排放在一起，就认为结果也已经通过同样验证。

策略选择还可能主动丢弃内容。偏向传入方的冲突选项，会优先采用传入方的冲突片段，同时保留其他非冲突变化；它不是自动保留双方意图的通用规则。另一种名为 ours 的策略则保留当前目录树，却仍把另一侧历史记录为已合并。因此，双父级图不能证明传入实现真的被采用。类似选择必须有明确依据并审查内容，不能只为让冲突提示消失而使用。

快速验证

在 POSIX 系统上使用 Python 3 和 Git 2.28 或更新版本运行下面实验。全部工作都在临时仓库，使用示例身份，没有远端，关闭钩子与签名，并排除继承的 Git 路由和个人配置。一条分支要求 Python 接口使用关键字参数，另一条分支新增位置参数调用。关闭字节码写入，是为了避免测试产生的缓存混入工作树状态，便于准确检查最终仓库是否干净。

import os
import subprocess
import sys
import tempfile
from pathlib import Path

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-merge-demo-") as directory:
 root = Path(directory)
 def git(*args):
 return subprocess.run(
 ["git", "-c", "user.name=Merge Example",
 "-c", "user.email=merge@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=root, env=env, text=True, capture_output=True, check=True,
 )
 def python(*args):
 return subprocess.run([sys.executable, "-B", *args], cwd=root,
 text=True, capture_output=True)
 git("init", "-q", "-b", "main")
 (root / "api.py").write_text('def render(name):\n return "Hi " + name\n')
 git("add", "api.py")
 git("commit", "-qm", "base API")
 git("switch", "-qc", "topic")
 (root / "api.py").write_text('def render(*, name):\n return "Hi " + name\n')
 git("add", "api.py")
 git("commit", "-qm", "require a named argument")
 topic = git("rev-parse", "HEAD").stdout.strip()
 topic_test = python("-c", 'from api import render; print(render(name="Ada"))')
 print("topic-test-passed:", topic_test.returncode == 0 and topic_test.stdout == "Hi Ada\n")
 git("switch", "-q", "main")
 (root / "client.py").write_text('from api import render\nprint(render("Ada"))\n')
 git("add", "client.py")
 git("commit", "-qm", "add a caller")
 main = git("rev-parse", "HEAD").stdout.strip()
 main_test = python("client.py")
 print("main-test-passed:", main_test.returncode == 0 and main_test.stdout == "Hi Ada\n")
 git("merge", "--no-ff", "--no-commit", "topic")
 print("text-merge-clean:", not git("ls-files", "-u").stdout
 and git("rev-parse", "MERGE_HEAD").stdout.strip() == topic)
 broken = python("client.py")
 print("combined-behavior-failed:", broken.returncode != 0 and "TypeError" in broken.stderr)
 (root / "client.py").write_text('from api import render\nprint(render(name="Ada"))\n')
 fixed = python("client.py")
 assert fixed.returncode == 0 and fixed.stdout == "Hi Ada\n", fixed
 git("add", "client.py")
 git("commit", "-qm", "merge topic and adapt the caller")
 print("reviewed-merge-parents:", git("rev-parse", "HEAD^1").stdout.strip() == main
 and git("rev-parse", "HEAD^2").stdout.strip() == topic)
 print("fixed-and-clean:", not git("status", "--porcelain").stdout)

六个观察都应为真。两条分支各自检查成功，Git 也没有报告未合并路径，但组合后的调用抛出类型错误。把调用方适配为关键字参数后，恢复预期输出，再记录合并。最终提交拥有两个准确的父级，工作树干净。这验证了一次真实的干净合并故障及其修复，也说明历史仍然可达，与最终行为正确，是必须分别验收的两件事。

来源

Git merge 参考，合并状态、父级、审阅控制和策略语义，已核验 2026-10-15。
Pro Git：分支与合并基础，快进、三方合并及未解决路径，已核验 2026-10-15。

git stash 把改动暂存到别处

Sat, 11 Dec 2027 00:00:00 +0000

Git stash 记录选定的未提交工作，让检出可以暂时回到较早的已提交状态。它适合短暂中断，但保存和恢复都不是对目录中所有文件的无条件承诺。真正需要确认的是包含了什么、工作原来基于哪个版本、目标现在处于什么状态，以及保存条目何时才能移除。只看到命令报告成功，还不足以证明所有想保留的数据都已经纳入快照。

明确快照包含的范围

普通保存操作记录受跟踪文件的工作树变化与索引，再把这些修改退回到 HEAD 对应状态。未跟踪文件默认留下，只有加入相应选项才会一起保存；被忽略文件在包含未跟踪文件时仍然留下，需要更大的包含范围才会纳入。选择之前先检查，因为忽略路径里可能有凭据、大型构建输出或不适合进入 Git 对象的本地数据，不能为了追求“全部收起来”就不看内容。

选定路径、只处理已暂存内容、保留索引等选项，会产生不同结果。不要习惯性组合参数，再假定它们代表同一份快照。应先检查状态与预期差异，为条目写明含义，并查看实际保存的内容，再把原编辑视为已经能够恢复。尤其要区分磁盘文本和索引文本，它们可能在同一路径上分别代表两阶段尚未完成的工作。

stash 使用 Git 提交对象表示，不是对象库之外的特殊文件。最新条目由专用引用指向，更旧的条目通过该引用的日志保留，所以普通分支历史不一定显示它们。忘记使用并不自动等于丢失，但删除保留引用之后，对象最终可能无法恢复。本地分支或 stash 也不会仅凭存在，就提供一份独立的异地备份；保存形式与备份位置是不同问题。

应用与弹出不同

应用命令尝试恢复，同时保留保存条目，适合先审阅恢复结果，再决定是否删除副本。默认不能期待原来的已暂存与未暂存区别自动重建；索引选项会额外尝试恢复这一状态，但如果冲突或目标变化妨碍恢复，仍可能失败。应检查索引和磁盘各自的结果，而不只看最终文件里是否出现了某段文字。

弹出操作只在应用成功后才从列表移除条目。发生冲突时，保存项保留，但能够干净应用的路径可能已经改变。因此，非零返回不代表整个工作树完全没动。再次操作前应查看索引和文件，不能在部分恢复的目录上反复弹出同一条目，指望重复执行自动修复第一次冲突。

条目不属于某个分支或关联工作树私有。描述中出现的原分支名称是背景，不是强制只能在那里恢复的规则。随着新增和删除，数字选择器还会变化，所以敏感操作前要检查并记录准确对象。在 Shell 中传入带花括号的选择器时应引用，避免外层语法干扰。需要删除的究竟是哪份内容，应由对象证据确认，而不是仅凭它此刻排在第一位。

坏掉的样子

在变化后的基线上恢复可能冲突；即便文本没有冲突，也可能需要业务适配。应依据最终代码意图解决，暂存具体路径并验证结果，不能反复向半恢复状态应用同一份变化。stash 应用没有一个通用中止命令，能够自动撤销任何已经产生的部分效果，因此“先试试，不行就一键回去”不是可靠的恢复设计。

如果适合回到原始基线继续，可以使用建立分支的恢复命令：它从记录的起点创建分支，再应用保存工作。通过 stash 日志指定条目且应用成功时，条目也会被移除。这是与记录基线有关的恢复流程，不要求必须有两份 stash，也不存在超过某个时间就必须采用的固定期限。应按当前基线与恢复意图判断，而不是按存放时长机械选择。

移除应发生在验证之后，不能代替验证。清空整个列表可能丢弃无关工作，已经删除的对象以后还可能被回收。需要持续评审的工作，应在适合的分支形成有意提交，并遵守项目的备份与共享规则。stash 也不承诺捕获编辑器未保存缓冲区、任意文件系统元数据或构建使用的全部外部资源，不能把它当作整套开发环境的恢复镜像。

快速验证

在 POSIX 系统上使用 Python 3 和 Git 2.28 或更新版本运行下面实验。全部修改与移除都发生在可丢弃仓库，使用示例身份，关闭钩子及签名，排除个人 Git 配置和路由变量，没有远端。样例故意让索引与工作文件包含不同值，再检查保存范围、索引恢复、冲突后的条目保留，以及验证后才删除的顺序。

import os
import subprocess
import tempfile
from pathlib import Path

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-stash-demo-") as directory:
 root = Path(directory)
 def git(*args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=Stash Example",
 "-c", "user.email=stash@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=root, env=env, text=True, capture_output=True, check=check,
 )
 git("init", "-q", "-b", "main")
 (root / ".gitignore").write_text("ignored.txt\n")
 (root / "note.txt").write_text("base\n")
 git("add", ".gitignore", "note.txt")
 git("commit", "-qm", "base")
 (root / "note.txt").write_text("staged\n")
 git("add", "note.txt")
 (root / "note.txt").write_text("working\n")
 (root / "new.txt").write_text("untracked\n")
 (root / "ignored.txt").write_text("ignored\n")
 git("stash", "push", "-qm", "tracked only")
 saved = git("rev-parse", "refs/stash").stdout.strip()
 print("default-leaves-untracked:", (root / "new.txt").exists()
 and (root / "ignored.txt").exists()
 and (root / "note.txt").read_text() == "base\n")
 git("stash", "apply", "--index", saved)
 restored = (git("show", ":note.txt").stdout == "staged\n"
 and (root / "note.txt").read_text() == "working\n")
 assert restored
 print("index-and-work-restored:", restored)
 print("apply-keeps-entry:", git("rev-parse", "stash@{0}").stdout.strip() == saved)
 assert git("rev-parse", "stash@{0}").stdout.strip() == saved
 git("stash", "drop", "-q", "stash@{0}")
 git("stash", "push", "-qu", "-m", "tracked and untracked")
 saved = git("rev-parse", "stash@{0}").stdout.strip()
 print("saved-untracked-content:",
 git("show", f"{saved}^3:new.txt").stdout == "untracked\n"
 and "ignored.txt" not in git("ls-tree", "-r", "--name-only", f"{saved}^3").stdout.splitlines())
 print("include-untracked-not-ignored:", not (root / "new.txt").exists()
 and (root / "ignored.txt").exists())
 (root / "note.txt").write_text("upstream\n")
 git("add", "note.txt")
 git("commit", "-qm", "new base")
 conflict = git("stash", "pop", "stash@{0}", check=False)
 print("conflicting-pop-keeps-entry:", conflict.returncode != 0
 and bool(git("ls-files", "-u").stdout)
 and git("rev-parse", "stash@{0}").stdout.strip() == saved)
 (root / "note.txt").write_text("upstream\nworking\n")
 git("add", "note.txt", "new.txt")
 assert not git("ls-files", "-u").stdout
 assert git("show", ":note.txt").stdout == "upstream\nworking\n"
 assert (root / "new.txt").read_text() == "untracked\n"
 git("commit", "-qm", "retain both fixture values")
 assert git("rev-parse", "stash@{0}").stdout.strip() == saved
 git("stash", "drop", "-q", "stash@{0}")
 print("resolved-and-verified:", not git("status", "--porcelain").stdout
 and not git("stash", "list").stdout)

七个判断都应为真。默认保存留下未跟踪和忽略文件；带索引应用恢复两个受跟踪状态，同时保留条目。包含未跟踪文件仍不会包含忽略文件。检查保存对象第三父级的目录树，还能确认未跟踪文本确实进入保存内容；文件从目录消失，本身不能证明它已经得到保留。这里使用对象结构只是为了独立验证样例，不要求日常使用者手动编辑内部对象。后续冲突弹出保留对应条目；样例明确决定保留两项预期值，提交并验证结果之后，才删除已经核对的那个保存项。最后由 Python 清理包括忽略文件在内的全部演示数据，不操作真实项目的保存列表。

来源

Git stash 参考，快照范围、条目存储、恢复及删除语义，已核验 2026-10-15。
Pro Git：储藏与清理，索引恢复及从原始基线继续工作，已核验 2026-10-15。

git cherry-pick 重新应用一次提交

Thu, 25 Nov 2027 00:00:00 +0000

cherry-pick 把选定提交引入的改动应用到当前开发线，适合旧发布分支只需要一个修复、不希望同时接收整条开发分支的场景。它不会搬走或删除源提交，也不会为目标建立与源分支的合并关系。移植后的结果必须在目标环境中重新审阅；源分支上已经通过的测试，只能说明原来的组合，不能直接证明换了依赖与历史之后仍然正确。

选择的是相对父提交的变化

对于普通的单父提交，相关变化是它相对父级的差异。Git 利用可用历史和合并机制，把这份变化应用到目标，而不是简单地用源提交的完整文件快照覆盖目标。目标原本已有的其他修改应继续保留，除非选定变化或人工解决明确要求改变它们。审阅时既要看搬来了什么，也要确认没有误把目标自己的工作一起替换掉。

通常，cherry-pick 会在目标末端后面记录新提交。父级不同，结果目录树也可能不同，因此对象身份会变化。原作者身份和作者日期通常保留，而提交者表示实际记录这次移植的人；消息不一定变化。不能把这项操作解释成必然换作者、必然改写消息，更不能根据对象标识不同就断言原作者署名已经丢失。

默认行为会创建提交，但不提交选项会把变化留在索引与工作树中，供审阅或组合；使用允许快进的选项时，满足条件的操作还可以直接前进到已有源提交。这些明确模式说明，“所有 cherry-pick 都一定生成新对象”也不是普遍成立的规则。解释一次具体结果时，应把实际参数与所处历史一起纳入判断。

移植之前检查依赖

修复可能依赖目标分支尚不存在的接口、数据结构、配置或前置重构。补丁在文本上干净落地，并不能证明行为正确。应阅读源变化及其前提，在真正的维护分支运行受影响行为测试，并只引入该修复实际必需的依赖。如果需要适配，说明为何不能原样采用，以及新分支上的实现如何满足同一修复目标。

在共享分支之间干净应用时，-x 会把源提交标识写进新消息，方便追踪，但它不是等价性或批准状态的密码学证明。手动解决冲突后也要检查最终消息，确认来源关系没有丢失。原提交的签名不会自动成为新对象的有效签名；目标要求签名时，应遵循目标发布流程，而不是把保留作者信息等同于继承了所有验证证据。

坏掉的样子

在默认创建提交的模式中，发生冲突时，HEAD 停在最后一个已成功创建的提交，Git 用 CHERRY_PICK_HEAD 记录当前难以应用的源提交。使用 --no-commit 时不会设置该引用，因此必须检查状态和未合并条目，不能仅凭这个标记是否存在来判断冲突。能够干净应用的路径可能已经更新，冲突路径则在索引中保留未合并条目。文本冲突标记便于查看，但二进制冲突及其他类型不能只靠搜索标记字符串识别，还应检查工作区状态和索引，确认当前到底有哪些未完成事项。

解决时应确定目标需要的行为，暂存具体已解决路径，运行相关测试，再继续序列。文件已经暂存只说明冲突被标记为解决，不证明代码逻辑正确。中止会返回序列开始之前的状态；退出序列管理则只是遗忘操作状态，并不执行相同的回退。开始前应保证工作树干净且状态明确，不能把中止功能当作保存无关未提交工作的替代品。

目标已经包含某项变化时，应用结果可能为空。跳过之前，要确认目标确实具有预期行为，而不是只看到类似代码就作判断。选取合并提交还会多一个语义选择：主线参数指定以编号中的哪个父级作为差异基准。这不是通用冲突绕过开关，必须依据想移植的实际变化选择，而且结果不会重现原合并提交的多父级拓扑。

快速验证

在 POSIX 系统上使用 Python 3 与 Git 2.28 或更新版本运行下面实验。它建立私有临时仓库，排除个人 Git 配置和继承的 Git 路由变量，使用示例身份，关闭钩子与签名，没有远端。一条目标线能够接收修复；另一条故意把同一行改成不同内容，用来观察冲突停止及中止恢复。全部修改都限于这份临时数据，不触碰当前项目的提交或文件。

import os
import subprocess
import tempfile
from pathlib import Path

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-pick-demo-") as directory:
 def git(*args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=Backport Example",
 "-c", "user.email=backport@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=directory, env=env, text=True, capture_output=True, check=check,
 )
 def commit(text, message):
 (Path(directory) / "value.txt").write_text(text)
 git("add", "value.txt")
 git("commit", "-qm", message)
 git("init", "-q", "-b", "main")
 commit("old\n", "base")
 base = git("rev-parse", "HEAD").stdout.strip()
 git("switch", "-qc", "source")
 (Path(directory) / "value.txt").write_text("fixed\n")
 git("add", "value.txt")
 git("-c", "user.name=Original Example", "-c", "user.email=original@example.invalid",
 "commit", "-qm", "fix value")
 source = git("rev-parse", "HEAD").stdout.strip()
 git("switch", "-q", "main")
 git("commit", "--allow-empty", "-qm", "target progress")
 target = git("rev-parse", "HEAD").stdout.strip()
 git("cherry-pick", "-x", source)
 print("change-applied:", (Path(directory) / "value.txt").read_text() == "fixed\n")
 print("new-object-on-target:", git("rev-parse", "HEAD").stdout.strip() != source
 and git("rev-parse", "HEAD^").stdout.strip() == target)
 print("author-preserved:", git("show", "-s", "--format=%ae", "HEAD").stdout.strip()
 == "original@example.invalid")
 print("committer-is-backporter:", git("show", "-s", "--format=%ce", "HEAD").stdout.strip()
 == "backport@example.invalid")
 print("provenance-recorded:", source in git("show", "-s", "--format=%B", "HEAD").stdout)
 git("switch", "-qc", "conflict", base)
 commit("other\n", "target alternative")
 before = git("rev-parse", "HEAD").stdout.strip()
 conflict = git("cherry-pick", source, check=False)
 print("conflict-stopped:", conflict.returncode != 0
 and bool(git("ls-files", "-u").stdout)
 and git("rev-parse", "CHERRY_PICK_HEAD").stdout.strip() == source
 and git("rev-parse", "HEAD").stdout.strip() == before)
 git("cherry-pick", "--abort")
 print("abort-restored:", git("rev-parse", "HEAD").stdout.strip() == before
 and (Path(directory) / "value.txt").read_text() == "other\n"
 and not git("status", "--porcelain").stdout)

七个判断都应为真。干净目标包含修复后的值，新提交的父级是目标原来的末端；作者仍为源作者，提交者是移植者，消息记录来源标识。另一条目标线停在冲突状态，索引存在未合并条目；中止后，它恢复原文本、原末端和干净状态。这些结果验证改动转移、身份信息与恢复机制，不冒充真实业务修复已经在维护分支完成验收。

来源

Git cherry-pick 参考，应用模式、冲突状态和序列控制，已核验 2026-10-15。
Pro Git：维护项目，为另一条开发线选择个别变化，已核验 2026-10-15。

.gitignore 控制未跟踪路径的处理

Mon, 15 Nov 2027 00:00:00 +0000

Git 忽略规则影响普通路径发现和添加操作如何处理尚未跟踪的文件，适合管理生成产物、编辑器状态和本地配置。但它不会形成访问控制边界，不会把已进入索引的文件移出去，也不会抹掉更早的提交。因此，应该把忽略文件看成具有可验证匹配规则的项目约定，不能把它当作敏感文件绝对进不了历史的保证。

坏掉的样子

某个文件被跟踪之后，再为它添加忽略规则，并不会停止跟踪。继续修改它并执行普通添加操作，新内容依然可能进入暂存区。这就是为什么泄漏配置后才把文件名补进 .gitignore，不能完成修复。索引里有没有这个路径、工作区文件现在是什么内容、历史提交保留了哪些对象，是三个不同状态，需要分别观察，而不是只看文件是否还显示在默认状态列表中。

否定规则也容易令人误判。排除整个目录，会阻止 Git 继续遍历该目录，后面针对某个子文件的例外便无法挽救它。可以只忽略目录里的内容，让父目录仍能被访问；也可以先逐层恢复被排除的父目录，再恢复后代。若 Git 根本不会进入某个目录，藏在里面的嵌套忽略文件也无从发挥作用，规则写得再靠近文件也没有帮助。

优先级并不是“看上去更精确的模式一定获胜”。Git 对命令行模式、目录忽略文件、仓库本地排除项和全局排除项定义了顺序；同一优先级内部，以最后匹配的模式为准。更深目录的忽略文件，可以针对它所管理的路径覆盖上层规则。因此，模式的写法与来源位置都重要，不能仅比较哪个字符串更长，就推导最终结果。

快速验证

在安装了 Git 的环境中运行下列 Python 脚本。它创建临时仓库，执行后自动删除；对子进程清除继承的 Git 路径与配置环境变量，关闭系统、全局配置及钩子，并使用空模板和虚构样本文件。原记录的版本为 Git 2.50.1；修订后的隔离检查也已在 Git 2.52.0、Python 3.12.14 下通过。即使从已有项目目录启动，实际 Git 操作也都以临时目录为工作目录，不会修改启动位置的仓库：

from pathlib import Path
from tempfile import TemporaryDirectory
import os,subprocess

env={key:value for key,value in os.environ.items() if not key.startswith('GIT_')}
env.update(GIT_CONFIG_NOSYSTEM='1',GIT_CONFIG_GLOBAL=os.devnull)
with TemporaryDirectory(prefix='git-ignore-lab-') as directory:
 root=Path(directory)
 hooks=root/'.no-hooks';hooks.mkdir()
 template=root/'.no-template';template.mkdir()
 def git(*args, expected=0):
 result=subprocess.run(['git','-c','core.hooksPath='+str(hooks),'-c','core.excludesFile='+os.devnull,*args],cwd=root,env=env,text=True,capture_output=True)
 assert result.returncode==expected,(args,result.returncode,result.stderr)
 return result.stdout
 def write(path,content='fixture\n'):
 target=root/path;target.parent.mkdir(parents=True,exist_ok=True);target.write_text(content)
 git('init','-q','--template='+str(template))
 git('config','user.name','Ignore Lab')
 git('config','user.email','ignore@example.invalid')
 git('config','commit.gpgsign','false')
 write('tracked.txt','first version\n')
 git('add','--','tracked.txt');git('commit','-qm','Track fixture')
 write('build/keep.txt');write('build/output.bin')
 write('.gitignore','/build/\n!/build/keep.txt\n')
 git('check-ignore','-q','build/keep.txt')
 print('excluded parent prevents child exception')
 write('.gitignore','/build/*\n!/build/keep.txt\n*.log\n/root-only.txt\ntracked.txt\n')
 git('check-ignore','-q','build/keep.txt',expected=1)
 rule=git('check-ignore','-v','build/keep.txt')
 assert ':2:!/build/keep.txt\t' in rule
 git('check-ignore','-q','build/output.bin')
 print('ignoring contents permits keep.txt; verbose output includes its negation')
 write('debug.log');write('nested/debug.log');write('nested/.gitignore','!debug.log\n')
 write('root-only.txt');write('nested/root-only.txt')
 git('check-ignore','-q','debug.log')
 git('check-ignore','-q','nested/debug.log',expected=1)
 git('check-ignore','-q','root-only.txt')
 git('check-ignore','-q','nested/root-only.txt',expected=1)
 print('nested exception and root anchor checked')
 write('tracked.txt','second version\n')
 git('add','-A')
 assert 'tracked.txt' in git('diff','--cached','--name-only').splitlines()
 git('check-ignore','-q','tracked.txt',expected=1)
 assert 'tracked.txt' in git('check-ignore','--no-index','-v','tracked.txt')
 git('rm','--cached','--','tracked.txt')
 assert (root/'tracked.txt').is_file()
 assert 'tracked.txt' not in git('ls-files').splitlines()
 git('cat-file','-e','HEAD:tracked.txt')
 print('tracked file still staged; cached removal keeps disk copy and old commit')
 git('add','-f','--','build/output.bin')
 assert 'build/output.bin' in git('ls-files').splitlines()
 print('force-add bypasses ignore rules')

第一项确认，排除 build/ 会使子文件例外失效。修改后的规则只排除目录里面的条目，因此允许 keep.txt，同时继续排除 output.bin。安静模式检查的是实际忽略结果，退出码一表示被检查的路径没有被忽略。这里不是根据文件名或规则长相猜测，而是把预期写成了真实 Git 命令的返回值断言。

对于已经允许的文件，详细输出仍然会显示那条带感叹号的匹配规则。所以，看到 git check-ignore -v 输出一行内容，并不能直接证明路径被排除；必须检查报告的模式，特别是有没有否定前缀。如果脚本需要布尔判定，应使用对应的安静模式结果，避免把诊断说明误当作阻止提交的判断条件。

嵌套目录的日志例外覆盖了根目录的日志规则，而 /root-only.txt 的前导斜杠把范围锚定在根忽略文件所在目录，因此同名的嵌套文件仍有资格被添加。这几项断言针对实际创建的路径执行，也说明“裸文件名”和“从本层目录开始的路径”不能随意互换。

已跟踪文件在修改后仍然进入暂存区，即使新规则匹配了它的名字。诊断命令的 --no-index 让我们暂时忽略普通的已跟踪判断，查看该模式本身。随后使用 git rm --cached，工作区副本仍在磁盘上，索引条目被移除，但旧提交中的对象依然存在。最后，强制添加把原本被忽略的构建产物重新放入索引，直接证明忽略规则并不是不可绕过的提交权限。

审阅下一次提交的真实内容

项目共同约定放进共享的 .gitignore；只影响某个仓库检出的本地排除项，可放在 .git/info/exclude；个人编辑器残留可以交给配置好的全局排除文件。不要让团队能否正确构建，依赖某台电脑上没人知道的全局规则。即使生成产物与源码放在相邻位置，也要保证真正的构建输入仍能被纳入版本管理。

提交前应检查暂存区差异和已跟踪路径，而不是只看默认状态是否显得干净。过宽的模式可能隐藏刚新增的源码，强制添加也可能突破原本的排除意图。如果要提交一个停止跟踪本地配置的变更，应同时具备替代的配置供应方式，因为其他检出应用这次删除时，可能真的移除原本被跟踪的副本，不能假定每个人都像当前工作区一样保留它。

若发生真实凭据暴露，应撤销或替换凭据，并调查已经传播到哪里。移除索引项不能让已经授予的访问失效，重写一个仓库也无法控制其他地方持有的副本。忽略规则能够减少常见操作失误，暂存内容审阅与合适的秘密检测可以补充检查，但它们各自都有边界，不能合起来就宣称泄漏不可能发生。

来源

Git 忽略规则，作用范围、优先级与被排除父目录的行为，已核验 2026-09-12。
git check-ignore，详细输出中的否定模式与索引诊断，已核验 2026-09-12。
git rm，移除索引项同时保留工作区文件，已核验 2026-09-12。
Git 环境与配置，仓库路径和隔离配置所用的环境变量，已核验 2026-10-15。
Git 配置，钩子与排除规则的路径，已核验 2026-10-15。

用 git worktree 做热修复，不打断功能开发

Sat, 06 Nov 2027 00:00:00 +0000

加急修复不必把尚未完成的功能开发从当前目录赶走。关联工作树可以从选定的发布提交开始，而原目录保留已暂存修改、未暂存编辑和未跟踪文件。这个流程真正成功，需要同时证明修复在正确基线上通过验证，以及原工作完整保留。仅仅多创建一个目录，既不能证明基线正确，也不能证明所有未完成状态没有受到影响。

先选基线，再开另一个目录

检查当前工作树，并确定需要修复的准确发布版本。一个方便使用的分支名称，不一定就是线上部署的提交。如果必须刷新远端跟踪引用，应获取指定远端之后，再记录实际解析到的对象。获取更新的是公共仓库引用，并不是只影响输入命令的那个目录；多个工作树之间仍然共享这部分状态。

创建时明确指定目录、新分支名称和起点。新的热修复分支可以避免与其他目录已检出的分支竞争。如果只是检查、不准备提交，分离工作树也可能足够。不要因为计划使用的名称已经存在，就直接采用重置分支或强制选项；先检查已有工作树和引用，弄清它们是否保存了其他工作，不能让方便命名变成覆盖状态的理由。

新工作树检出的是所选起点中的已提交内容，不会复制原目录的功能改动或未跟踪笔记。这有利于在没有功能开发偶然修复或新增依赖的情况下复现发布问题，但也意味着编辑器缓冲区、本地配置文件等不会自动出现在新目录。需要哪些文件，应依据真正的测试环境准备，而不能假定整个开发上下文被一起复制过去。

在真实热修复目录复现与验证

先确认新 HEAD，再运行针对性复现，随后修改代码，并在同一热修复目录运行相同检查和相关的更广范围测试。在原功能目录跑出的成功，只能证明另一份检出的情况。测试输出应关联准确的提交、目录和配置，让后来审阅的人能够知道观察结果对应哪一套输入，而不是只看到一个没有上下文的成功提示。

放在各目录内部的构建产物是不同文件，但外部状态仍可能竞争。两个服务可能绑定相同端口，两套测试可能写同一个数据库，共享缓存也需要正确的区分键。工作树不是容器、虚拟机或安全边界；运行不熟悉分支的构建命令前，应检查它会执行什么以及访问哪些资源，不能把目录不同解释成任何副作用都彼此隔离。

只暂存预期修复，并在提交前检查差异。新提交通过公共对象库对其他目录可见，但原功能分支和索引不需要因此移动。保留原状态是要求时，应明确复核这些事实，而不是靠“工作树本来就独立”推断没有问题。提交在本地可见，也不意味着分支已经分发或修复已经部署；发布仍然是单独受授权约束的步骤。

坏掉的样子

目录名称可能像某个发布版本，实际 HEAD 却指向另一个位置。应核对解析后的版本，而不是信任文件夹标签。另一个常见错误，是把公共仓库配置当成当前工作树私有配置：为热修复调整的设置，可能影响其他工作树，即便那些目录里的文件完全没有变化。遇到差异时，应同时检查文件和共享配置，而不只比较源码。

结束前检查关联工作树的状态、未跟踪文件以及有价值的忽略产物。普通状态不会显示被忽略的文件，受跟踪差异为空，也不证明目录里没有值得保存的数据。需要保留的日志或制品，应在移除之前移到目录之外。还要停止继续使用该目录的进程，因为 Git 状态干净并不说明服务已经退出，也不说明没有文件仍然被打开。

对确认过的路径使用普通移除命令。遇到未提交或普通未跟踪工作时，它会拒绝，而不会默认这些内容可丢弃；应调查拒绝原因，不要习惯性补上强制参数。移除删除的是关联检出和注册信息，不是分支本身。清理失效管理信息则针对目录已经消失的记录，不是删除活动工作区的替代命令，两种操作不能混用。

快速验证

在 POSIX 系统上使用 Python 3 与 Git 2.28 或更新版本运行下面实验。临时仓库排除个人 Git 配置和继承的 Git 路由，关闭钩子及签名，没有远端。功能目录故意同时保留三种未完成工作；热修复测试先失败，再经过一行修复后成功。全部内容都是合成测试数据，不会改变当前项目的编辑、分支或发布状态。

import os
import subprocess
import sys
import tempfile
from pathlib import Path

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-hotfix-demo-") as directory:
 root = Path(directory)
 feature, hotfix = root / "feature", root / "hotfix"
 feature.mkdir()
 def git(tree, *args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=Hotfix Example",
 "-c", "user.email=hotfix@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=tree, env=env, text=True, capture_output=True, check=check,
 )
 def test():
 return subprocess.run([sys.executable, "-B", "-c",
 "from calc import double; assert double(4) == 8"],
 cwd=hotfix, text=True, capture_output=True)
 git(feature, "init", "-q", "-b", "feature")
 (feature / "calc.py").write_text("def double(n):\n return n * 2 + 1\n")
 (feature / "draft.txt").write_text("base\n")
 (feature / ".gitignore").write_text("ignored.log\n")
 git(feature, "add", "calc.py", "draft.txt", ".gitignore")
 git(feature, "commit", "-qm", "release baseline")
 baseline = git(feature, "rev-parse", "HEAD").stdout.strip()
 (feature / "draft.txt").write_text("staged\n")
 git(feature, "add", "draft.txt")
 (feature / "draft.txt").write_text("unstaged\n")
 (feature / "idea.txt").write_text("untracked idea\n")
 git(feature, "worktree", "add", "-qb", "hotfix", str(hotfix), baseline)
 print("clean-baseline:", git(hotfix, "rev-parse", "HEAD").stdout.strip() == baseline
 and (hotfix / "draft.txt").read_text() == "base\n"
 and not (hotfix / "idea.txt").exists())
 broken = test()
 print("regression-reproduced:", broken.returncode != 0 and "AssertionError" in broken.stderr)
 (hotfix / "calc.py").write_text("def double(n):\n return n * 2\n")
 fixed = test()
 assert fixed.returncode == 0 and not fixed.stderr, fixed
 git(hotfix, "add", "calc.py")
 git(hotfix, "commit", "-qm", "fix double")
 fixed_commit = git(hotfix, "rev-parse", "HEAD").stdout.strip()
 print("feature-preserved:", git(feature, "rev-parse", "HEAD").stdout.strip() == baseline
 and git(feature, "symbolic-ref", "--short", "HEAD").stdout.strip() == "feature"
 and git(feature, "show", ":draft.txt").stdout == "staged\n"
 and (feature / "draft.txt").read_text() == "unstaged\n"
 and (feature / "idea.txt").read_text() == "untracked idea\n")
 artifact = hotfix / "review-notes.txt"
 artifact.write_text("reviewed\n")
 refused = git(feature, "worktree", "remove", str(hotfix), check=False)
 print("dirty-removal-refused:", refused.returncode != 0 and artifact.exists())
 saved = root / "saved-review.txt"
 artifact.rename(saved)
 ignored = hotfix / "ignored.log"
 ignored.write_text("useful build log\n")
 print("ordinary-status-hides-ignored:", not git(hotfix, "status", "--porcelain").stdout
 and "ignored.log" in git(hotfix, "status", "--short", "--ignored").stdout)
 saved_log = root / "saved-build.log"
 ignored.rename(saved_log)
 git(feature, "worktree", "remove", str(hotfix))
 print("checkout-removed-branch-kept:", not hotfix.exists()
 and git(feature, "rev-parse", "hotfix").stdout.strip() == fixed_commit)
 print("review-notes-preserved:", saved.read_text() == "reviewed\n"
 and saved_log.read_text() == "useful build log\n")

七个观察都应为真。热修复从已提交的基线内容开始，能够复现故障，并保留原功能分支、索引文本、磁盘文本和未跟踪笔记。新的未跟踪评审记录会阻止移除，移到关联目录之外后，还检查一份被忽略的日志：普通状态不显示它，加入忽略项检查才可见。保存日志后，普通移除才成功，热修复分支、评审记录和日志仍在。只有这些检查完成之后，外层临时目录管理器才有意清理整套演示数据。

来源

Git worktree 参考，显式创建、检出保护、移除和失效记录清理，已核验 2026-10-15。
Git status 参考，暂存与工作树差异，以及未跟踪和忽略文件，已核验 2026-10-15。

git bisect 收敛第一个坏提交

Sun, 24 Oct 2027 00:00:00 +0000

二分排查回答一个明确的历史问题：在选定历史中，某个可复现观察从哪里开始由正常变成异常？它不会仅凭给出一个提交，就自动确定根因。搜索依赖正确的端点标签和一致的中间判断。应把报告出的边界当作需要检查的证据，再确认边界两侧行为，并解释哪项变化造成了结果差异，不能把一行定位输出当作完整故障分析。

依据观察选择端点，而不是日期

至少一个已知正常提交和一个已知异常提交可以建立搜索；更多正常版本还可以进一步约束提交图。最近经过验证的正常版本，通常比不必要地选择很古老的基线更能缩小范围。日期不是搜索顺序：Git 使用祖先关系，作者时间戳不一定反映提交在图上的位置。因此，“最早”应放在这次历史边界内解释，而不是直接按墙上时间排序。

赋予标签之前，应在两个端点运行同一份复现。明确什么算目标症状，包括边界输入与相关配置。只检查任意命令有没有失败，可能把产品回归与解释器缺失、服务不可用或构建环境不兼容混在一起。一个无法测试的版本，其结论是未知，而不是自动判坏；如果输入条件没有保持一致，后续再精细的搜索也无法补回缺失的可比性。

使用干净、可丢弃的检出，或专门的关联工作树。二分通常会把 HEAD 切到选定版本并更新文件，因此应提前保存未完成工作，不能认为搜索会自动创建备份。探针和必需证据也应放在不会随历史检出而消失或改变的地方，让测试程序自身的变化与被测源码版本分开，避免把旧脚本缺失当成源码故障。

每次都判断同一个性质

观察当前版本之后，按复现结果标记正常或异常。某个版本由于与目标症状无关的原因无法分类时，可以跳过。靠近转换点的跳过可能使答案不唯一，此时应报告剩余候选集合，而不是把最先显示的对象包装成已经确定的责任提交。未知本身也是有效调查结果，不能为了快速收束而强行填上好坏标签。

简单二分直觉要求所选历史中的转换足够稳定。问题先引入、后修复、再重新引入时，对这个判断条件来说已经不是单一的单调时间线；随机失败的测试也会制造类似的误导。观察与假设矛盾时，应细化问题或区间，而不是把不一致结果塞进方便解释的故事。搜索算法不会替你决定这些不一致到底意味着什么。

合并较多时，搜索全部祖先还是只沿第一父级集成线，会改变问题本身。第一父级搜索可能找到集成分支因某次合并而出现故障的点，而不是主题分支最初引入代码的提交。同样，限制文件路径可能排除真正相关的配置或调用方变化。只有这些限制符合调查目标时才应用，不能只为了让候选数量看起来更少而缩小问题。

自动运行 git bisect run 时，退出码零表示正常，125 表示跳过，1 至 127 中其余值表示异常，其他状态会中止搜索。命令不存在可能返回 127，因此包装脚本必须区分工具不可用与目标回归，不能把每个失败都直接转交为坏版本。手动探针中的异常同样应先调查，而不是自动贴标签。

坏掉的样子

一个错误标签就可能排除真正边界。结束当前排查之前保存搜索日志；发现判断有误时，保留原证据，修正决定记录，重置会话后重放修正日志。重放恢复的是判断过程，不会重新执行测试，也不能证明当时的环境现在仍然有效。若探针或依赖发生变化，需要重新验证对应结论，不能把可重放等同于已复测。

找到候选后，在候选及相关父级运行准确的复现。普通线性边界应表现为候选异常、父级正常；合并提交则可能需要检查多个父级和组合行为。还应阅读补丁及受影响调用链。即便候选只是暴露了更早就存在的问题，也仍需解释因果关系，不能只凭它改变了症状，就把全部根因归给那次提交。

不要为了验证猜测，就立刻在共享或有未提交修改的分支撤销候选。修正实验应放在受控检出中，并单独审阅和测试。记录发现之后，二分重置会结束会话，通常回到开始时的检出；还要核对当前分支和版本，而不能把最后用于诊断的历史位置误认成日常开发分支，随后把新工作提交到错误位置。

快速验证

在 POSIX 系统上使用 Python 3 与 Git 2.28 或更新版本运行下面实验。临时仓库使用示例身份，关闭钩子及签名，排除个人 Git 配置和路由变量，没有远端。七个版本中，第三号版本把数值上限从包含等号改成不包含等号；探针专门检查边界输入十。这样测试的是一个明确行为，而不是根据提交消息或预设对象标识给版本贴标签。

import os
import subprocess
import sys
import tempfile
from pathlib import Path

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-bisect-boundary-") as directory:
 root = Path(directory)
 repo, log = root / "repo", root / "bisect.log"
 repo.mkdir()
 def git(*args):
 return subprocess.run(
 ["git", "-c", "user.name=Boundary Example",
 "-c", "user.email=boundary@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=repo, env=env, text=True, capture_output=True, check=True,
 )
 def verdict():
 result = subprocess.run([sys.executable, "-B", "-c",
 "from limit import accepts; print(int(accepts(10)))"],
 cwd=repo, text=True, capture_output=True, check=True)
 assert result.stdout in ("0\n", "1\n"), result
 return "good" if result.stdout == "1\n" else "bad"
 git("init", "-q", "-b", "main")
 commits = []
 for number in range(7):
 operator = "<" if number >= 3 else "<="
 (repo / "limit.py").write_text(f"def accepts(n):\n return n {operator} 10\n")
 (repo / "revision.txt").write_text(f"{number}\n")
 git("add", "limit.py", "revision.txt")
 git("commit", "-qm", f"revision {number}")
 commits.append(git("rev-parse", "HEAD").stdout.strip())
 endpoints = []
 for revision in (commits[0], "main"):
 git("switch", "-q", "--detach", revision)
 endpoints.append(verdict())
 git("switch", "-q", "main")
 print("endpoints-confirmed:", endpoints == ["good", "bad"])
 git("bisect", "start", commits[-1], commits[0])
 try:
 while len(git("rev-list", "refs/bisect/bad", "--not",
 "--glob=refs/bisect/good-*").stdout.splitlines()) > 1:
 git("bisect", verdict())
 found = git("rev-parse", "refs/bisect/bad").stdout.strip()
 log.write_text(git("bisect", "log").stdout)
 print("boundary-identified:", found == commits[3])
 finally:
 git("bisect", "reset")
 checks = []
 for revision in (found, f"{found}^"):
 git("switch", "-q", "--detach", revision)
 checks.append(verdict())
 git("switch", "-q", "main")
 print("candidate-and-parent-retested:", checks == ["bad", "good"])
 try:
 git("bisect", "replay", str(log))
 print("log-replays-boundary:", git("rev-parse", "refs/bisect/bad").stdout.strip() == found)
 finally:
 git("bisect", "reset")
 print("original-branch-restored:", git("symbolic-ref", "--short", "HEAD").stdout.strip() == "main"
 and git("rev-parse", "HEAD").stdout.strip() == commits[-1]
 and not git("status", "--porcelain").stdout)

五个判断都应为真。在这份线性且没有跳过的样例中，循环逐次记录正常或异常，直到只剩一个候选。最终定位第三号版本，独立复测确认候选在边界输入上失败、父级成功。重放保存的日志可以到达同一结果，但不会再次执行探针；最后恢复 main。补丁也解释了观察：上限处的相等情况被排除，正是这次回归的具体来源。

来源

Git bisect 参考，标签、跳过、祖先限制、日志和重放，已核验 2026-10-15。
Pro Git：使用 Git 调试，测试历史端点及检查定位边界，已核验 2026-10-15。

Git 工作树共享仓库，各自保留检出状态

Mon, 26 Jul 2027 00:00:00 +0000

关联工作树让同一个 Git 仓库拥有另一个工作目录，并保存各自的检出状态。功能开发、发布维护和评审可以并排展开，不必反复替换同一目录中的文件。真正有用的边界是工作文件与暂存状态分离，而不是完全隔离。对象、许多引用以及普通仓库配置仍然共享，所以操作时既要考虑当前目录，也要考虑它背后的公共仓库，不能把关联工作树等同于互不影响的独立克隆。

区分每份检出自己的状态

每个工作树都有自己的 HEAD 和索引。在一个目录暂存修改，不会让另一目录的索引出现同样变化；编辑一个受跟踪文件，也不会同步编辑旁边那份文件。关联工作树中的普通提交推动它当前选中的分支。新对象和共享分支引用则立即能被其他工作树里的 Git 命令看到，不需要在这些目录之间再执行获取操作。

关联目录中的 Git 入口通常是一个文件，指向它的管理目录。真正检出的源文件住在创建工作树时指定的路径，而不是内部的工作树管理条目里。假定 Git 入口必然是目录的工具，可能因此失效。需要定位公共目录、当前管理目录或索引时，应向 Git 查询对应路径，不能自行拼接内部文件名，把偶然的存储结构当作可靠接口。

对象可以共享，但工作文件和构建产物仍然各自占用磁盘。第二份检出不是第二套完整对象库，却也不是所有源码和生成文件都零复制。保留多个发布版本时，应按实际检出及构建需求估算空间，而不是只看创建一个引用很便宜，就认为新增整套开发环境没有存储成本。

共享不代表所有东西都共享

本地分支和标签通常属于公共仓库，HEAD 和操作状态则属于具体工作树；部分引用也按工作树分离，例如二分排查使用的引用。把所有引用一概当成全局共享，或全部当成当前目录私有，都会导致工具错误。应从目标工作树调用 Git 解析需要的引用，确保命令看到的是准备操作的那份状态。

普通仓库配置默认共享。因此，站在评审目录执行本地配置修改，也可能影响功能开发目录。Git 支持明确启用的工作树专用配置，但启用扩展本身就是仓库配置变更，需要遵守文档中的迁移规则。不能因为命令名称里有“本地”，就假定它的作用域已经缩小到当前这份检出；配置究竟共享到哪里，应依据实际机制确认。

同样，共享的暂存工作列表不是某个目录独享的草稿箱。应用或删除保存项之前，应明确命名并检查内容。源目录分离也不会自动隔离端口、数据库、外部缓存和命令使用的凭据。构建或运行服务时，仍需检查这些资源是否按任务分配，否则两个工作树可能通过仓库之外的资源互相干扰。

坏掉的样子

默认情况下，Git 拒绝在两个工作树同时检出同一本地分支，避免两个独立索引和工作目录竞争更新一个移动引用。这是可被强制参数绕过的保护，不是存储上绝对不可能的情况。独立改动应使用不同分支，检查同一提交可以采用分离检出；不要把绕过保护当作常规创建方式，否则表面上的目录隔离与实际引用关系会不一致。

分离检出没有一条本地分支随新提交前进。如果实验结果需要在移除工作树后保留，应先给目标提交创建分支名称。移除工作树不会自动删除它的分支；清理失效管理信息也不等于删除仍存在的检出。选择命令时必须先判断真实状态，不能把几种都叫“清理”的操作当成可互换步骤。

搬迁时，在受支持场景优先使用工作树移动命令；它不能移动主工作树，也不能移动包含子模块的关联工作树。已经手动移动的检出，可以通过修复命令重新连接。可移动卷暂时不在线，并不代表目录已废弃，锁定对应工作树可以避免离线期间被清理注册信息。不要把直接修改内部管理文件当成通用恢复方案，否则可能进一步损坏双向路径关系。

快速验证

在 POSIX 系统上使用 Python 3 和 Git 2.28 或更新版本运行下方实验。临时仓库排除继承的 Git 路由和个人配置，使用示例身份，并关闭钩子与签名。唯一写入的配置是合成演示键。两个目录分别暂存不同文本，然后在关联工作树提交，观察新对象如何从主目录可见，同时主目录原来的暂存状态仍然保留。

import os
import subprocess
import tempfile
from pathlib import Path

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-worktree-state-") as directory:
 root = Path(directory)
 main, review, detached = root / "main", root / "review", root / "detached"
 main.mkdir()
 def git(tree, *args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=Worktree Example",
 "-c", "user.email=worktree@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=tree, env=env, text=True, capture_output=True, check=check,
 )
 git(main, "init", "-q", "-b", "main")
 (main / "note.txt").write_text("base\n")
 git(main, "add", "note.txt")
 git(main, "commit", "-qm", "base")
 git(main, "worktree", "add", "-qb", "review", str(review), "HEAD")
 common = [(tree / git(tree, "rev-parse", "--git-common-dir").stdout.strip()).resolve()
 for tree in (main, review)]
 indexes = [(tree / git(tree, "rev-parse", "--git-path", "index").stdout.strip()).resolve()
 for tree in (main, review)]
 print("shared-common-dir:", common[0] == common[1])
 print("separate-indexes:", indexes[0] != indexes[1])
 (main / "note.txt").write_text("main staged\n")
 git(main, "add", "note.txt")
 (review / "note.txt").write_text("review staged\n")
 git(review, "add", "note.txt")
 print("independent-staging:", git(main, "show", ":note.txt").stdout == "main staged\n"
 and git(review, "show", ":note.txt").stdout == "review staged\n")
 git(main, "config", "--local", "demo.shared", "visible")
 print("shared-local-config:", git(review, "config", "--get", "demo.shared").stdout.strip() == "visible")
 git(review, "commit", "-qm", "review change")
 print("commit-visible-from-main:", git(main, "show", "review:note.txt").stdout == "review staged\n")
 print("main-staging-unchanged:", git(main, "show", ":note.txt").stdout == "main staged\n"
 and (main / "note.txt").read_text() == "main staged\n")
 duplicate = git(main, "worktree", "add", str(root / "duplicate"), "main", check=False)
 print("duplicate-branch-refused:", duplicate.returncode != 0)
 git(main, "worktree", "add", "-q", "--detach", str(detached), "main")
 print("detached-copy-allowed:", git(detached, "symbolic-ref", "-q", "HEAD", check=False).returncode == 1)
 git(main, "worktree", "remove", str(review))
 git(main, "worktree", "remove", str(detached))

八个判断都应为真。路径查询证明公共仓库相同、索引不同；两个索引各自保留对应文本，合成配置与已提交的评审分支则共享。同一分支的重复附着检出被拒绝，同一提交的分离检出可以创建。实验只移除自己的干净关联目录，最后由 Python 清理可丢弃的主目录，没有把真实项目里的未提交工作纳入清理范围。

来源

Git worktree 参考，共享状态、工作树专用状态、保护和生命周期命令，已核验 2026-10-15。
Git 仓库布局，关联管理目录、公共存储及索引位置，已核验 2026-10-15。

小提交应当讲清一个完整变化

Sun, 25 Jul 2027 00:00:00 +0000

有用的提交应当回答仓库行为发生了什么变化。它包含实现、能够说明该行为的验证，以及使用变化所需的文档。这里的“小”指修改理由有明确边界，而不是行数越少越好。例如，修正免运费门槛，需要同时修改计算函数和对应的回归断言；旁边正在编写的无关笔记应当继续留在工作区。把这些边界说明白，之后的读者才知道哪些变化必须一起存在。

暂存区决定这次留下的检查点

Git 区分工作区、暂存区和已经提交的文件树。编辑文件只会改变工作区；执行添加操作，才会把当时的内容放进暂存区。此后继续编辑，不会自动更新已经暂存的版本。因此，在当前目录运行测试成功，并不能证明即将提交的快照也能通过：测试可能依赖尚未暂存的修复、导入或配置。审阅时应看暂存差异，包括新增和删除；部分暂存造成实质差异时，应验证选中的那个快照。

同一个目录里有两件独立工作时，暂存区可以帮助保留边界。只选择当前目的需要的文件或代码块，同时检查它依赖的测试数据、导入、配置和说明是否齐全。只有几行实现，却遗漏必需的数据库结构变更，并不是可用的独立检查点。反过来，一次机械重命名即使涉及很多文件，只要变化理由一致，仍然可以是一个完整事项。文件数量不能替代对依赖关系的判断。

下面的小实验只有一组自包含文件，因此只复制改动文件就足够；真实仓库的暂存快照还必须包含未改动的已跟踪依赖、可执行模式以及必需的子模块。若不完整导出又意外从工作区导入依赖，就破坏了检查原本想建立的隔离，测试通过仍不能证明实际提交可用。

坏掉的样子

混合提交把本来无关的决策绑在一起。回退界面变化时，可能顺带移除藏在同一提交里的可靠性修复。随意按文件拆开也未必更好：如果第一个提交已经调用新接口，第二个提交才定义接口，中间状态就不能运行。应该保留有意义的中间版本；如果一组修改必须按顺序共同审阅，就明确写出依赖，而不是用很多碎片制造可独立交付的假象。

小提交能够减少审阅者需要同时理解的信息，却不保证反向操作没有冲突，更不保证生产回退安全。后续代码可能已经依赖之前的行为，数据库迁移也可能改变 Git 无法恢复的数据。revert 会记录一个新的反向变化，与中间发生的修改仍可能冲突。即使文本合并成功，也要重新检查最终行为及部署条件，不能把命令成功当作业务状态已经恢复。

二分定位同样需要历史版本上可靠的好坏判定。某个中间提交无法编译，不等于目标缺陷就是在这里引入的。跳过无法测试的版本，有时只能得到多个可能候选。保持检查点可运行有助于定位，但提交够小、标题够清楚，都不能修好一个会随机失败的测试，也不能补齐历史环境缺失的依赖。

快速验证

把下面代码保存为 small-commits.py，安装 Git 后执行 python3 small-commits.py。脚本创建临时仓库，隔离全局 Git 配置并使用空 hooks 目录，只在该仓库创建两个本地提交。实验约定：小计低于五十时收取五个单位运费，达到五十就免运费。初始函数错误地把恰好五十也算进了收费区间。

from pathlib import Path
from tempfile import TemporaryDirectory
import json
import os
import subprocess
import sys

with TemporaryDirectory() as directory:
 repo = Path(directory) / 'repo'
 repo.mkdir()
 hooks = Path(directory) / 'empty-hooks'
 hooks.mkdir()
 env = {'PATH': os.environ['PATH'], 'LC_ALL': 'C',
 'GIT_CONFIG_NOSYSTEM': '1', 'GIT_CONFIG_GLOBAL': os.devnull}

 def git(*args):
 return subprocess.check_output([
 'git', '-c', 'user.name=Example', '-c', 'user.email=example@example.invalid',
 '-c', 'commit.gpgsign=false', '-c', f'core.hooksPath={hooks}',
 '-c', 'core.autocrlf=false', *args], cwd=repo, env=env, text=True)

 git('init', '-q', '-b', 'main')
 (repo / 'price.py').write_text('def shipping(subtotal):\n return 5 if subtotal <= 50 else 0\n')
 (repo / 'test_price.py').write_text('from price import shipping\nassert shipping(49) == 5\n')
 (repo / 'notes.txt').write_text('unrelated draft\n')
 git('add', 'price.py', 'test_price.py', 'notes.txt')
 git('commit', '-qm', 'Add shipping calculation and its initial check')
 test = 'from price import shipping\nassert shipping(49) == 5\nassert shipping(50) == 0\n'
 (repo / 'test_price.py').write_text(test)
 failed = subprocess.run([sys.executable, '-B', 'test_price.py'], cwd=repo,
 capture_output=True, text=True)
 assert failed.returncode != 0 and 'AssertionError' in failed.stderr
 (repo / 'price.py').write_text('def shipping(subtotal):\n return 5 if subtotal < 50 else 0\n')
 (repo / 'notes.txt').write_text('unrelated draft, still being edited\n')
 git('add', 'price.py', 'test_price.py')
 staged = git('diff', '--cached', '--name-only').splitlines()
 assert staged == ['price.py', 'test_price.py']
 snapshot = Path(directory) / 'index-snapshot'
 snapshot.mkdir()
 for name in staged:
 (snapshot / name).write_text(git('show', ':' + name))
 subprocess.run([sys.executable, '-B', 'test_price.py'], cwd=snapshot, check=True)
 git('commit', '-qm', 'Make the free-shipping threshold inclusive')
 assert git('status', '--porcelain') == ' M notes.txt\n'
 assert git('show', 'HEAD:notes.txt') == 'unrelated draft\n'
 print(json.dumps({'regression_failed_before_fix': True,
 'staged_files': staged, 'staged_test_passed': True,
 'unrelated_edit_preserved': True}))

新增的边界断言首先会在旧函数上失败。修正之后，脚本仅暂存 price.py 和 test_price.py，再把这两个文件的暂存字节复制到另一目录，在那里执行断言，成功后才提交。输出同时记录修复前的失败和暂存快照的成功，因而能区分“测试存在”与“测试确实运行并通过”这两件事。

最终状态只剩 notes.txt 的无关未提交修改；提交中的笔记仍保持原来的文字。这证明选择性暂存没有吞掉另一项工作的内容。实验覆盖一组完整文件的提交边界，没有模拟所有部分暂存组合，也没有执行真实的 revert 或 bisect 会话。临时目录结束后自动清理，当前业务仓库的历史不会被这段示例修改。

留下差异之外仍然需要的理由

“让免运费门槛包含临界值”这样的主题能够直接说明行为变化。正文可以补充原先观察到的错误、期望契约和实际运行的验证，避免只写“修复问题”让后来的人重新猜测。不能因为提交中新增了测试文件，就声称测试已经通过；应说明验证的是哪个快照。发布一组提交前，既要读合并后的完整差异，也要看每个检查点：最终功能要成立，中间步骤也应当如实表达它是怎样逐渐变得可用的。

来源

Git: git-add，暂存区如何记录选中的内容，已核验 2026-09-13。
Git: git-bisect，可测试版本与跳过提交的语义，已核验 2026-09-13。
Git: git-revert，反向提交及其冲突处理，已核验 2026-09-13。

git bisect 用自动探针定位回归

Wed, 07 Jul 2027 00:00:00 +0000

自动二分会反复检查历史版本，并把测试结果转成对提交的判断。在简单区间里，它通常能用近似对数级的探针次数替代大量手动检出，但前提是测试可信。包装脚本若把工具缺失或基础设施故障错误归类为产品回归，就可能给出看似明确、实际错误的提交。因此，设计判断契约本身就是调试工作的一部分，不能当作搜索外面无关紧要的准备步骤。

先确定能够复现的问题

选择一个可观察的回归，并用同一个执行器验证计划采用的正常端点和异常端点。某个发布名字被认为没问题，证据弱于在那个准确版本上实际检查成功。输入、工具链、依赖和相关环境应保持足够一致，让源码版本成为真正接受检验的变量；否则即使最后缩小到一个提交，也无法知道改变结果的究竟是代码还是环境。

启动时先给出异常版本，再给出已知正常版本。Git 会选择中间提交，并从当前检出的工作树调用探针。执行器应放在不会随历史切换而消失的稳定路径，或确保每个待测版本都包含可用实现。相对路径脚本在搜索一半时不存在，属于测试设施问题，不是产品恰好从那次提交开始损坏的证据。

按真实退出码契约映射结果

自动运行模式中，零表示正常；一到一百二十七表示异常，但一百二十五是例外，代表当前版本无法测试，需要跳过。其他状态值会中止自动搜索。这与“所有非零都说明发生回归”的简化说法不同，包装脚本必须明确区分结果，而不能把任何失败都交给 Git 当作同一种判断。

文档规定的异常区间包含常用于命令不可执行或不存在的一百二十六和一百二十七。应提前检查必需工具，并把识别出的基础设施失败映射到中止状态，例如二百。不能不看测试工具自身的含义，就原样转交所有非零返回。另外，超出可表示范围的 Shell 退出值可能被截断，因此需要选择明确、受支持的状态，不能随意用一个巨大数字表示致命错误。

跳过适用于某个确实无法测试、结论未知的版本，而不是所有构建失败。如果正在寻找的回归本来就是构建损坏，把构建失败跳过就等于丢掉主要证据。反过来，与症状无关的过时依赖，也不应自动把旧提交判坏。执行器为什么把两类情况区别对待，需要有可检查的依据，并在日志中保留相应原因。

坏掉的样子

测试输出经过管道时，最后的日志命令成功可能掩盖测试失败；清理命令也可能覆盖原状态。应先保存测试结果，再记录诊断，最后明确返回映射后的判断值。标准错误上出现了一段异常文字，并不会阻止 Git 接受意外返回的零。自动化读取的是状态契约，不会根据人类看起来很严重的日志重新推断好坏。

修改源码的测试、复用陈旧构建产物的测试，以及依赖持续变化远端服务的测试，都可能让不同版本之间失去可比性。应隔离生成文件，并保留足够日志解释每次判断。不要为了让探针可重复，就清空宽泛的用户目录；应使用可丢弃且归属明确的测试环境，把清理范围限定到自己创建的路径。

靠近转换边界的跳过，可能留下多个首坏候选。随机失败或非单调变化的判断条件，也会破坏简单边界假设；增加次数不能修复错误标签。归因之前应检查搜索日志，在报告出的边界及相关父级重新测试。提交图、跳过版本和不同构建耗时还意味着，对数级探针次数并不等于固定的实际运行时间。

快速验证

使用 Python 3 和 Git 2.28 或更新版本运行下面实验。临时仓库排除个人 Git 配置和路由变量，关闭钩子与签名，没有远端。九个合成版本编码正常、异常或不可测状态；第七号版本首次变坏，第四号版本专门触发跳过路径。执行器位于检出仓库之外，因此切换提交不会把它移走或替换成旧版本。

import os
import subprocess
import sys
import tempfile
from pathlib import Path

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-bisect-run-") as directory:
 root = Path(directory)
 repo, probe = root / "repo", root / "probe.py"
 repo.mkdir()
 probe.write_text('''from pathlib import Path
import sys
try:
 state = Path("state.txt").read_text().strip()
except OSError:
 sys.exit(200)
code = {"good": 0, "bad": 1, "skip": 125}.get(state, 200)
print(f"probe={state} code={code}")
sys.exit(code)
''')
 def git(*args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=Bisect Example",
 "-c", "user.email=bisect@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=repo, env=env, text=True, capture_output=True, check=check,
 )
 git("init", "-q", "-b", "main")
 commits = []
 for number in range(9):
 state = "skip" if number == 4 else ("bad" if number >= 7 else "good")
 (repo / "state.txt").write_text(state + "\n")
 git("add", "state.txt")
 git("commit", "--allow-empty", "-qm", f"revision {number}")
 commits.append(git("rev-parse", "HEAD").stdout.strip())
 codes = []
 for revision in (commits[0], "main"):
 git("switch", "-q", "--detach", revision)
 codes.append(subprocess.run([sys.executable, str(probe)], cwd=repo,
 text=True, capture_output=True).returncode)
 git("switch", "-q", "main")
 assert codes == [0, 1], codes
 print("endpoints-verified:", True)
 git("bisect", "start", commits[-1], commits[0])
 try:
 run = git("bisect", "run", sys.executable, str(probe))
 assert "probe=skip code=125" in run.stdout, run.stdout
 print("skip-observed:", True)
 assert git("rev-parse", "refs/bisect/bad").stdout.strip() == commits[7]
 print("first-bad-correct:", True)
 finally:
 git("bisect", "reset")
 git("bisect", "start", commits[-1], commits[0])
 try:
 before = git("bisect", "log").stdout
 fatal = git("bisect", "run", sys.executable, "-c", "raise SystemExit(200)", check=False)
 assert fatal.returncode != 0 and git("bisect", "log").stdout == before
 print("fatal-did-not-classify:", True)
 finally:
 git("bisect", "reset")
 assert git("symbolic-ref", "--short", "HEAD").stdout.strip() == "main"
 assert git("rev-parse", "HEAD").stdout.strip() == commits[-1]
 assert not git("status", "--porcelain").stdout
 print("original-checkout-restored:", True)

五个观察会先由断言检查，再打印真值；样本若不满足契约会以失败状态退出，不会只是显示一个假值然后仍然成功返回。执行器先确认两个端点，搜索中实际遇到跳过码，仍然正确定位第七号版本。第二次搜索故意返回二百，应中止且不向二分日志增加新的好坏判断。两次搜索最后都恢复原分支与原末端，并保持工作树干净，避免把仍处于排查状态误当作已经回到正常开发位置。

这个样例验证自动化语义，包括未知版本和致命测试设施结果。状态文件有意使用合成数据，不冒充某个应用的业务测试。应用到真实回归时，应换成已经独立验证的复现条件，同时保留正常、异常、不可测和测试设施损坏这四种区别，才能让自动搜索的结论与实际问题保持一致。

来源

Git bisect 参考，执行器退出码、跳过版本、搜索日志和恢复行为，已核验 2026-09-07。
Pro Git：使用 Git 调试，建立端点及自动化回归搜索，已核验 2026-09-07。

git tag 把一次发布固到提交

Fri, 11 Jun 2027 00:00:00 +0000

发布标签为某个源码版本提供一个容易交流的名字。它与分支不同，创建新提交时不会自动前进。但 Git 并没有从物理上禁止标签变化：拥有相应权限的人仍能替换或删除标签引用。可靠的发布约定来自几件事共同作用：记录对象标识、坚持发布名称不可变，以及限制谁能够更新发布引用。不能仅凭“用了标签”就断言任何人拿到的代码一定相同。

两种标签

轻量标签是直接指向某个对象的引用，通常指向提交。附注标签则指向单独的标签对象，其中保存目标、打标签者身份、时间、说明，以及可选的签名。打标签的人并不一定是提交作者；有了这些元数据，也不意味着附注已经经过密码学签名。发布记录需要说明谁作出发布决定，而不是把提交作者与发布者混为一谈。

对于附注标签，git rev-parse refs/tags/v2.4.1 得到标签对象标识，git rev-parse 'refs/tags/v2.4.1^{commit}' 则解引用到目标提交。当说明或签名身份也是发布证据的一部分时，应同时记录二者。只比较提交会漏掉标签留言或签名者变化；只比较可读名称，则连源码是否一致也无法确定。对象标识与名称各自承担不同的核对职责。

为什么给发布签名

git tag -v 使用配置的签名后端及本地信任材料验证签名标签。密码学验证成功之后，还需要确认该密钥确实属于项目发布策略认可的人。一个陌生人的有效签名，并不能证明维护者批准了这次发布。密钥的来源、授权范围和撤销状态，都应由实际发布流程明确管理，而不是靠命令里出现“成功”两个字代替。

源码标签有签名，也不能直接证明下载的二进制就是从该源码构建的。制品校验和、构建来源记录及构建过程，需要补上这条独立关系。另外，不要把验签命令接到 head 后面，再依赖管道最后一项的退出码：只截取几行输出可能掩盖验签失败。发布检查应保留并判断验签命令自身的结果，显示多少行只是界面选择。

移动要格外小心

修正尚未分享的本地标签，与替换消费者已经获取的标签，是两种不同操作。标签一旦分发，应优先使用新版本名称，并记录旧版本被撤回的原因。修补安全缺陷也不要求重写旧标签；保留原引用反而有助于识别受影响部署。服务端的引用保护应阻止未经授权的发布标签更新与删除，不能只靠客户端的习惯维持这个约定。

如果特殊情况下确实批准替换，应公布准确的新旧对象标识，并只协调那个明确的引用。把所有标签一起强制获取，会覆盖其他无关的本地引用，不应成为常规修复建议。消费者需要知道自己持有的是哪一个对象，不能让两个不同提交在没有说明的情况下继续共享同一个发布名称。

坏掉的样子

latest 这类浮动名称可能在两次构建之间解析到不同提交。即便界面保留方便阅读的名字，也应为每个制品和每次部署记录真正解析到的提交标识。同名不保证两次构建一致，而固定提交也不会自动固定外部依赖或编译器版本。源码定位与可复现构建有关，却不能互相替代。

另一种故障是发布标签只存在于某个本地克隆。普通分支推送不一定传输它；--follow-tags 处理的是从推送提交可达、符合条件的附注标签，不是本地全部标签。应使用 git ls-remote --tags 核对准确的远端引用及对象标识，不能对版本号作模糊子串匹配，否则可能把另一个版本当成目标。远端可见只能证明分发，不能证明构建正确或签名可信。

快速验证

在 POSIX 系统上用 Python 3 及 Git 运行下面的实验。它创建独立临时仓库，使用示例身份，为演示明确关闭签名，并且不配置远端。所有提交和标签都位于这个临时仓库，不会给当前项目打标签；退出后由临时目录管理器清理。命令通过参数列表调用，不需要拼接或解释来自外部的 Shell 文本。

import os
import subprocess
import tempfile

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-tag-demo-") as directory:
 def git(*args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=Tag Example",
 "-c", "user.email=tags@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "tag.gpgsign=false",
 "-c", "core.hooksPath=/dev/null", *args],
 cwd=directory, env=env, text=True, capture_output=True, check=check,
 )

 git("init", "-q")
 git("commit", "--allow-empty", "-qm", "first")
 first = git("rev-parse", "HEAD").stdout.strip()
 git("tag", "-a", "demo-v1", "-m", "example release")
 git("tag", "demo-bookmark")
 print("annotated:", git("cat-file", "-t", "demo-v1").stdout.strip())
 print("lightweight:", git("cat-file", "-t", "demo-bookmark").stdout.strip())
 git("commit", "--allow-empty", "-qm", "second")
 target = git("rev-parse", "demo-v1^{commit}").stdout.strip()
 print("tag-still-first:", target == first)
 print("head-moved:", git("rev-parse", "HEAD").stdout.strip() != first)
 duplicate = git("tag", "demo-v1", check=False)
 print("existing-name-refused:", duplicate.returncode != 0
 and git("rev-parse", "demo-v1^{commit}").stdout.strip() == first)
 verification = git("tag", "-v", "demo-v1", check=False)
 print("unsigned-rejected:", verification.returncode != 0)

开头应分别输出对象类型 tag 和 commit，随后四个判断都为真。新提交让分支前进，但标签仍指向第一个提交；不带强制选项复用既有名称会失败，目标保持不变。这项本地保护与服务端引用保护不同。未签名的附注会验签失败。这个实验有意不把“标签存在”冒充“可信签名”或“远端已经发布”：后两项仍需要项目实际认可的密钥策略，以及对真实远端引用的准确检查。

来源

git tag 参考，标签对象及替换已分发标签的影响，已核验 2026-10-15。
Git 打标签基础，轻量与附注标签及共享行为，已核验 2026-10-15。

git 分支是一个会移动的标签

Fri, 05 Feb 2027 00:00:00 +0000

Git 分支为一条历史线的末端提供名字。新建分支通常只是增加一个指向既有提交的引用，不会再复制一份全部受跟踪文件。两个名字可以先指向同一提交，再分别前进。这让分支创建成本很低，但不意味着名字内部装着历史，更不意味着删除指向某个提交的全部引用后，内容仍会永远保留。理解分支时，需要把名称、对象和保留条件分开。

它是引用，不是固定的存储文件

本地分支属于 refs/heads/ 引用命名空间，具体表示方式是实现细节：引用可能独立存储、被打包，或使用其他受支持的后端。不要假定一定存在某个松散文件，就直接编辑 Git 内部目录来移动分支。应使用 Git 的引用命令，让它遵守仓库实际的存储结构和更新规则，而不是把一种磁盘布局当作永久接口。

提交记录目录树和父提交，沿着父级关系向前追溯，就得到分支末端可达的历史。因此，两条分支可以共享大部分祖先，却拥有不同的末端。分支名称不是提交身份的一部分，新增或重命名分支也不会改写它指向的提交。图中的对象关系解释了共享历史，名称只是人们访问这些对象的入口。

创建分支与切换分支也不同。git branch topic 在当前提交创建名称，但当前分支不会改变；git switch topic 才选中它，并按需要更新工作树。git switch -c topic 把创建与切换合在一起。记录新工作之前，应检查真正活动的分支，不能因为名称已经存在，就误以为接下来的提交一定会记在那条线上。

HEAD 决定哪个名字前进

第一次提交之前，HEAD 可以指向尚未诞生的分支名，此时分支引用还无法解析为提交。这与分离状态不同：名字已被选中，只是没有首个提交对象。仓库已有提交之后，通常的附着状态下，HEAD 通过符号引用指向当前分支。创建提交时，该分支前进到新对象，其他原本共享旧末端的分支保持不动；新提交的父级关系保留祖先。分支也可能因合并或其他明确更新引用的操作而移动，并不是只有普通提交才能改变它。因此，判断某个名字为什么变化，需要检查实际发生的操作，而不只看提交按钮是否被点击。

直接选中一个提交，可以进入分离状态。之后的新提交会推动 HEAD，但不会推动某条本地分支。提交本身是真实对象，只是切换离开后可能没有持久的分支名称指向它。离开之前可以在目标提交创建分支，或者之后凭已知对象标识重新命名。引用日志有助于恢复，却受到保留时间和垃圾回收影响，不能被当作永久保存承诺。

origin/main 这类远端跟踪引用，是本地对远端状态的观察，通常随获取操作更新；它不是实时连接，也不等同于本地 main。上游配置描述供相关命令使用的分支关系，不会在任意一方提交时自动同步两个末端。排查本地与远端差异时，应明确比较的是哪两个引用，以及远端状态上次何时被获取。

坏掉的样子

未提交改动属于工作树和索引，不是一份已经保存在分支里的快照。切换时，兼容的改动可能被一起带走；如果会覆盖当前修改，Git 也可能拒绝切换。应先检查工作区状态，再有意识地保存未完成工作。仅仅创建一个分支名字，并没有保存那些从未提交的编辑，不能据此清理或丢弃文件。

删除分支是删除引用，不是要求立即擦除它曾经到达的全部对象；其他引用可能继续保留那些提交。但如果最终没有任何保留路径，对象以后仍可能被清理。普通删除命令检查目标是否已经合入配置的上游；没有上游时，则检查是否合入当前 HEAD。这种保护检查的是图上关系，不是合并后程序是否正确，更不是对所有业务改动都已经保留的验收。

合并也不只是多加一个名字。快进会移动已有引用，而分叉历史的普通合并通常创建带结果目录树和多个父级的新提交。父级可达关系保留历史对象，却不保证每项贡献都正确地出现在合并后的文件中。审阅时既要看图，也要看内容，不能把“历史还能找到”解释成“最终行为没有丢失”。

快速验证

在 POSIX 系统上使用 Python 3 和 Git 2.28 或更新版本运行下面的实验。它只在私有临时仓库创建空提交，排除个人 Git 配置和继承的 Git 路由变量，关闭钩子及签名，不配置任何远端。删除尝试也只针对这个可丢弃仓库里的演示分支，不会影响当前项目的引用。实验结束后，临时目录管理器会清理整套演示数据。

import os
import subprocess
import tempfile

env = {key: value for key, value in os.environ.items() if not key.startswith("GIT_")}
env.update(GIT_CONFIG_NOSYSTEM="1", GIT_CONFIG_GLOBAL=os.devnull)
with tempfile.TemporaryDirectory(prefix="git-branch-demo-") as directory:
 def git(*args, check=True):
 return subprocess.run(
 ["git", "-c", "user.name=Branch Example",
 "-c", "user.email=branch@example.invalid",
 "-c", "commit.gpgsign=false", "-c", "core.hooksPath=/dev/null", *args],
 cwd=directory, env=env, text=True, capture_output=True, check=check,
 )
 git("init", "-q", "-b", "main")
 print("unborn-is-not-detached:",
 git("symbolic-ref", "--short", "HEAD").stdout.strip() == "main"
 and git("rev-parse", "--verify", "HEAD", check=False).returncode != 0)
 git("commit", "--allow-empty", "-qm", "base")
 base = git("rev-parse", "HEAD").stdout.strip()
 git("branch", "topic")
 print("created-without-switch:",
 git("symbolic-ref", "--short", "HEAD").stdout.strip() == "main")
 print("same-tip:", git("rev-parse", "topic").stdout.strip() == base)
 git("switch", "-q", "topic")
 git("commit", "--allow-empty", "-qm", "topic work")
 topic = git("rev-parse", "HEAD").stdout.strip()
 print("only-topic-moved:", topic != base
 and git("rev-parse", "main").stdout.strip() == base)
 git("switch", "-q", "--detach", "HEAD")
 git("commit", "--allow-empty", "-qm", "detached work")
 detached = git("rev-parse", "HEAD").stdout.strip()
 print("detached-without-moving-topic:",
 git("symbolic-ref", "-q", "HEAD", check=False).returncode == 1
 and git("rev-parse", "topic").stdout.strip() == topic)
 git("branch", "rescue", detached)
 git("switch", "-q", "main")
 print("unmerged-delete-refused:",
 git("branch", "-d", "topic", check=False).returncode != 0)
 print("rescued-commit:", git("rev-parse", "rescue").stdout.strip() == detached)

七个判断都应为真。未诞生分支有名字，但还没有提交。创建 topic 后当前仍选中 main；在 topic 提交只推动那一个名字。分离状态的新提交不会推动 topic，而 rescue 随后为新结果提供名称。从尚未合入该工作的 main 删除 topic 会被拒绝，即便另一个引用也保留着这些历史。这说明当前分支选择、提交可达性和删除策略是不同问题，不能只看到某个对象还在，就推断任意分支操作都会被允许。

来源

Pro Git：分支简介，分支末端、HEAD 与共享祖先，已核验 2026-10-15。
Git branch 参考，创建分支、上游关系和删除检查，已核验 2026-10-15。
Git 仓库布局，HEAD 可以指向未诞生分支，已核验 2026-10-15。

凭据应留在仓库历史之外

Mon, 14 Sep 2026 00:00:00 +0000

凭据一旦提交到 Git，就成为版本化对象关系的一部分，协作者和自动化系统都有可能复制它。从最新目录树删除文件，并不会删除先前包含它的提交。实际应建立的边界，是让凭据值不进入源码历史，再通过获得授权的运行时机制供应。仓库配置可以说明怎样取得秘密，而不需要把秘密本身写进可复制的源文件。

坏掉的样子

一个看起来干净的检出，可能掩盖历史版本中已经暴露的值。新克隆通常会收到可达历史，包括已删除文件的旧版本。不能说 Git 在任何清理策略下都会永远保留所有对象，但“删掉今天的文件”确实不等于清理历史。即使重写一个仓库，也无法召回已经独立分发出去的克隆、分叉、缓存和构建产物，清理某一位置不能代表所有副本都已消失。

面对真实泄漏，应先撤销或替换相关凭据，并确认哪些系统会接受它。删除一行改变的是发布内容，不是认证状态。历史重写应单独协调，因为它会改变提交标识，也可能打断协作者的工作。说明事件时，不能再把原值复制到问题单、提交说明、扫描报告或事故笔记里，否则处理过程本身又制造了新的传播位置。

运行时注入也不会自动保密。环境值可能被子进程继承或被诊断工具采集；文件可能被具有足够访问权限的身份读取。应限制消费服务的权限，控制交付通道，避免把真实值写入日志和生成结果。即使文件位于仓库外，也仍然需要明确的拥有者与生命周期，不能把“没有提交到 Git”当作全部秘密管理工作已经完成。

快速验证

在安装了 Git 的 POSIX 系统上运行下列 Python 脚本。它使用明确的虚构标记，绝不使用任何有效凭据；两个仓库和运行时文件都位于同一个临时目录，退出后一起清理。夹具排除继承的 GIT_* 覆盖值、系统及全局配置和模板钩子，记录中的 Git 版本为 2.50.1：

from pathlib import Path
from tempfile import TemporaryDirectory
import io,os,stat,subprocess,sys,tarfile

env={key:value for key,value in os.environ.items() if not key.startswith('GIT_')}
env.update(GIT_CONFIG_NOSYSTEM='1',GIT_CONFIG_GLOBAL=os.devnull)
with TemporaryDirectory(prefix='credential-repo-lab-') as directory:
 base=Path(directory);repo=base/'source';repo.mkdir()
 def git(*args,cwd=repo,binary=False):
 result=subprocess.run(['git',*args],cwd=cwd,env=env,capture_output=True,text=not binary)
 assert result.returncode==0,result.stderr
 return result.stdout
 git('init','-q','--template=');git('config','user.name','Credential Lab')
 git('config','user.email','credentials@example.invalid')
 git('config','commit.gpgsign','false')
 dummy='EXAMPLE-ONLY-NOT-A-REAL-SECRET\n'
 (repo/'fixture.env').write_text(dummy)
 (repo/'app.txt').write_text('read the configured credential file at runtime\n')
 git('add','--','fixture.env','app.txt');git('commit','-qm','Synthetic exposure fixture')
 original=git('rev-parse','HEAD').strip()
 git('rm','--','fixture.env');git('commit','-qm','Remove fixture from current tree')
 assert not (repo/'fixture.env').exists()
 assert git('show',original+':fixture.env')==dummy
 clone=base/'clone';git('clone','-q','--no-local',str(repo),str(clone))
 assert not (clone/'fixture.env').exists()
 assert git('show',original+':fixture.env',cwd=clone)==dummy
 print('current file absent; historical fixture readable in source and clone')
 archive=git('archive','--format=tar','HEAD',binary=True)
 with tarfile.open(fileobj=io.BytesIO(archive),mode='r:') as bundle:
 assert bundle.getnames()==['app.txt']
 print('current-tree archive excludes fixture; Git history still contains it')
 runtime=base/'runtime';runtime.mkdir(mode=0o700)
 secret_file=runtime/'credential';secret_file.touch(mode=0o600)
 secret_file.write_text(dummy)
 assert stat.S_IMODE(secret_file.stat().st_mode)==0o600
 child_env=dict(env,CREDENTIAL_FILE=str(secret_file))
 child="from pathlib import Path; import os; p=Path(os.environ['CREDENTIAL_FILE']); assert p.read_text(); print('credential loaded without printing its value')"
 result=subprocess.run([sys.executable,'-c',child],cwd=clone,env=child_env,text=True,capture_output=True)
 assert result.returncode==0,result.stderr
 assert dummy.strip() not in result.stdout+result.stderr
 print(result.stdout.strip())

第一项确认，两个当前工作区都没有样本文件，但都能通过早先的提交读取它的原始内容。克隆使用普通 Git 传输路径，关闭本地硬链接优化，因此验证的是另一个实际建立起来的对象数据库，不只是两个路径恰巧指向同一份文件。脚本在内部比较虚构标记，结果只说明是否保留，没有打印它的值，保留了检查与泄漏输出之间的区别。

当前树的归档只包含应用说明。这说明导出一个干净的当前目录树，可以不带上已删除文件，同时源仓库历史仍然保留该文件。但这个结果不能证明任何打包方式都安全：构建脚本可能接收其他输入、复制仓库元数据，或者把编译时传入的秘密写进产物。应检查实际发布路径，不能把某一次安全的归档命令外推成所有构建步骤的保证。

运行时示例创建私有目录，并将凭据文件设置为仅拥有者可读写。子进程通过环境取得的是文件路径，读取后只打印一条确认消息；断言会拒绝意外输出虚构标记。这里证明了源码与运行时文件分离，以及普通 POSIX 权限设置成立，并没有实现完整秘密服务、静态加密，也不能保护它免受相同操作系统身份读取。实验边界需要与真实部署需求分开理解。

明确交付与恢复路径

仓库中可以提交配置结构或带有无害占位值的示例，实际值由部署平台或访问范围受限的秘密服务供应。如果平台支持成熟的工作负载身份，可优先沿用，避免为了获取一种凭据，又永久分发另一把权限更大的启动凭据。同时要决定应用怎样重新载入替换值，以及旧访问怎样被撤销；仅把新值写入存储，不代表运行中的进程已经开始使用它。

在能够减少常见失误的位置加入秘密检测，例如提交前和持续集成中，并使用合适的虚构样本验证规则是否真的生效。模式和熵检测可能漏掉不认识的凭据，也可能把合法示例识别为问题。检测结果应作为调查证据，不能把没有告警视为仓库绝对安全，也不能为了消除一个误报就不加区分地屏蔽整类风险。

按照实际交付链检查发布归档、容器层、构建日志、缓存和诊断附件。Git 的忽略规则不会自动控制这些输出。记录受影响凭据的标识和撤销证据即可，不要复制真实值。完整修复需要旧访问确实失效、替换过程受控、传播范围得到理解；一个删除提交只能证明最新目录树发生了变化，无法单独证明凭据已经失去作用。

来源

GitHub 敏感数据清理，先撤销凭据、再协调历史清理，以及分布副本的限制，已核验 2026-09-12。
OWASP 秘密管理，交付、最小权限、日志与凭据生命周期，已核验 2026-09-12。
git archive，导出选定的仓库目录树，已核验 2026-09-12。

Git · XB 现场笔记

merge 与 rebase 画出的历史线不同

合并记录什么

变基改变什么

坏掉的样子

快速验证

延伸阅读

来源

git merge 用一个新的提交把分叉的两条线接起来

父级保留历史，不把它改写成单线

记录连接之前先审阅结果树

坏掉的样子

快速验证

延伸阅读

来源

git stash 把改动暂存到别处

明确快照包含的范围

应用与弹出不同

坏掉的样子

快速验证

来源

git cherry-pick 重新应用一次提交

选择的是相对父提交的变化

移植之前检查依赖

坏掉的样子

快速验证

来源

.gitignore 控制未跟踪路径的处理

坏掉的样子

快速验证

审阅下一次提交的真实内容

来源

用 git worktree 做热修复，不打断功能开发

先选基线，再开另一个目录

在真实热修复目录复现与验证

坏掉的样子

快速验证

延伸阅读

来源

git bisect 收敛第一个坏提交

依据观察选择端点，而不是日期

每次都判断同一个性质

坏掉的样子

快速验证

延伸阅读

来源

Git 工作树共享仓库，各自保留检出状态

区分每份检出自己的状态

共享不代表所有东西都共享

坏掉的样子

快速验证

延伸阅读

来源

小提交应当讲清一个完整变化

暂存区决定这次留下的检查点

坏掉的样子

快速验证

留下差异之外仍然需要的理由

来源

git bisect 用自动探针定位回归

先确定能够复现的问题

按真实退出码契约映射结果

坏掉的样子

快速验证

延伸阅读

来源

git tag 把一次发布固到提交

两种标签

为什么给发布签名

移动要格外小心

坏掉的样子

快速验证

延伸阅读

来源

git 分支是一个会移动的标签

它是引用，不是固定的存储文件

HEAD 决定哪个名字前进

坏掉的样子

快速验证

来源