标签: #git

한국어English日本語中文

← 全部文章

• 同时跑五个智能体真的会快五倍吗 —— 并行作业的瓶颈不在生成

  专门用来同时运行多个编码智能体的环境正在变多。Orca 就是其中之一，它主打把一条提示词撒给多个智能体、把每个都隔离到各自的 git worktree 里，再比较结果并合并其中一个。但提高吞吐并不会让瓶颈消失，只会让它换个位置。本文用排队论的一行结论指出它换到了评审与合并上，并整理了在装工具之前只用 git worktree 就能试同一套工作流的方法。

  2026-08-09 · 13 分钟阅读 #developer-tools#git#worktree#code-review#workflow

• GitHub 堆叠 PR 完全指南 —— 原生堆叠 PR 解决了什么，又原样留下了什么

  2026 年 7 月 30 日，GitHub 把 Stacked Pull Requests 推进了公开预览阶段。把一次大改动拆成若干个带有依赖顺序的小 PR、并行评审、再一并合并的这套工作流，现在由 Web 界面和 gh-stack CLI 扩展原生提供支持。本文梳理堆叠(stacking)真正解决的问题、GitHub 原生实现做了什么又没做什么、当基础分支发生变化时触发的"变基级联(rebase cascade)"要付出多大代价，以

  2026-07-31 · 20 分钟阅读 #github#stacked-pr#code-review#git#developer-workflow

• .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

• 写出会被快速合并的 PR 和提交信息

  很快就被审阅完、很快就被合并的 PR，都有一些共同点。小而目的单一的 PR、Conventional Commits、提交正文里写的是"为什么"而不是"改了什么"、上传前自己先做一遍自我审查、包含背景·变更·测试三部分的 PR 说明、对审阅者的共情，以及堆叠 PR。节省审阅者的时间，就是让自己的 PR 更快通过的捷径。

  2026-06-26 · 13 分钟阅读 #git#code-review#collaboration

• 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