个人项目Git流程：轻量分支管理、提交规范与reflog恢复指南

1. 我给个人项目重新定 Git 流程的起因

1.1 一次误删分支让我开始反思

在讲具体流程之前，我想先说一件真实的小事故。

去年年中，我在家里电脑上整理一个写了快两年的个人博客项目。当时觉得某个功能分支已经没用了，准备清理掉，结果手一抖敲错了分支名，把一个还没合回主线、存着三天改动成果的分支直接删了。我当时的第一个反应是“完蛋了”，第二个反应是去翻 .git 目录下的 reflog 碰碰运气。好在那三天里我每天至少提交一次，最终用 git reflog 把丢掉的引用找回来，分支内容毫发无损。

这件事给我的触动很大。我原本以为一个人写项目，不需要什么流程，反正代码都在本地，能跑就行。但那次之后我意识到：个人开发不代表没有风险，也不代表不需要恢复手段。真正缺的只是适合个人的轻量流程。

从那以后我开始系统性地整理自己用 Git 的方式，从分支命名、提交规范、合并策略到远程推送节奏，逐步形成了一套不太折腾但很实用的流程。这篇文章就是想把这些实践完整地分享出来。

1.2 个人流程和团队流程的本质差异

我在公司里参与过团队项目的 Git 管理，也帮别人搭过仓库，实际情况是：很多人把团队里那套流程硬搬到个人项目上，结果要么难受无比，要么干脆放弃维护。

团队流程和个人流程的本质差异在哪？我用一句话概括：团队流程的核心是“多人协作的秩序”，个人流程的核心是“单人恢复的便利”。 前者往往需要严格的分支权限、Code Review 约定、合并门禁、规范化的 CI 检查；后者根本不需要这些，个人项目里的每一个提交、每一次合并，最终服务对象只有你自己，所以原则应该是“少操作、快恢复、可回溯”。

举个最简单的例子。团队项目里 master 分支往往受保护，不允许直接 push，个人项目不需要，只要你愿意，直接在 master 上提交也没人拦你。但“可以”不等于“应该”。当你把这一条升级成“master 永远保持可以发布的干净状态”，后续的一切都会变得从容。

1.3 这套流程的目标：省事、可追溯、不焦虑

我在设计个人 Git 流程时没有贪多，只定了三个目标。

第一个是省事。我不希望每提交一次代码都要想半天“下一步执行什么命令”，所以流程必须贴近直觉，常用操作最好一条命令能搞定。第二个是可追溯。不管是一个月前改过的一行配置，还是某个功能在哪一天有了第一次可用版本，都能通过 Git 历史快速查清楚。第三个是不焦虑。哪怕误删分支、误重置文件、误提交了大量不该提交的内容，我知道怎么恢复，不会慌。

后续所有内容都是围绕这三个目标展开的。如果看完你也能在你自己的项目里建立一个差不多的节奏，并且觉得“原来个人开发也可以这样清晰”，那这篇文章就没白写。

2. 基础准备：把 Git 环境一次性调顺手

2.1 安装和全局配置里最该认真对待的几项

如果你用的是 Windows，最简单的方式是去 Git 官网下载安装包，安装时一路默认即可。macOS 上通常自带了 Git，但版本可能偏旧，建议通过 Homebrew 安装最新版：brew install git。Linux 发行版里一般直接 sudo apt install git 或 sudo yum install git。

很多人装完 Git 就直接开始用，忽略了几个值得认真对待的全局配置。

第一个是 user.name 和 user.email。提交信息里会一直挂着这两个字段，将来查历史的时候如果看到“unknown”或者一串乱码邮箱，基本就是当时没配置干净导致的。我的建议是设置成自己常用的英文名和真实邮箱，并且保持所有设备一致，这样换电脑之后历史记录依然完整。

bash复制git config --global user.name "YourName"
git config --global user.email "you@example.com"

第二个是默认文本编辑器。有时候执行 git commit 或 git rebase 会弹出编辑器让你写信息，默认的 Vim 会让很多人懵住。我习惯设置为 VS Code：

bash复制git config --global core.editor "code --wait"

第三个是行尾符号处理。这一点很容易被忽略，但跨平台协作或者一个人多设备同步时，问题非常烦人。Windows 上的行尾默认是 CRLF，macOS/Linux 上是 LF，如果配置不当，每次打开文件都会看到大量“红色修改”。个人项目我推荐统一用 LF，提交时保留原样：

bash复制# Windows 上推荐
git config --global core.autocrlf false
git confi