面向非技术用户的 Git 基础

上一节留了一个结论：它用命令删掉的文件，回退救不回来。

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

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

Git 是什么

给文件夹装的时光机。

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

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

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

三条说话原则

① 说目的，不说命令

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

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

② 说清楚背景

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

③ 危险动作先让它确认

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

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

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

日常够用的九件事

让一个文件夹开始被管理

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

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

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

告诉它哪些文件不用管

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

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

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

看看现在改了什么

现在哪些文件改过了？

保存当前进度

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

这是最常用的一个动作。 什么时候该存？每完成一个有意义的小节就存一次。

存档太少的唯一后果，是出事时只能退回到很早以前。

刚才改的不要了

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

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

看看以前做过什么

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

开个分线试新东西

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

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

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

半成品先收起来

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

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

回到某个旧版本

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

和 GitHub 联通

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

⚠️ 发布到 GitHub 前务必确认是私有仓库。

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

遇到冲突

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

冲突就是「你和别人改了同一行」。它不是错误，是 Git 在说「这里我不敢替你做主」。

决定权应该在你，别让它自动选。

为什么这一节放在这里

回到开头那个问题。第 04 章讲的检查点回退有五条限制，其中三条都指向同一个结论：

Git 覆盖的正是回退救不了的那部分。

官方自己的说法是：把检查点当成本地撤销，把 Git 当成永久历史。

四条心法

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

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

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

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

最小可用组合

只想记三句话的话：

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

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

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

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

本节为 HiBridge 整理的工作方法，非官方文档内容。 其中关于检查点覆盖范围的部分依据官方 Checkpointing，查证日期 2026-08-05。