提到 Git，很多人首先想到代码、命令行和复杂的团队协作。其实它最核心的能力很朴素：记录一组文件在不同时刻的状态。文章恰好也是不断修改的文件，因此，即使完全不写代码，也可以把 Git 当成个人写作的“时间轴”。
我平时用 Markdown 写文章，每篇文章就是一个普通的文本文件。建立 Git 仓库以后，写完一段、调整结构或准备发布时，都可以保存一次有说明的版本。它不会替我写作，却能减少“改坏了怎么办”的顾虑。
版本不是无数个副本
不用 Git 时，人们常把文件命名为“最终版”“最终版2”“真的最终版”。时间一长，很难知道哪个版本改了什么。Git 会比较前后差异，只记录文件发生的变化，并保留完整历史。需要时，可以查看某一句是什么时候加入的，也可以比较两次修改之间删掉了哪些段落。
这种版本管理并不要求频繁操作。对个人写作来说，在完成初稿、完成事实核对、正式发布前各保存一次，通常已经足够。重点不是记录每次敲键盘，而是留下几个有意义的阶段。
提交信息写给未来的自己
Git 把一次版本记录称为“提交”。提交时附上一句简短说明，例如“完成全文初稿”“补充本地备份案例”或“发布前修正错别字”。几个月后回看，这些说明会比日期更容易唤起记忆。
提交不必追求专业格式，也不用把所有改动塞进一次记录。如果今天既重写了开头，又整理了三篇旧文，可以分开提交。一次提交围绕一个明确目的，日后查找和恢复都会更轻松。
分支可以用，但不必复杂
分支适合尝试尚未确定的改法。比如一篇文章已经可以发布，但我还想试试完全不同的结构，就可以创建一个临时分支，在里面大胆删改；效果满意再合并，不满意则放弃这个分支，原稿不会受影响。
不过，个人写作完全没必要照搬大型软件项目的流程。大多数时候只使用一个主分支就够了。只有重写长文、尝试新栏目或批量改版时，再引入临时分支。工具应该降低心理负担，而不是制造新的仪式。
误删以后，先停下来查看历史
Git 很实用的一点是恢复误删。只要文件或段落曾经提交过，就能从历史版本中找回来。发现问题后，先不要连续保存或随意覆盖，可以查看文件记录，确认最后一个正常版本，再恢复整篇文件或复制其中一段。
但 Git 不是万能撤销键：从未提交过的草稿，Git 通常无法恢复；如果仓库所在硬盘损坏，本地历史也可能一起丢失。因此，“已经提交”解决的是版本问题，不等于完成了可靠备份。
同步和备份是两件事
把仓库推送到 GitHub、Gitee 或自建 Git 服务，可以在多台设备之间同步，也能增加一份异地副本。不过同步会忠实传播修改，包括误删和错误操作；平台账号也可能遇到权限、服务或安全问题。它不能替代完整的备份方案。
更稳妥的做法是把 Git、远程仓库和定期备份组合起来：Git 管理修改历史，远程仓库负责同步，移动硬盘或可信的备份服务保存独立副本。包含私人日记、未公开资料时，还要把仓库设为私有，并谨慎检查上传内容。
一个简单的 Markdown 工作流已经够用：新建文章，写完一个阶段后查看改动，提交并写清说明，需要跨设备时再推送到远程。发布网站时，用构建工具把 Markdown 生成静态页面。这样，内容始终是容易迁移的纯文本，版本记录也不会被某个写作软件锁住。
Git 的学习门槛主要来自陌生名词，而不是写作场景本身。先掌握“查看状态、提交版本、查看历史、同步远程”这几件事，就能得到大部分好处。等真正遇到重写或恢复需求，再学习分支和回退，也完全来得及。