Sky李晓峰1. 版本管理混乱的痛点与Git的核心思路
1.1 从一次“删了三天代码”的教训说起
先讲个真事。前几年我带一个小项目，组里有个同事做了一版界面重构，连续干了三天，临到下班准备提交代码时，觉得某个文件里有些调试代码不干净，就手动打开文件删删改改。改完一运行，整个页面白屏，仔细一看，误删了一段核心逻辑。更要命的是，这三天他没有做过任何一次版本提交，也没备份。最后我们花了一整晚，靠IDE的本地历史一点点翻找，才把那段代码捞回来。
做过开发的人大概率遇到过类似场景。这个问题的根源在于：多数人刚接触代码版本管理时，习惯用复制文件夹、改文件名带日期、存网盘这种“土办法”来保住自己的劳动成果。但这些方式在单机状态下勉强能用，一旦涉及多人协作、多分支开发、版本回退、代码审查，就完全力不从心。而Git这套分布式版本控制系统，解决的正是这一整类问题——它不但能帮你记录每一次修改，还能让你在任何时刻回退到任意一个历史版本，甚至让几十个人在同一个项目里各改各的而互不干扰。
这也是我决定写这篇文章的原因。网上关于git安装、git配置、git命令的教程非常多，但多数要么只讲了“怎么点下一步”，要么直接把命令列表甩出来让人背，看完还是不知道怎么在真实项目里用。我想从实际工作流的角度，把从零开始安装Git、完成基础配置、掌握核心命令再到处理常见坑的完整链路，讲清楚每一步背后的逻辑。
1.2 Git相比SVN与网盘备份，真正的优势在哪里
很多人第一次接触版本管理时，脑子里会冒出疑问：我以前用网盘备份文件，也有历史版本功能，为什么还要专门学Git？这个疑问很正常，但两者完全不是一个量级的东西。
网盘的历史版本，本质上是“文件快照”，它能帮你找回某个文件在某一天的状态，但做不到细粒度地回溯“某一行代码是什么时候、被谁、因为什么原因改掉的”。SVN这类集中式版本控制系统，倒是能做到版本回溯，但它有一个中心服务器的前提：你提交代码必须联网连接服务器，一旦服务器挂了或者你出差没网，提交和查看历史就成了问题。
Git最大的不同，在于“分布式”这三个字。每个开发者本地都有一个完整的仓库，包含全部历史记录。你不需要联网就能提交、查看日志、创建分支、甚至回退版本。等到有网络时，再把本地提交推送到远程仓库，实现同步。这个机制的额外好处是：任何人都不是单点依赖，远程仓库哪怕是彻底烧毁了，任意一个克隆过项目的人，都能用本地仓库把整个项目连同历史恢复出来。
一句话概括：Git不是“高级网盘”，而是搭在你自己机器上的一套完整代码时光机，顺便还集成了多人协作、分支管理、变更审查等一整套工作流工具。
1.3 三个核心区：工作区、暂存区、版本库
在正式开始安装之前，我建议先花三分钟理解Git的两个核心模型：三个区域和文件的四种状态。这个东西不搞明白，后面学命令会一直有一种“照猫画虎但不知道为什么”的漂浮感。
Git在本地操作时，涉及三个区域：
- 工作区：就是你电脑上肉眼可见的文件目录，你在编辑器里改代码，改的是工作区的内容。
- 暂存区：一个临时存放区域。你可以把若干文件的修改先放进去“排队”，但不急着真正落库。英文叫staging area，或者叫index。
- 版本库：Git真正保存历史版本的地方。每一次提交，本质上是把暂存区里的内容永久性地写入版本库，生成一个新的版本快照。
配合这三个区域，文件就有了四种状态：未跟踪、已修改、已暂存、已提交。比如你新建了一个文件，Git不认识它，它处于“未跟踪”状态；你把它加入暂存区，它就变成“已暂存”；你提交一次，它就变成“已提交”，此时工作区、暂存区和版本库三处内容一致；你再改几行代码，文件又变成“已修改”。
绝大多数高频命令，都是在推动文件在这三个区域之间流转：
git add：把工作区的修改放入暂存区git commit：把暂存区的内容固化到版本库git checkout/git restore：把版本库的内容覆盖回工作区git reset：撤销暂存，或者回退版本
理解了这套流转逻辑，后面遇到任何看起来复杂的命令组合，都能自己推理出它的用途。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Git安装全流程实操：从下载到环境验证
2.1 Windows平台安装：不要一路狂点“下一步”
先说最普遍的Windows平台。Git官网的下载页面，会根据你的系统自动推荐Windows版本，下载下来的基本是一个exe安装包。安装过程大部分时候确实可以一路下一步，但有几个关键选项，建议按自己的实际需求选，而不是默认到底。
第一个是安装路径。默认路径在C:\Program Files\Git，如果你不想让C盘越来越臃肿，可以在第一步就改成D盘或其他数据盘。这个改动完全不影响使用，只需要注意路径不要包含中文和空格，避免以后某些工具解析出错。
第二个是“选择默认编辑器”。Git在提交代码时，偶尔需要打开编辑器让你填写提交说明，默认用的是Vim。如果你不熟悉Vim，第一次在终端里被它“困住”时会一脸懵：怎么输入文字、怎么保存退出都不知道。所以我建议在安装时就把默认编辑器改成VS Code、Notepad++这类你平时就在用的图形化编辑器，省去以后为这点事折腾的时间。
第三个是PATH环境变量的那一项选择。这里务必选第二项“Git from the command line and also from 3rd-party software”，也就是把Git加入系统PATH。选这一项，意味着你可以在CMD、PowerShell以及任何终端工具里直接敲git命令。选第一项的话，只能在Git自带的Bash里用Git，太受限了；选第三项会把一堆Unix工具也塞进系统PATH，容易跟你已装的软件产生命令冲突，不推荐。
除此之外，还有一个容易被忽略的细节：换行符转换方式。安装向导会问“Checkout Windows-style, commit Unix-style line endings”还是别的选项。这个选项涉及跨平台协作时的换行符处理，建议保持默认（第一项），它的含义是：检出到Windows时自动转成CRLF换行，提交到仓库时自动转成LF换行，这样同一份代码在Windows和Linux上都能正常显示。
2.2 Mac与Linux安装方法一览
Mac上安装Git有两条路。一条是安装Xcode Command Line Tools，终端里运行xcode-select --install，系统会弹出提示框，确认后自动下载安装，装好的Git会被放置在/Library/Developer/CommandLineTools/usr/bin/git目录下。这条路的优点是省事，缺点是你拿到的版本可能不是最新的，而且下载速度时快时慢。
另一条是用Homebrew安装：brew install git。这种方式装的是最新版本，而且后续升级也方便，brew upgrade git一条命令搞定。如果你是经常需要跑前端、后端开发项目的开发者，我推荐用Homebrew的方式，因为版本新意味着新特性、性能优化和bug修复都跟得上。
Linux发行版的安装命令也都很直接：
- Ubuntu / Debian系列：
sudo apt install git - CentOS / RHEL系列：
sudo yum install git，或是sudo dnf install git - Arch Linux系列：
sudo pacman -S git
Linux安装一般不需要管编辑器路径之类的问题，因为默认环境就是终端，Vim对多数Linux用户来说是基本功。不过值得提醒的是，某些较老的发行版自带的Git版本可能比较旧，而Git的服务器端和客户端协议会逐渐淘汰老版本。如果你发现git clone一个托管平台上的仓库时报错，提示“server certificate verification failed”或“unknown key type”，先不要怀疑自己的操作，大概率是Git版本太老，建议先把Git升级到较新的版本再说。
2.3 安装完成后的环境验证
安装完Git，第一步不是急着配置，而是打开终端确认它真的被装好了。在终端里输入：
bash复制git --version
正常会输出类似git version 2.40.1.windows.1这样的一行信息。如果提示“command not found”，说明安装路径没有正确写入系统PATH，检查一下环境变量配置，或者重启一下终端再试。
接下来，再确认一下Git的安装路径。有时候你觉得自己用的是系统Git，但实际可能被其他软件捆绑的Git占了位置。执行：
bash复制which git
Windows上如果用的是Git Bash，也可以用where git。确认路径是预期位置后，就可以进入下一环节：初始化配置。
3. 提交前的关键配置：名字、邮箱、SSH与换行符
3.1 为什么要配置user.name和user.email
Git每一次提交，都会记录两条身份信息：作者（author）和提交者（committer），它们来自user.name和user.email这两个配置项。也就是说，如果不先设置它们，你压根没法成功提交代码，Git会报错并提示Please tell me who you are。
这个身份信息并不是用来做登录验证的，而是作为提交历史的一部分被永久记录下来。多人协作时，团队成员靠这些信息区分每一行代码是谁写的。所以我的建议是：user.name用你的真实姓名或常用的英文昵称，user.email用你能长期收到邮件的地址，最好和你的代码托管平台账号邮箱保持一致。这样在代码审查、提交记录追溯、自动化通知这些环节，都能把提交准确对应到具体的人，省去很多对不上号的麻烦。
设置命令非常直接：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
--global的意思是全局生效，也就是这台机器上所有仓库默认都用这个身份。如果你某一天只为某一个特定仓库设置不同的身份，可以不带--global，在那个仓库目录下单独执行一次即可。
3.2 配置检查与Git的配置优先级
设置完之后，建议检查一下配置是否生效：
bash复制git config --list
这条命令会把当前仓库能碰到的所有配置都列出来，包括系统的、全局的、仓库级的。你会发现配置是有层级之分的，从高到低依次是：系统级（/etc/gitconfig）、全局级（~/.gitconfig）、仓库级（.git/config）。后一层级的配置会覆盖前一层，也就是说，如果你在仓库级配置了一个不同的user.email，它会盖掉全局邮箱，只在这个仓库里生效。
很多新手开发踩过一个暗坑：自己明明在全局配置了正确的邮箱，结果打开某个项目的提交历史一看，有几笔提交的作者邮箱是错的或空的。原因基本有两种：一种是这个仓库是别人拷给你的，自带了一份.git/config，里面写了他自己的user信息；另一种是某些可视化工具在创建仓库时，自己生成了一组默认身份配置。遇到这种情况，先用git config --list --show-origin查一下当前配置来自哪个文件，直接定位到对应层级改掉就行。
3.3 SSH密钥配置：免输密码的关键
远程协作时，每次git push都要输入账号密码会非常烦人。解决方案有两个：HTTPS方式下使用凭据管理器记住密码，或者SSH方式下配置密钥配对。对于高频操作的开发者，我强烈建议走SSH这条路。
SSH的工作原理可以简化理解为：你生成一对密钥，一把私钥留在本地，一把公钥放到代码托管平台。平台验证你的身份时，用公钥来确认。整个过程不需要输密码，安全性也更高。
生成密钥的命令是：
bash复制ssh-keygen -t ed25519 -C "你的邮箱"
这里选择ed25519算法，是因为它比传统的RSA更安全、密钥更短、生成速度更快，目前主流平台都支持。执行过程中会让你确认保存路径和设置私钥密码，如果不想每次使用都输密码，直接一路回车就行。生成的公钥文件通常位于~/.ssh/id_ed25519.pub。
然后用cat命令把公钥内容打印出来，复制它，粘贴到代码托管平台（GitHub、GitLab、Gitee等）的SSH Keys设置页面里。测试是否配置成功：
bash复制ssh -T git@github.com
正常会返回一条欢迎信息，比如Hi username! You've successfully authenticated。看到这个，SSH配置就算完成了。
其实SSH并不是唯一的免密方案。如果你嫌管理密钥麻烦，也可以继续走HTTPS，配合官方凭据管理器，第一次输完账号密码，后续都能自动记住。两种方式都能用，但从安全性和跨平台稳定性角度，我还是更推荐SSH。
3.4 换行符与文件权限的跨平台设定
跨平台协作的另一个隐患是换行符。Windows用CRLF（回车+换行）表示行尾，Linux和Mac用LF（换行）。如果你不管它，就会出现这种情况：在Windows上提交的代码，到了Linux上每一行末尾多出一个^M，Git diff里满屏都是红绿差异，但实际上代码逻辑一行都没改。
前面安装Git时提到的那个换行符选项，实际上是在帮你自动转换。如果你安装时忘了改或者选错了，也可以用命令来微调。在Windows上，比较稳妥的全局配置是：
bash复制git config --global core.autocrlf true
而在Linux或Mac上，则建议设置成：
bash复制git config --global core.autocrlf input
意思分别是“检出时转成CRLF，提交时转成LF”和“检出时不转换，提交时转成LF”。这样一来，仓库里存的一律是LF，到了不同人的工作区，再根据平台特性自动调整。
还有一个Windows上容易踩的坑是文件权限变化。默认情况下，Windows会把文件权限记录下来，导致你改一个文件的执行权限，也变成一次提交变更。如果你不希望Git追踪权限变化，可以执行：
bash复制git config --global core.filemode false
这条对纯Windows开发环境非常友好，省去一堆无关紧要的diff噪音。
4. 高频Git命令的底层逻辑与正确用法
4.1 核心提交流程：add、commit、status与log
理解了三个区域的概念后，最基本的提交流程就非常清晰了。假设你在一个已经初始化好的仓库里新建了一个文件README.md，工作区里出现了这个文件，但Git还不知道它，它处于“未跟踪”状态。
第一步，用git status查看当前仓库状态。这条命令我建议随时用、随手用，它不是摆设，而是你了解仓库“正在发生什么”的最直接窗口。每次不知道该执行什么命令时，先跑一下git status，它会给你下一步的提示。
第二步，把文件加入暂存区：
bash复制git add README.md
如果想一次加入所有变更文件，可以用git add .。这里想提醒一下：git add .虽然方便，但也会把一些不该提交的文件（比如临时文件、日志文件、本地配置文件）一并加入。规范的团队一般会在仓库里配置.gitignore文件，把不需要追踪的文件类型和目录排除在外，这一点后面我会专门讲。
第三步，提交到版本库：
bash复制git commit -m "docs: 添加项目说明文档"
-m参数后面跟的是提交说明。提交说明的质量直接影响后续的历史追溯效率。我的习惯是采用约定式提交的格式，用feat:、fix:、docs:、refactor:、test:这些前缀来区分提交类型，遇到紧急修复还能在fix后面加(模块名)标注影响范围，比如fix(user-center): 修复登录超时问题。这样看历史记录时，一眼就能扫出来哪笔提交是干嘛的。
提交完成后，用git log查看提交历史，你会看到每次提交的哈希值、作者、日期和提交说明。加--oneline参数可以把历史压缩成一行一行的简洁列表，非常适合快速浏览。
4.2 分支操作：平行宇宙的创建与合并
分支是Git最强大的功能，也是很多新手觉得最玄乎的部分。换个角度看，分支其实就是一条独立的提交线，你可以从某个历史节点分叉出去，在分叉上任意修改和提交，完全不影响主线。开发完再把它合并回去。
常用的分支命令只有那么几个。创建一个新分支：
bash复制git branch feature/login
切换到新分支：
bash复制git checkout feature/login
上面两步可以用一条命令完成：
bash复制git checkout -b feature/login
这两个操作合在一起，覆盖了“我先建一条新线，然后走到这条新线上去开发”的完整语义。
合并分支时，最关键的一个选择是merge和rebase的区别。默认大多数人用的是merge：
bash复制git checkout main
git merge feature/login
merge会生成一个新的合并提交，它的好处是完整保留了分支的汇入历史，缺点是历史记录会出现“分叉再汇合”的网状结构，复杂项目里看起来不够线性。rebase则是把当前分支的提交一个个“摘下来”，重新排列到目标分支的顶端，历史变成一条直线，干净整洁，但代价是会改写提交哈希，多人使用同一条分支时容易产生冲突。
我的个人建议是：在自己的功能分支上，可以放心用rebase来保持历史整洁；在多人协作的主干分支上，优先merge，安全第一。不过这属于团队规范层面的取舍，没有绝对的对错。
4.3 撤销与回退：三个常见的“后悔药”场景
Git被很多人称为“后悔药制造机”，因为它能应对各种手误。但后悔药也有不同强度，用对了救命，用错了可能连后悔的机会都没了。
场景一：文件改了，但还没git add，想撤销工作区的改动，回到上一次提交时的状态：
bash复制git checkout -- 文件名
或者新版Git更推荐的语义化命令：
bash复制git restore 文件名
这个操作很直接，它会把版本库里的内容覆盖到工作区，你手动的修改会全部丢失，所以执行前确认一下是不是真的不想要这些改动了。
场景二：文件已经git add了，想取消暂存，但保留工作区的修改：
bash复制git reset HEAD 文件名
新版命令是：
bash复制git restore --staged 文件名
注意这里只是把文件从暂存区“退出来”，不会动你工作区里的内容。常用在“本来想提交A文件，手滑把B文件也加进来了”这种情况。
场景三：已经提交了好几次，想回退到某个历史版本。这里有两种力度，务必要分清。git reset --soft只是把HEAD指针挪到指定提交位置，你后续提交的内容还在暂存区里；git reset --hard则是把暂存区和工作区全部重置到目标提交的状态，中间所有提交都会被丢弃。搞混的话，可能把最新的代码全冲掉，而且很难找回来。所以我的习惯是：执行reset --hard之前，先给当前状态创建一个备份分支git branch backup/xxx，万一手滑了还能用git reset --hard backup/xxx跳回来。
如果已经提交了，而且代码已经推送到了远程仓库，一般不建议再用reset改写历史，而是用git revert来生成一个“反向提交”，把错误代码撤销掉的同时保留完整历史。这在多人协作的场景下是最稳妥的。
5. 新项目与日常协作场景的完整流程演示
5.1 本地初始化仓库与首次提交
说了这么多命令，我们用一套真实项目流程把它们串起来。假设你准备接手一个新项目，或者自己从零开一个项目目录，第一步是进入项目根目录，初始化仓库：
bash复制cd /path/to/your-project
git init
执行后，目录下会多出一个隐藏的.git文件夹，这就是Git仓库的本体。注意，这个文件夹里装的是整个仓库的全部历史记录，日常开发中不要手动去改它里面的文件，一旦损坏，轻则提交异常，重则历史全部丢失。
初始化之后，第一时间创建一个.gitignore文件。这个文件里的每一行，都是一个忽略规则，告诉Git不用追踪哪些文件或目录。比如用Node.js开发，至少要忽略掉node_modules/；用Python，要忽略__pycache__/和.venv/；编译产物如dist/、build/一般也不入库；IDE的本地配置如.idea/、.vscode/最好也忽略。把忽略规则写全，能避免很多“文件怎么又冲突了”的烦恼。
接着就可以执行第一次提交了：
bash复制git add .
git commit -m "chore: 初始化项目"
首次提交的意义在于给整个项目打下一个稳定的基线。从这一刻起，你可以放心大胆地去改任何代码，因为所有修改都在Git的掌控范围内。
5.2 新功能开发的标准操作：切分支、提交、合并
项目初始化好之后，日常开发的第一步永远不是直接改代码，而是先确定“我在哪条分支上干活”。查看当前分支用git branch，它会列出所有本地分支，并在当前分支前面加个*号。
假设主分支是main，你要开发一个登录功能，正确流程是：
bash复制git checkout -b feature/login
切到新分支后，编辑器里改代码，改完一段就提交一段。这里一定要养成“小步提交”的习惯，不要憋着一整天攒了一大堆改动才提交一次。一天下来几十个文件的改动堆在一起，一旦出错，回退时都不知道退到哪一步。每完成一个相对独立的功能点，就git add对应的文件，写一条清晰的提交说明，立即commit。
功能开发完，测试通过后，切回主分支，把功能分支合并进来：
bash复制git checkout main
git merge feature/login
如果合并时遇到冲突，Git会在冲突文件里用<<<<<<<、=======、>>>>>>>标记出两边的代码。你需要手动打开文件，决定保留哪一方的修改，或者把两边合并成新代码，删掉这些标记行，然后重新git add再git commit，完成合并。处理冲突是最考验耐心的环节，我的经验是：遇到冲突先别急着改，先用git status看看哪些文件冲突了，再逐个打开，理清双方的意图后再动手。
合并完成后，如果功能分支没用了，可以删掉：
bash复制git branch -d feature/login
-d会检查该分支是否已经合并，如果没有合并就提示你，避免误删还保留着独立提交的分支。
5.3 远程仓库协作：clone、push、pull与fetch
当你完成本地开发后，需要把代码推送到远程仓库，让队友看到并协同。远程协作涉及的命令不多，但排列组合起来容易让人迷惑，我把它们拆开讲。
先看两种启动方式。第一种是你从别人已经建好的远程仓库拉取代码到本地：
bash复制git clone git@github.com:user/project.git
执行完，项目代码和Git仓库都会出现在当前目录下的一个子文件夹里，而且Git会自动把远程仓库地址记录下来，命名为origin。第二种是你本地已经有仓库，要给它在远程建一个空仓库并绑定地址：
bash复制git remote add origin git@github.com:user/project.git
git push -u origin main
这里的-u参数是--set-upstream的简写，含义是“把本地的main分支和远程的main分支建立跟踪关系”。设置过之后，后续直接敲git push就可以，不用再写origin main。
日常更新代码，有两个容易混淆的命令：git pull和git fetch。git fetch只把远程仓库的更新拉取到本地，但不会改动你当前的工作区；git pull则是fetch加merge的组合，会直接把远程更新合并到当前分支。我见过不少开发者的习惯是一上来就git pull，结果本地有未提交的改动时，经常被远程更新顶得乱七八糟。如果你本地有改动，建议先用git stash把改动暂存起来，git pull之后再git stash pop把改动恢复出来，能省不少冲突处理的精力。
6. 我踩过的Git坑与对应的排查修复经验
6.1 Windows下CRLF换行符引发的“假冲突”
第一次带跨平台团队时，我遇到过一件怪事：一个同事在Windows上改了两行代码，提交后合并，Git却提示他和另一个Linux同事的三百多行代码冲突。打开冲突文件一看，满是^M符号，核心逻辑根本没碰过。原因就是换行符没有统一。
解决思路分两步。第一步，统一仓库里存储的换行符格式，我最终在团队内部约定：仓库里一律LF，不追踪文件权限。Windows开发机执行git config --global core.autocrlf true，Linux和Mac执行git config --global core.autocrlf input。第二步，对已经被错误格式污染过的历史文件，用一条命令批量重写工作区：
bash复制git add --renormalize .
这条命令会按照当前的换行符配置重新规范化所有文件，然后再提交一次，让仓库里整个历史基线变得干净。从那以后，这类“假冲突”再没出现过来。
6.2 误执行git reset --hard之后如何救回
前面提到git reset --hard很危险，但危险不等于无解。有一次我在一个分支上执行git reset --hard HEAD~2，把最新的两笔提交连同工作区的改动一起冲掉了，然后才想起来还有一个被我改了一半、还没来得及提交的文件。当时一瞬间整个人是蒙的。
后来我找到的恢复办法有两个方向。方向一：如果你还记得被冲掉的那笔提交的哈希值，用git reflog查看操作日志，找到对应位置，再git reset --hard <哈希>跳回去。reflog会记录你在本地仓库里执行过的每一次HEAD移动操作，相当于Git的操作历史，不会因为reset而丢失。方向二：如果文件压根没有提交过，只是工作区改动被reset清掉了，那就只能寄希望于IDE的本地历史，比如VS Code的Timeline功能，或者JetBrains系列里的Local History。这个教训让我养成了一个条件反射：任何一次reset --hard之前，先git branch backup/当前分支名建一个备份分支，真出事了随时跳回来。
6.3 gitignore规则不生效的真相
.gitignore文件写好之后，有时候你会奇怪地发现某些文件明明在忽略规则里，git status却还是能看到它。新手很容易以为是规则写错了，反复调整格式，其实真相很简单：如果某个文件在加入.gitignore之前就已经被Git跟踪了，那么忽略规则对它是无效的。Git只会在文件处于“未跟踪”状态时，才参考忽略规则来决定要不要显示它。
针对已经被追踪的文件，最直接的办法是从Git缓存中移除它，但保留本地文件：
bash复制git rm -r --cached node_modules
git commit -m "chore: 移除node_modules的版本追踪"
执行完之后再更新.gitignore，把这个路径加进去，以后就彻底清净了。这里的--cached参数是关键，它只移除了Git缓存里的记录，实际磁盘上的文件一个都不会少。
6.4 提交信息写错与邮箱错误的历史修正
有一次我把一个功能分支上的5笔提交推送到远程后，才发现5笔提交的作者邮箱全部写错，导致代码托管平台上的统计和审查系统无法正确关联到人。这种场景并不少见，尤其是用别人的电脑改过代码，或者全局配置信息本身有问题。
如果提交还没推送到远程，修正方案是交互式变基：
bash复制git rebase -i HEAD~5
在打开的编辑界面里，把需要修改的提交前面的pick改成edit，保存退出后依次执行git commit --amend来修正提交信息或作者，然后git rebase --continue跳到下一笔。
如果提交已经推送到了远程，修正历史就要格外谨慎。你需要再执行一次git push --force才能把改写过的历史覆盖到远程，但这个操作会改变远程分支上所有人都看得到的提交记录，如果别人已经基于这些提交做了新开发，会造成严重的同步问题。所以我的铁律是：只有在自己独立开发的功能分支上，才允许强推修正历史；在共享的主干分支上，宁可追加一个新提交，也不去改写历史。
6.5 误提交敏感信息的应急处理
最后再说一个相对少见但影响很大的问题：把密码、密钥、token这类的敏感信息提交到了仓库里。哪怕你后来把文件删掉了再提交一次，敏感信息也仍然留在历史记录中，任何人都能翻出来。
第一步，立刻修改已泄露的密码或密钥，让泄露的凭据立即失效，这一步永远是最重要的。第二步，用工具改写历史，把敏感信息从所有历史提交中抹掉。常用的工具是git filter-repo，它是官方推荐的历史改写工具，市面上很多教程还在讲古老的filter-branch，性能差且容易出错，不推荐。执行方式大致是：
bash复制git filter-repo --path path/to/secret.txt --invert-paths
这里--invert-paths的含义是“保留除指定路径外的所有文件”，也就是把敏感文件从整个历史中删除。执行完它会自动帮你清掉origin的remote配置，需要重新git remote add绑定远程地址，然后强推覆盖。
还需要注意一点：改写历史之后，所有已经从远程克隆过这个仓库的人，他们的本地历史里依然残留着敏感信息，除非他们重新克隆或者按你的改写方式同步。所以在真实团队里，这样的操作通常需要全体成员协同配合，绝不能一个人悄悄执行完就完事。
Git这个东西，说实话入门门槛真的不高，把add、commit、push、pull、branch、merge这六七个命令反复用熟，就足以应付大多数日常开发。真正拉开差距的，是对工作流的理解和异常情况的处理能力。希望这篇从安装配置讲到命令原理、再讲到实战坑位的长文，能让你少走一些我走过弯路。写到最后，我再分享一个个人习惯：每次准备做危险操作（reset、rebase、force push）之前，先在草稿箱或聊天框里把命令和影响范围写一遍，确认无误再去终端里执行。这个看似多此一举的步骤，已经帮我避开过好几次灾难级的失误。