个人开发必备Git流程：从配置到回滚的完整实践

很早以前我也觉得，git是团队协作才需要的东西，一个人写代码哪用那么讲究。直到自己手里同时维护三四个项目，电脑换了一台又一台，某天想回退一个功能改动却找不到历史节点，才意识到个人开发如果没有一套顺手的git流程，本质上就是在裸奔。项目越往后写，配置、文档、脚本越来越多，改坏一个地方可能半天都找不回来。

这篇东西不是git命令大全，而是我在个人开发场景里沉淀下来的一整套使用习惯。包含git安装与初始化配置、SSH免密登录、日常提交的核心命令流、分支合并策略，以及IDE集成时那些奇怪参数的真实含义。适合正在从“会用几个git命令”走向“能稳定管理自己代码”的开发者，也适合被每次push都要输密码、提交信息乱写、误操作不知道怎么回滚这些事烦过的人。内容按实操顺序组织，照着走一遍就能把个人开发环境理顺。

1. 个人开发流程先想清楚三件事

很多教程上来就铺分支模型、多人协作规范、code review流程，对个人开发者来说反而制造焦虑。一个人开发，没有同事帮你review代码，没有CI帮你跑测试，所有错误都只能自己兜住，所以流程设计的核心逻辑不是“管控”，而是“能后悔、能定位、能恢复”。

1.1 单兵作战最常见的三个误区

个人项目最常见的做法是：git init完事，代码写一大坨一次性commit，commit message写“更新”或者“修改”，所有改动全堆在master/main分支上，从不打tag。短期看没问题，等代码量过万行之后，问题就暴露了。

第一个问题是没法精准回滚。一次提交里混着新功能、bug修复、配置文件调整，某天线上出问题需要回退某一项改动时，根本无从下手，因为commit已经被打包得乱七八糟。

第二个问题是没法定位问题引入时间。用git bisect定位回归bug时，如果每个commit都是几百行代码的巨无霸，每次二分都要在大量代码里人工分辨，效率极低。

第三个问题是换设备后环境不一致。换台电脑想继续开发，发现之前的用户信息是别人的、换行符处理乱套、每次拉取推送都要输密码，这些都是没有系统配置过git的典型症状。

1.2 个人流程只需要守住四条原则

不需要把团队协作的那套完整搬过来，个人开发只要做到四点就足够：

• 每次提交只做一件事，改动范围尽量收窄，哪怕一个功能拆成多个commit也值得。
• 提交信息能说明白改动原因，半小时后你看到它还能想起来当时在干嘛。
• 关键节点打上tag，release一个版本就记录一次，方便随时回到稳定点。
• 所有“误操作”都有后悔药，reflog、stash、reset这几个技能必须熟练。

这篇文章后面的所有内容，都是围绕这四条原则展开的。安装配置是地基，SSH免密解决的是体验问题，日常命令流程是核心动作，分支和回滚则是安全兜底。

2. Git安装与初始化配置：先把工具底座搭稳

个人开发流程里最容易被忽略的是初始配置。很多人装完git就开始commit，根本不管user.name、user.email、换行符属性这些基础配置，结果提交历史里出现别人的名字，或者项目在Windows和Mac之间来回切换时出现成片的换行符diff，这些都是可避免的。

2.1 Windows环境安装与Git Bash的选择

如果主力环境是Windows，安装git时建议直接到官网下载安装包，一路默认选项即可。安装完成后，系统里会出现Git Bash和Git CMD两个入口，日常操作优先使用Git Bash。

Git Bash的本质是一个模拟Unix终端的环境，提供ls、grep、sed这些Linux命令，和真实Linux终端里的操作手感几乎一致。个人开发中大部分时间需要在终端里看状态、查日志、处理冲突，Git Bash下写的命令以后切到macOS或Linux服务器时可以直接复用，不需要重新记忆一套Windows风格的东西。

安装完成后第一步验证版本，在Git Bash里执行：

bash复制git --version

能正常输出版本号，说明安装成功。如果cmd里也想直接使用git命令，需要把git的bin目录手动加到系统PATH环境变量里，但个人使用场景下，固定在Git Bash里操作就够了，不太建议去折腾这个。

2.2 第一次安装后必配的五个参数

刚安装完的git是一张白纸，不配置也能用，但会埋下一堆坑。以下五组配置建议逐条执行，它们分别解决不同的问题。

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
git config --global init.defaultBranch main
git config --global pull.rebase true
git config --global core.autocrlf input

user.name和user.email会写入每一次commit记录里，这是提交历史的“身份证”，一定要设置成真实可识别的信息，方便日后追溯。

init.defaultBranch设成main是为了避免新建项目默认生成master分支。现在主流托管平台默认分支名基本都是main，提前统一格式能少很多认知负担。

pull.rebase true解决的是拉取代码时的合并方式问题。默认情况下git pull执行的是merge操作，会在历史里产生多余的合并提交；设为rebase后，本地提交会“搬到”远程最新提交的顶端，历史是一条干净的直线，对个人项目的代码审查和回溯更友好。

core.autocrlf建议直接设成input。这个参数控制git如何处理换行符。Windows下文件默认用CRLF（回车换行）结尾，Linux/macOS用LF（换行）结尾。如果设置成true，git在提交时会把CRLF转成LF，检出时再转回CRLF，这容易造成一种情况：项目里同一行代码，在一个平台上显示有改动、另一个平台显示没改动。设成input后，git只在提交时把CRLF转换成LF入库，检出时不转换，能最大程度减少换行符引起的假diff。

注意：core.autocrlf只对改动过的文件生效，不会自动修复历史文件。如果项目中已经存在大面积的换行符差异，需要一次性规范化处理，不要指望改完配置世界就清净了。

2.3 Git Bash中文乱码和显示优化的处理思路

Git Bash在中文环境下有两个典型问题。一个是git status和git log显示中文文件名或提交信息时乱码，另一个是终端里手动输入中文commit message显示乱码。前者和core.quotepath有关，后者涉及bash的local