标签: #version-control

한국어English日本語中文

← 全部文章

• .gitignore 不生效的时候 — 头号原因与模式规则精读

  明明在忽略列表里写清楚了，文件却还是一直被提交上去，原因基本只有一个：对已经被跟踪的文件，忽略规则不生效。本文讲清楚把它从索引里摘出来的准确命令，以及这条命令会把文件从同事工作目录里删掉的副作用；讲怎么用 check-ignore 直接问 Git 究竟是哪条规则在作祟，以及它对被跟踪文件什么都不输出的坑；还有前导斜杠、末尾斜杠和否定模式的顺序依赖，排除上层目录会让其中的否定模式失效这条规则，忽略规则的优先级层次，以及不区分大小写的文件系

  2026-07-26 · 16 分钟阅读 #git#gitignore#troubleshooting#security#version-control

• 用 Git 内部结构理解命令 — 用对象、引用、索引重读 reset 和 rebase

  把 Git 命令背下来，结果每次还得搜；可只要懂了数据模型，命令的行为是可以推出来的。本文用 cat-file 和 ls-files 亲手打开来看：blob、tree、commit、tag 这四种对象，相同内容永远得到相同哈希的内容寻址，分支不过是一个 41 字节的文件这一事实，以及索引里到底装了什么。有了这个模型，reset 为什么是指针移动、rebase 为什么不是搬走提交而是新建提交、cherry-pick 为什么会冲突、deta

  2026-07-26 · 16 分钟阅读 #git#internals#git-objects#fundamentals#version-control

• git 撤销 — 按情况挑选 restore、reset、revert、reflog

  把撤销命令背下来，结果每次还是要搜；可要是先把"我到底想撤销什么"分类清楚，命令自己就定下来了。本文把问题拆成六种情况——工作目录、暂存、上一条提交信息、提交本身、已经推送出去的提交、被删掉的分支——并给出各自准确的命令和风险等级。文中用一张表展示 reset 的 soft、mixed、hard 分别移动 HEAD、索引、工作树中的哪些部分，说明为什么已推送的历史只有 revert 这一个答案，以及把合并提交 revert 之后再合并一

  2026-07-26 · 16 分钟阅读 #git#undo#reset#reflog#version-control

• git 变慢的时候 — 让大型仓库重新变快的结构性处方

  仓库变慢的原因不止一个。提交历史太长、文件数量太多、里面塞了大的二进制文件，这是三个不同的问题，处方也各不相同。本文先从区分原因的测量命令讲起，说明浅克隆和部分克隆为什么不是彼此的替代品而是用途不同的工具，sparse-checkout 和文件监视如何把 status 缩短，以及 commit-graph 为什么能把日志和合并基准点的计算改变得那么明显。文中还讲了"用 aggressive 跑 gc"这条常见建议为什么大多是亏的，为什么

  2026-07-26 · 16 分钟阅读 #git#performance#monorepo#git-lfs#version-control

• git merge vs rebase — 什么时候用哪个，为什么共享分支不做 rebase

  merge 和 rebase 的差别，看图不准，看提交哈希才准。变基不是移动提交的命令，而是创建父提交不同的新提交的命令，而哈希会变这一个事实，就是"不要对共享分支做 rebase"这条黄金法则的唯一依据。本文用真实的提交哈希和 reflog 输出展示这个变化，用 first-parent 日志反驳"合并提交是噪音"的成见，讲清楚压缩合并从 bisect 和 cherry-pick 那里拿走了什么，变基过程中同一个冲突反复出现的原因以及

  2026-07-26 · 16 分钟阅读 #git#rebase#merge#version-control#workflow

• git history — Git 放在 rebase 旁边的实验性历史重写命令

  Git 2.54(2026-04-20)以实验特性的形式引入了名为 git history 的新命令，2.55(2026-06-29)又加入了 fixup 子命令。它把 reword/split/fixup 这三种常见的历史重写操作，用一条命令就能完成，不再需要交互式 rebase，并且会用一次原子性的 ref 事务，把目标提交的所有后代分支一并更新。维护者 Patrick Steinhardt 在提交信息里直接点明了这个功能的动机 —

  2026-07-16 · 24 分钟阅读 #git#version-control#jujutsu#rebase

• Git 到底是怎么存储数据的

  我们大多数人每天都在用 Git，却不知道它内部长什么样。本文从底层出发，梳理由 blob、tree、commit、tag 组成的对象模型，用 SHA 哈希对内容做寻址的方式，提交组成的 DAG，分支其实只是指针这一事实，.git 目录的真实样貌，相同内容只存一次的原理，以及打包文件(packfile)。这是 Git 背后真正的数据模型。

  2026-06-13 · 23 分钟阅读 #git#version-control#fundamentals

• Git 精通指南 — 从基础到 rebase、cherry-pick、bisect、worktree

  从 Git 的内部结构，到高级命令（rebase、cherry-pick、bisect、worktree）、分支策略、PR 评审、Monorepo 管理 — Git 的一切。

  2026-04-12 · 20 分钟阅读 #devops#git#version-control#github#branching