给非技术人的 Git：你不用记命令，只要会用人话说

上一篇讲检查点时留了个结论：bash 删掉的文件，回退救不回来，只能靠 Git。

于是问题变成：一个不写代码的人，要不要为此去学 Git？

不用。 你需要知道的是「有哪些事可以做」，剩下的用人话说给 Claude 听就行。

Git 是什么

给文件夹装的时光机。

它替你保存每一次改动、每一个版本，让你随时回到过去任何一个状态。GitHub 则是把这台时光机放到云端，方便你在多台电脑之间同步、或者和别人协作。

对研究工作，它解决三个真实问题：

• 改坏了能回去。 不用再存「报告_v3_最终_真最终.docx」
• 能看见改了什么。 两个版本之间到底哪里不同，一目了然
• 能开分线试。 想试一个大改动又怕毁掉现有的，开个分支，不成就扔掉

三条使用原则

在开始之前，先说清楚怎么跟 Claude 说话。

一、说目的，不说命令

• ❌ 「执行 git reset –hard HEAD」
• ✅ 「我刚才改的都不要了，回到上次保存的样子」

说目的，让它选命令。 你说错命令它就照做，你说错目的它会问你。

二、说清楚背景

• ❌ 「提交一下」
• ✅ 「把刚才改的访谈稿提交了，说明写『完成 A 组 12 份编码』」

三、危险动作先让它确认

涉及删除、覆盖、丢弃改动的操作，加一句：

执行前先告诉我这会影响哪些文件，等我确认。

这一句话能挡掉绝大多数事故。

---

本地：日常够用的九件事

让一个文件夹开始被管理

把这个文件夹用 Git 管起来。

这就是 git init。一次性动作，之后这个文件夹里的一切改动都有记录。

建议在开始任何批量处理之前先做这一步。

告诉它哪些文件不用管

帮我建一个 .gitignore，把临时文件、系统文件和体积大的原始音频排除掉。

有些东西不该进版本库：系统自动生成的文件（.DS_Store）、几个 G 的原始录音、含敏感信息的台账。

⚠️ 含客户数据或凭据的文件一定要排除。 一旦提交进去，即使后来删掉，历史记录里仍然留着。这是最常见的事故。

看看现在改了什么

现在哪些文件改过了？

保存当前进度（打存档）

把现在的状态保存一下，说明写「完成第一轮编码」。

这是 commit。这是最常用的一个动作。

什么时候该存档？每完成一个有意义的小节就存一次。 存档太少的唯一后果，是出事时只能退回到很早以前。

刚才改的不要了

我刚才的改动都不要了，回到上次保存的样子。

⚠️ 这个动作会丢弃未保存的改动，不可恢复。所以上面第三条原则很重要。

看看以前做过什么

列一下这个项目的修改历史。

开个分线试新东西

开一个新分支叫 test-framework，我想试一套新的编码框架，不影响现在的。

这是 Git 最被低估的能力。 你可以放心试一个激进的方案，试砸了直接扔掉这条分线，主线毫发无损。

对研究工作的典型场景：客户要求换一套分析框架，但你不确定新的更好。开分支跑一遍，两个版本并排比较。

切回主线 / 切换分支

切回主分支。

半成品先收起来

我手头这些改到一半的先收起来，我要去处理另一件急事。

这是 stash。适合「做到一半被打断」的情况——把工作台清空，之后再原样取回来。

合并回主线

把 test-framework 分支的工作合并回主分支。

回到某个旧版本

回到「完成第一轮编码」那次保存的状态。

---

和 GitHub 联通

只有在需要多台电脑同步或多人协作时才需要这部分。单机工作用不上。

⚠️ 发布到 GitHub 前务必确认是私有仓库。 含客户数据的项目不应该放到任何云端代码仓库——即使是私有的。研究行业的合同通常对此有明确约束。

遇到冲突

有冲突了，帮我看看是哪些文件、两边分别改了什么，我来决定保留哪个。

冲突就是「你和别人改了同一行」。它不是错误，是 Git 在说「这里我不敢替你做主」。决定权应该在你，别让它自动选。

---

四条心法

一、存档要勤。 一次有意义的进展就存一次。存档不花钱，回不去才花钱。

二、说明要写人话。 「更新」这种说明等于没写。三个月后你要靠它找回某个版本。

三、危险动作先问。 凡是涉及丢弃、覆盖、强制推送的，让它先说清楚影响范围。

四、敏感数据永远不进版本库。 客户数据、账号密码、含个人信息的原始记录——一旦提交进历史就很难彻底清除。宁可一开始就用 .gitignore 排除掉。

---

最小可用组合

如果你只想记三句话：

1.「把这个文件夹用 Git 管起来。」（开始之前）

2.「保存一下，说明写……」（每完成一段）

3.「回到上次保存的样子。」（出事之后）

这三句覆盖了 90% 的日常需要。剩下的等真的遇到了再说——反正你也不用记命令。