DevLog

一、Git 最重要的能力，是管理版本

翻译成大白话，Git 做的事情很简单：

记住每次修改——每次改动都有记录
比较前后差异——哪里删了、哪里加了，一目了然
随时回到旧版本——不用翻文件名猜
让我们敢放心去试另一种写法——改坏了可以回来

这套能力能管代码，但绝不只限于代码。

一份资料只要需要反复修改、需要应对外部反馈、怕改坏、还想回头看旧版本，就已经很适合接入 Git。长文章、读书笔记、小说草稿、项目方案，全都是最典型的例子。

二、为什么长篇写作更需要版本管理

长篇写作的过程，天然就是一条版本管理工作流。

不管是写长文还是写论文，过程其实很像：都会经历反复修改、分阶段推进、应对编辑或导师的多轮反馈。中间更是少不了整段重写、结构重排和观点推翻。写着写着，经常会突然想看一眼：我上个月到底删了什么？

如果全靠"另存为"来应对这些变化，最后都会变成一个样子：

文件名越来越长
搞不清哪份才是当前版本
想恢复旧写法时只能人工翻
想放开手脚重写一段，又怕把原稿弄坏

接入 Git 之后，最大的变化就是终于敢改了。再也不需要在"继续改"和"保留原稿"之间做单选题。

三、Git 核心概念：三个区域

Git 把代码管理分成三个区域，理解它们的关系是掌握 Git 的关键。

1. 工作区（Working Directory）

正在写代码（或文章）的地方，就是工作区。打开编辑器，创建文件、修改内容，这些都发生在工作区。

2. 暂存区（Staging Area）

准备提交的修改，会先放到暂存区。为什么要有暂存区？因为可能同时改了很多文件，但只想把其中一部分存档。

3. 本地仓库（Local Repository）

正式提交后，内容就进入本地仓库，成为历史记录。每次 commit 都是一个检查点，可以随时回退。

三区流转：

工作区 ──git add──▶ 暂存区 ──git commit──▶ 本地仓库

在工作区修改文件
用 git add 把修改放进暂存区
用 git commit 正式存档到本地仓库

这个流程理解了，Git 就掌握了一半。

四、安装与配置

1. 安装 Git

Windows： 访问 git-scm.com，下载安装包，一路 Next 即可。安装完成后右键桌面选择「Git Bash Here」。

macOS：

brew install git

Linux（Ubuntu/Debian）：

sudo apt update && sudo apt install git

验证安装：

git --version

看到版本号（如 git version 2.x.x）即安装成功。

2. 配置用户信息

每次存档都会记录"是谁存的"，安装完第一件事就是配置身份：

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

查看配置：

git config --list

--global 表示全局配置，对本机所有项目生效。如果某个项目需要用不同的身份，可以在项目目录下去掉 --global 单独配置。

五、写作项目的完整工作流

1. 建立项目目录

一个够用的写作项目目录大概长这样：

writing-project/
  outline.md          ← 大纲
  chapter-01.md       ← 章节草稿
  chapter-02.md
  notes.md            ← 研究笔记
  feedback.md         ← 反馈记录
  references.bib      ← 引用条目

如果走 Typora 或 LaTeX：

writing-project/
  document.typ
  chapters/
    chapter-01.typ
    chapter-02.typ
  notes.md
  feedback.md
  references.bib

2. 初始化仓库

cd writing-project
git init
git branch -M main
git add .
git commit -m "初始化目录和大纲"

做完这步，就已经告别了"最终版-v3"的混乱。

3. 日常提交节奏

后面每次写到一个值得留档的节点，再提交一次就行：

git add chapter-02.md
git commit -m "补完第二章初稿"

收到新一轮意见，再提交一次：

git add chapter-02.md feedback.md
git commit -m "根据反馈重写第二章结构"

提交节奏的原则： 完成一个小功能就提交一次，不要攒一大堆修改再提交。就像游戏里打完一个 Boss 就存档，而不是通关了才存。

4. 提交信息怎么写

好的提交信息应该简洁明了，能让一个月后的自己看懂：

✅ 初始化目录和大纲
✅ 根据反馈重写第二章结构
✅ 补充第三章案例和引用
✅ 整理修改意见记录

不好的提交信息：

❌ 修改
❌ update
❌ fix

六、常用操作速查

查看状态

git status

告诉你哪些文件被修改了、哪些在暂存区、哪些还没被追踪。

查看历史

git log --oneline

简化输出，只显示一行提交记录：

c3d4e5f 添加首页文件
b2c3d4e 添加项目描述和功能列表
a1b2c3d 初始化项目，添加 README

查看具体改了什么

git diff

这是长篇写作中最值钱的命令之一——它会直接告诉我们：

哪一段删掉了
哪一段新增了
哪一处措辞变了

一次添加多个文件

git add file1.md file2.md file3.md
# 或者添加当前目录下所有修改
git add .

七、分支：大胆修改的安全网

长篇写作最需要 Git 的时刻，往往出现在反馈回来之后。

假设某一章节被提了 6 条修改意见，原来的做法通常是：新建一个"第二章修改版"，大改一轮，觉得改得不对再复制一个"第二章修改版2"，过几天已经不知道哪版删掉了什么。

接入 Git 之后，可以用分支来解决：

git switch -c chapter2-rewrite

这相当于单独开了一个实验版本。重写成功就把结果留下，重写失败也不会影响原来的版本。

分支的典型使用场景：

想大刀阔斧重写某一章，但不确定效果
想尝试不同的论证思路
想保留原版的同时测试新的结构安排

实验完成后，如果满意就合并回主线：

git switch main
git merge chapter2-rewrite

如果不满意，直接删掉分支即可，主线丝毫不受影响：

git branch -D chapter2-rewrite

这就是 Git 在写作场景里最值钱的地方：让"大胆修改"和"保留原稿"同时成立。

八、多人协作与远程仓库

如果是一个团队共同写作（比如小组报告、合著论文），可以把仓库推到 GitHub 或 GitLab 上：

1. 创建远程仓库

在 GitHub 上新建一个仓库，然后关联：

git remote add origin https://github.com/你的用户名/仓库名.git
git push -u origin main

2. 拉取他人修改

git pull origin main

3. 解决合并冲突

当两个人改了同一段内容，Git 会提示冲突。冲突标记长这样：

<<<<<<< HEAD
你的修改
=======
别人的修改
>>>>>>> commit-id

手动选择保留哪部分（或两者都保留），删掉标记符号，然后重新提交：

git add 冲突文件
git commit -m "解决合并冲突"

九、.gitignore：告诉 Git 哪些文件不用管

在写作项目中，有些文件不需要纳入版本管理，比如临时文件、系统生成的缓存等。在项目根目录创建一个 .gitignore 文件：

# 系统文件
.DS_Store
Thumbs.db

# 编辑器临时文件
*.swp
*.swo
*~

# 编译产物（LaTeX/Typst）
*.aux
*.log
*.pdf
out/

# Word 临时文件
~$*.docx

十、如果最后只收 Word，还能用 Git 吗

很多人会想：如果最后只能交 docx，那前面这套做法还有意义吗？

当然有，而且意义很大。因为值得纳入 Git 的，往往不只是一份最终交稿文件，还包括：

用 Markdown 写的大纲和章节草稿
用 feedback.md 整理的反馈记录
用 references.bib 整理的参考资料
为了最终交付 docx 而提前积累的整套中间资料

把 Markdown 转换成 Word 早就不是难题。用 Typora、Obsidian 这类写作软件导出，基本都是点一下鼠标的事：

pandoc chapter-01.md -o chapter-01.docx

很多时候，只要把大纲、反馈记录和章节草稿用 Git 管起来，返工的痛苦就已经能明显减轻。

十一、GUI 工具推荐

如果暂时不想碰命令行，这些图形界面工具也完全可以：

工具	平台	特点
GitHub Desktop	Windows / macOS	官方出品，界面简洁，最适合新手
VS Code 内置 Git	全平台	编辑器内直接操作，写文章时最方便
Sourcetree	Windows / macOS	功能丰富，可视化分支图很直观
TortoiseGit	Windows	右键菜单集成，操作最无感

更重要的是，现在有了 AI，不会敲命令早就不是借口了。可以唤起 Claude Code 这类终端 AI 助手，直接说"帮我把现在的改动存一次档"，AI 就会直接把对应的 Git 命令跑完。

十二、适用场景总结

如果今天就想开始，先别做太复杂。最小的一步，是把当前正在写的东西放进同一个文件夹里，然后把三类文件留下来：

正文和章节草稿，比如 outline.md、chapter-01.md
修改意见和反馈记录，比如 feedback.md
参考资料和引用线索，比如 notes.md、references.bib

每完成一个明确节点，就提交一次。提交说明不用写得很高级，能让一个月后的自己看懂就行。

只要一份资料具备这几个特征，它就值得用版本管理系统保护起来：

会反复修改
会经历多轮反馈
会担心改坏
会需要回看旧版本

适用的例子包括：长文章、专栏草稿、研究笔记、课程讲义、项目方案、Prompt 模板、AI Agent 配置文件……

Git 根本不是什么纯粹的"代码工具"，它更像一个长期文本资产的版本管理系统。

记住这四件事就够了：

Git = 存档系统，commit 就是打检查点

三个区域：工作区 → 暂存区 → 本地仓库

基础流程：git add 选择要存档的内容，git commit 正式存档

查看状态：git status 看当前状态，git log 看历史记录

真正省下来的，不只是时间，还有敢改的胆量。就从一篇文章、一份笔记或者一篇论文开始——只要有一份会反复修改的文本资产，就已经值得把 Git 变成自己的工具。

Git版本控制系统