Git 创作者指南 — 写作人的版本控制

一

动机

你的写作值得一个更好的家

2019 年，一位作家差点失去她一生的心血——唯一的手稿副本保存在一个 U 盘里。那个 U 盘丢了。

这个故事触目惊心，但它并不罕见。我们大多数人的写作都以某种脆弱的方式存在着：一个 Google Doc、一个 Notion 页面、一个 Dropbox 文件夹里名字越来越长的文件——定稿_v3_最终版_真的最终.docx。

"那个 U 盘消失了，一部小说也随之消失。这不仅仅是备份问题——这是关于我们如何对待自己工作的根本态度问题。"

— Theena Kumaragurunathan，《Git 不只是给开发者的》

软件工程师早就解决了这个问题。他们用 Git——一种版本控制系统。它记录每一次变化，允许你随时回到任何一个过去的时刻，让协作变得有序而非混乱。

问题是：没有人告诉写内容创作者们 Git 也适合他们。

你现在的痛点，Git 都能解决

❌ 现在的问题

• 文件名混乱，无法判断哪个是最新版
• 删掉一段后悔了，但找不回来
• 与编辑协作时版本冲突
• 作品存放于第三方平台，受平台规则限制
• 无法追踪"这段是什么时候写的，为什么这么改"

✅ Git 之后

• 永远只有一个文件，历史清晰可查
• 任何修改都可以回退，删除不再是永久的
• 多人协作有序，改动有迹可循
• 文件存在你控制的地方
• 每次提交都记录了你的思考过程

二

理解

Git 是什么？用写作者的语言来说

Git 是一个版本控制系统。它的工作很简单：追踪你的文件随时间发生的每一次变化，让你能随时回到任意一个过去的时刻。

类比理解

想象你的手稿是一条河流。Google Docs 的"版本历史"就像在河边偶尔拍了几张照片——有的，但没有规律。Git 则像在河里每隔一段距离设置了一个精确的坐标点，每个点都有标注："这里，2024年3月12日，我重写了第三章的结尾，因为觉得太仓促。"你不仅可以看照片，还可以把时间倒流回任意一个坐标。

Git 和 GitHub 是一回事吗？

很多人混淆这两个词，但它们不同：

Git 版本控制工具

安装在你电脑上的软件，负责追踪文件变化、管理创作历史。一个功能极其强大的本地"版本历史"，可以随时回溯到任何一个过去的时刻。

GitHub / Gitea / Codeberg 云端存储平台

在线服务，用来存储和分享你的 Git 仓库。GitHub 最出名，但不是唯一选择。如同云盘之于本地文件——你的文件在那里，但本地也有一份。

关键认知

Git 不要求你懂编程。它只是一套管理文件变化的规则。你的文章、章节、笔记——只要是纯文本文件，Git 就能完美追踪。

三

词汇表

六个核心概念，用创作者语言解释

Git 有自己的专业词汇。以下是写作者需要理解的六个最重要的概念，全部用写作的语言来解释。

repository（仓库）你的写作项目

一个包含你所有文件及其完整历史的文件夹。你的一本小说可以是一个仓库，你的博客文章集也可以是一个仓库。

commit（提交）一个时间存档点

就像游戏里的"存档"。每次你对写作做了一些有意义的改动，就创建一个提交，并写一句话描述你做了什么。"重写了第二章的开场白" 就是一个好的提交说明。

branch（分支）平行草稿

允许你在不影响"正式稿"的情况下，另开一条线索尝试全新的方向。比如："如果用第一人称写第三章会怎样？"创建一个分支来试验，满意了再合并，不满意就丢弃。

merge（合并）整合修改

将一个分支上的改动整合到主稿中。就像把编辑返回的修订意见应用到你的原稿里。

clone（克隆）完整复制一份

将一个仓库（包括全部历史）复制到你的本地电脑。就像从云端下载你的完整写作档案，可以在新电脑上接着写。

push / pull（推送/拉取）同步到云端/从云端更新

Push：把本地最新的改动上传到 GitHub。Pull：从 GitHub 下载别人（或你自己在另一台设备上）做的最新改动。

四

实操

从零开始：你的第一个写作仓库

以下步骤假设你是全新的开始。我们会先用命令行建立基础，然后在下一节介绍图形界面工具（鼠标点击，无需命令行）。

写在前面：命令行看起来吓人，但你只需要记住五到六条命令。如果你更喜欢图形界面，完全可以跳过这一节，直接去看"图形界面工具"部分。

1

安装 Git

访问 git-scm.com，下载适合你系统（Windows / macOS / Linux）的安装包，按提示安装即可。macOS 用户也可以通过 Homebrew 安装：

            TERMINAL
            brew install git
          

2

告诉 Git 你是谁

只需要做一次。Git 需要知道你的名字和邮箱，这些信息会出现在每次提交记录里：

            TERMINAL
            git config --global user.name "你的名字"

            git config --global user.email "你的邮箱@example.com"
          

3

为你的项目创建仓库

进入你的写作文件夹，然后初始化一个 Git 仓库：

            TERMINAL
            cd ~/Documents/我的小说

            git init

            # 此文件夹现在被 Git 管理了

4

做你的第一次提交

把所有现有文件加入追踪，并创建第一个存档点：

            TERMINAL
            git add .

            # "." 表示添加当前文件夹里的所有文件

            git commit -m "初始提交：项目开始"

            # 引号里是你对这次改动的描述

恭喜，你的第一个存档点创建成功了。

5

连接到 GitHub（可选，但推荐）

在 github.com 注册账号，创建一个新的仓库，然后将本地项目连接上去：

            TERMINAL
            git remote add origin https://github.com/你的用户名/你的仓库名.git

            git push -u origin main

            # 此后你的写作就有了云端备份

五

节奏

写作者的日常 Git 工作流

掌握 Git 之后，你的日常写作节奏只需要三个动作：写作 → 提交 → 同步。

写作在你喜欢的编辑器里

→

git add .暂存改动

→

git commit -m "..."记录存档

→

git push上传到云端

什么时候该提交？

没有严格规定，但以下是一些好的触发时机：

• 完成了一个完整的章节或段落
• 做了一次大的结构调整
• 删除了一段文字（提交后删除不再是永久的）
• 今天的写作结束，准备关电脑
• 在尝试一个新方向之前（先提交，再实验）

如何写好提交说明？

❌ 不好的提交说明

          git commit -m "更新"

          git commit -m "修改了一些东西"

          git commit -m "asdfjkl"

✅ 好的提交说明

          git commit -m "第三章：重写了主角出场场景"

          git commit -m "删去了2000字的支线，暂存备用"

          git commit -m "调整了第一章时间线，修正逻辑漏洞"

如何查看历史记录？

      TERMINAL
      git log --oneline

      # 简洁地显示所有提交历史
    

如何回到过去某个版本？

      TERMINAL
      git log --oneline

      # 找到你想回去的那个提交，复制它的 ID（例如 a3f9c12）

      git checkout a3f9c12 -- 第三章.md

      # 这会将"第三章.md"恢复到那个版本，其他文件不受影响

六

工具推荐

不用命令行？这些图形工具为你准备

命令行不是使用 Git 的唯一方式。以下这些图形界面工具让你用鼠标就能完成所有操作，对写作者尤其友好：

🖥️ GitHub Desktop 免费 · Windows / macOS · 官方出品

GitHub 官方出品，界面简洁直观。提交、推送、拉取、查看历史，全部鼠标操作。最推荐的入门工具。

🦊 GitKraken 免费/付费 · 全平台

可视化展示分支树状图，让"平行草稿"的概念一目了然。适合喜欢视觉化管理的创作者。

📝 VS Code + Git 插件免费 · 全平台

如果你用 VS Code 写作，它内置了 Git 界面。写完直接在编辑器里提交，无需切换应用。

🌊 Sourcetree 免费 · Windows / macOS

Atlassian 出品，功能强大，适合想要更多控制权的创作者。可视化提交树和分支管理清晰易懂。

🌿 Obsidian Git 插件免费 · Obsidian 用户专属

如果你用 Obsidian 做笔记和写作，这个插件可以让你的整个 Vault 自动由 Git 管理，完全无感。

✍️ Typora / Zettlr 所见即所得 Markdown 编辑器

这些编辑器将 Markdown 文件渲染得像 Word 文档一样漂亮，同时保持纯文本底层，与 Git 完美配合。

七

纯文本写作

为什么要用纯文本？Markdown 速成

"纯文本是最不性感、也最重要的数字基础设施。选择用纯文本写作，是一个关于记忆与权力的政治选择，不仅仅是文件格式的偏好。"

— Theena Kumaragurunathan

Git 可以追踪任何文件，但它对纯文本文件（.txt, .md）的追踪效果最完美——它可以精确显示哪一行哪个字被改了。对于 .docx 这类二进制格式，Git 只能说"这个文件变了"，而无法告诉你具体改了什么。

Markdown：写作者的最佳选择

Markdown 是一种极简的纯文本格式语法。你用普通符号标注格式，写作时不会被排版打断，导出时可以变成 Word、PDF、网页等任意格式。

你这样写（纯文本）

          # 第一章：归途

          这是一个**关于回家**的故事。

          他走在*熟悉又陌生*的街道上。

          > 有些地方，你离开了就再也回不去了。

          ---

渲染后看起来是这样

第一章：归途

这是一个关于回家的故事。

他走在熟悉又陌生的街道上。

有些地方，你离开了就再也回不去了。

与编辑、合著者协作

Git 真正改变游戏规则的场景是协作写作。告别"请看附件_最终稿_修改版(3).docx"这种噩梦。

基本协作流程

1

作者将仓库分享给编辑

在 GitHub 上将编辑添加为协作者，或者给他们仓库的链接（如果是公开仓库）。编辑用 git clone 下载完整项目到本地。

2

编辑在自己的分支上工作

编辑创建一个新分支，在上面做修改，不会影响作者的主稿：

git checkout -b 编辑-李明-第一章修订

3

提交修改，发起 Pull Request

编辑完成修改后，在 GitHub 上发起一个 Pull Request（PR）——本质上是在说："我做了这些修改，请作者审阅是否接受。"

4

作者审阅并决定是否合并

作者可以逐行查看每处改动，留下评论，接受或拒绝特定修改，最终决定是否将编辑的修改合并到主稿中。