非技术 Builder，到底需要懂多少 Git / 开发知识？
How much Git does a non-technical builder need?和 Coding Agents 一起做产品以后，我经常会碰到一些以前不会主动学习的词：
branch、main、worktree、origin/main、rebase、commit SHA、diverged……
如果每碰到一个词都停下来系统学习，很快就会发现：产品没做多少，开发基础课倒是越补越多。
但完全不懂也不行。
Agent 说“这个 branch 已经落后 main”“本地和远端发生分叉”“这个任务基于旧的 commit”，如果我完全不知道它在说什么，就很难判断现在能不能继续做。
所以对我来说，更实际的问题不是“我要不要学 Git”。
而是：
作为一个非技术背景的 Builder，我到底要懂到什么程度？
目前我给自己的边界是六件事。
1. 当前的「共同基准」是什么
一个项目同时可能存在很多“版本”：Claude Design 刚产出的设计、Coding Agent 正在修改的 branch、本地还没 commit 的文件，以及已经 merge 进入 main 的代码。
它们可能都很新，但状态不同。
对我来说最重要的是知道：哪一版是其他 Agent 默认应该继续工作的共同基准。
通常是已经 merge 的 main。其他内容可以比 main 更新，但在 merge 之前，它们仍然是 proposal、work in progress 或 candidate。
这并不意味着 main 里的所有东西永远正确。发生产品或设计冲突时，还需要继续看对应的 Product Definition、Design Rules 或其他 canonical source。
所以我需要理解的不是 Git 的每个细节，而是两件事：现在大家基于哪一版工作，以及发生冲突时谁有决定权。
所以当 Agent 说：
已经改好了。
我会多问一层：
是在 branch 里改好了，还是已经 merge 了？
这两件事差很多。
2. 单个任务是基于哪一版开始的
Coding Agent 说：
目前代码里是这样的。
这里的“目前”其实有时间范围。
一个任务如果已经做了几天，中间又有很多其他修改 merge 进入 main，它的判断可能仍然建立在几天前的代码上。
这就是 BASE 这个概念对我有用的地方。
我不需要自己记住一长串 commit SHA，只需要理解：
这个任务从项目的哪个版本开始？
如果 main 已经发生了相关变化，就需要让 Agent 重新检查原来的判断是否还成立。
具体怎么查 commit、怎么同步，由 Agent 完成。
我要知道的是：Agent 的上下文也会过期。
3. 分清是哪一种「已完成」
这个区别对非工程背景的人很容易混在一起。
一个任务可能已经：
设计完成；实现完成；测试通过；commit；push；甚至已经创建 PR。
它依然可能没有进入 main。
所以现在看到 Coding Agent 写：
implementedcommittedpushedmerged
我不会再把它们理解成同一件事。
implemented 只能说明某个工作区里已经做了。
merged 才意味着它进入了项目共同的主线。
这也让我更容易理解为什么几个 Agent 有时候会看到不同的产品状态。
4. 理解 branch 的作用，但不必自己精通 branch 操作
我现在对 branch 最需要的理解很简单：
main 是共同基线，branch 是一条暂时独立的工作线。
不同任务可以在不同 branch 上推进，互相不影响。
最后经过 review，再决定是否进入 main。
至于：
怎么建 branch；怎么建 worktree；什么时候 rebase；发生分叉怎么恢复；
这些我可以让 Coding Agent处理。
我需要能看懂的是：
这个修改现在在哪条工作线上？它有没有进入共同版本？
这已经足够解决大量沟通问题。
5. 能看懂 dependency，而不是自己解决所有冲突
有些开发问题看起来像 Git 问题，其实更重要的是依赖关系。
例如：
任务 A 正在修改一个全局组件。
任务 B 同时大量使用这个组件。
Git 最后可能完全没有报 conflict，但 B 原本基于旧组件做出的判断已经失效。
所以我需要知道：
这个任务依赖什么？
但我不需要自己决定用 merge 还是 rebase 去同步。
这也是我现在理解 technical literacy 的一个边界：
我要看懂关系，不一定要亲自执行操作。
6. 知道什么时候不能继续把决定交给 Agent
有一类问题，我会放心让 Coding Agent 自己处理：
这个 branch 落后 main，检查以后安全同步。
建一个新的 worktree。
Git history 有分叉，先保护现有修改，再给出恢复方案。
两个文件出现机械性的 merge conflict，按当前代码语义合并。
这些主要是技术执行。
另一类问题，我一定会介入：
新设计要求 Button 36px，但当前 Design Rules 写的是 34px，应该改哪边？
实际代码行为和 Product Definition 不一致，哪个才是 intended behavior？
两个任务对同一个组件提出了不同要求，产品最后应该选择哪一个？
这里缺的不是 Git 技巧。
缺的是一个决定。
如果我把这类判断也交给 Agent 自己“顺手解决”，最后很容易得到一个技术上完全成立、产品上却没有人真正决定过的结果。
所以，我并不需要把 Git 全部学会
我现在需要的，不是能够脱离 Coding Agent 独立完成所有工程操作。
我需要的是看懂几件关键事情：
- 当前什么算数；
- Agent 基于哪一版工作；
- 哪些修改还没有进入主线；
- 一条 branch 大概意味着什么；
- 任务之间有没有依赖；
- 问题什么时候已经从技术执行变成了产品决定。
至于 Git 命令、rebase、worktree、branch 清理、冲突恢复，我会随着使用慢慢知道一些，但没有必要把“自己熟练操作”当成目标。
对非技术背景的 Builder 来说，我觉得一个更实际的标准是：
看得懂，能判断，敢授权，也知道什么时候应该把决定收回来。
操作可以继续交给 Coding Agent。
版本、依赖和最终判断，至少要留在自己手里。