我真的不是标题党：为什么我会写这样一份Git学习记录？
先交代一下背景。2024年以前我一直是个“能跑就行”的半吊子用户，Git在我手里基本只有三板斧：add、commit、push。直到有一次帮同事排查代码冲突，发现自己连git rebase和git merge的区别都讲不清楚，更别提背后那套索引和对象模型了。那段时间我吭哧吭哧翻文档、看专栏、记笔记，前前后后折腾了一个月，踩了无数坑，才慢慢把Git从“工具”用成了“习惯”。
这份“Git学习记录”不是官方文档的复读，也不是命令大全式的罗列。它是我自己从零开始、亲手敲过每一个命令之后的经验沉淀，包含完整安装配置、高频命令、免密方案、常见网络热词背后的真实场景，以及一些冷门但实用的排查技巧。适合刚起步的新手照着操作，也适合给用了一段时间但总感觉哪里没通的人查漏补缺。如果你正准备系统梳理一遍Git，这篇文章应该能帮你少走大半弯路。
1. 先别急着敲命令：Git安装前的三个认知铺垫
很多教程上来就让你下载安装，装完再讲概念，结果就是命令敲得飞起，出了问题完全不知道去哪找原因。我自己踩过这个坑，所以强烈建议你动手之前，先把下面三件事在脑子里过一遍。
1.1 为什么要先理解Git和GitHub的区别
这是个特别基础但又特别容易被混淆的点。Git是一个分布式版本控制系统，它负责在你本地记录文件的每一次改动、管理分支、支持回滚；而GitHub、GitLab、Gitee这些平台，只是基于Git协议搭建的远程托管服务，相当于给本地仓库提供了一个云端备份和协作的中转站。
没有远程仓库，Git本身也能完整工作。我在没有联网的飞机上提交过代码，落地后一push，所有提交记录都在，这就是分布式带来的安全感。搞清楚这层关系之后，你就不会再把“上传到GitHub”和“使用Git”画等号了，后面理解remote、push、pull这些概念会顺畅很多。
1.2 版本选择和包管理器之争：官方安装包还是命令行安装？
Git的安装方式很多，但不同方式的后续维护成本差异非常大。以我的实战经验，分系统来说：
- Windows环境：官方exe安装包（从git-scm.com下载）和
winget install --id Git.Git -e效果差不多，exe安装时注意勾选“Add to PATH”即可。不建议用非常古老的“便携版”或来路不明的绿色版，因为Git在Windows依赖系统环境变量和OpenSSL配置，封装过度的版本容易出幺蛾子。 - macOS环境：我强烈推荐通过Homebrew安装，也就是
brew install git。好处有两点：第一，它自动处理依赖关系；第二，后续升级只要一条brew upgrade git就够了，不用跑到官网重新下载安装包覆盖。 - Linux环境：用发行版自带源安装最简单，Debian/Ubuntu系执行
sudo apt install git；CentOS/RHEL系执行sudo yum install git。如果源里的版本太老，那就编译安装新版，或者配置第三方源，但这适合有经验的用户，新手建议先用系统源。
从我的实操心得来看，无论哪个系统，装完之后第一件事都应该是执行git --version确认安装成功，同时看一眼版本号。不同版本的Git对协议、默认分支名、认证插件的支持不同，版本信息是排查问题的第一线索，很多人遇到疑难杂症最后发现是版本太老导致的。
1.3 一次安装后的全局体检：验证Git是否具备完整工作能力
安装不等于配置完成。我见过很多人在这一步翻车，因为装完之后什么都没验证就进入下一步，等到推送代码才发现认证有问题。
安装完我习惯顺手执行下面这几条命令做体检：
# 查看版本，确认安装成功 git --version # 查看全局配置文件位置，方便后续手动编辑 git config --global --list --show-origin # 查看Git默认使用的编辑器 git config --global core.editor如果git config --global --list返回空，说明你还没设置用户信息；如果提示找不到命令，那就从PATH变量排查。我曾经在Windows上遇到过装完Git但重启终端才生效的情况，因为环境变量在系统重启前不会重新加载。这些都是小问题，但提前知道解法，总比临时抓瞎强。
2. 安装及配置教程的进阶组合：用户信息、换行符、别名的完整调优
关于“Git安装及配置教程”的热搜词常年居高不下，说明大家都卡在安装之后的那一步：怎么配置才顺手？这里我把自己长期使用的配置方案完整拆开，每一步都告诉你为什么要这样设置。
2.1 用户信息配置：user.name和user.email的真正作用
git config --global user.name "Your Name" git config --global user.email "your@email.com"这是每个教程都会教的命令，但我特别想强调一点：这个user.email和你的远程仓库登录账号没有必然关系。它只作为提交记录里的作者标识，将来显示在commit历史里。所以哪怕你的邮箱填错了，提交依然能成功，只是提交历史里会留下错误的作者信息。
这里有三个级别需要分清：--system（全机器生效）、--global（当前用户生效）、--local（当前仓库生效）。作用域越小，优先级越高。如果一个项目需要用特定的企业邮箱覆盖全局的个人邮箱，就在该项目目录下执行git config --local user.email "work@company.com"，这样不会影响其他项目。
修改完user信息后，已经产生的旧提交不会自动更新。如果需要在改邮箱后修正历史，可以用git filter-branch或git filter-repo，但那个操作会改写提交哈希，强烈不建议在共享分支上执行。我个人的习惯是：先想清楚用什么邮箱，提交前检查一遍，省得后续折腾。
2.2 core.autocrlf：新老手最容易忽略的换行符陷井
换行符的问题，表面看不致命，但一旦遇到，解决起来最费时间。Windows系统里的文本默认用CRLF（回车+换行）结尾，而Linux和macOS用的是LF（换行）。Git如果不去管它，同一份文件在不同系统之间切换时，会在diff里看到整行都被标为改动，造成“文件没动但diff很乱”的假象。
处理这个问题的配置项是core.autocrlf。我推荐按系统分开设置：
- Windows用户设置为
true，Git在提交时会把CRLF转为LF存进仓库，检出时再转回CRLF； - macOS和Linux用户设置为
input，提交时转成LF，但检出时不强制转换； - 如果你确定团队所有成员都用同一种系统，那就设置
false，彻底关闭转换。
我个人的做法比较稳妥：在仓库根目录增加一个.gitattributes文件，明确指定哪些文件用什么换行符。比如：
* text=auto *.sh text eol=lf *.bat text eol=crlf把这个文件提交到仓库后，所有成员无论在哪套系统上操作，都会被Git强制按规则处理换行符，比靠每个人自觉修改配置可靠得多。这个技巧是从一次线上事故里学来的：当时因为Windows成员提交时把整个文件从LF转成了CRLF，导致diff全部显示为删除再新增，代码评审差点没法做。
2.3 配置别名和默认编辑器：让Git用起来更顺手的小细节
Git允许为命令配置别名，也就是快捷键。我常用的别名配置如下：
git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status git config --global alias.lg "log --graph --pretty=format:'%h -%d %s (%cr) <%an>' --abbrev-commit --date=relative"设置完git lg之后，你会得到一棵清晰的分支提交图谱，每次看历史都比默认的git log舒服得多。别名的本质是字符串替换，所以还能组合出更复杂的自定义命令，比如：
git config --global alias.unstage "reset HEAD --"以后想取消暂存就可以直接执行git unstage file.txt，不用记那一长串reset参数。配置编辑器同理，执行git config --global core.editor "code --wait"之后，commit信息弹窗就会用VS Code打开，写完保存关闭即可。
3. 核心命令的精讲与实操：add、commit、branch和撤销策略
很多人把“Git命令”直接理解为一堆离散指令，背了就忘。实际上Git的高频命令背后有一条非常清晰的路径：往索引里放内容（add）、把索引固化成记录（commit）、在记录之间切换和分叉（checkout/branch）、必要时抹掉或修改记录（reset/revert）。一旦你理解这条路径，命令就不再需要死记硬背了。
3.1 把目录变成仓库：init和clone的适用场景
git init是把当前文件夹变成一个仓库，适合你手头已有项目、准备开始用Git管理的情况。执行完会生成一个.git隐藏目录，这个目录里存放着Git的全部对象、引用和配置信息，不要手贱去改里面的文件。
git clone则适合从零开始接手一个已有项目。它的本质是：在本地把远程仓库完整复刻一份，包括所有历史提交。所以clone出来的项目自带完整log，不需要重新init。我建议新手在GitHub上练习时多采用clone方式——GitHub会默认生成README等文件，避免你陷入“先有仓库还是先有文件”的鸡生蛋问题。
3.2 add和commit之间的那道“暗门”：暂存区到底装了什么
我刚学Git时最不理解的就是暂存区（Index/Stage）存在的意义：为什么不能一步到位直接提交？后来才意识到，暂存区提供的恰恰是“挑挑拣拣再打包”的能力。
git add会把文件当前的内容复制到暂存区，生成一个二进制快照；git commit则把暂存区里的快照正式提交为版本记录。如果你改了文件却不add，无论怎么commit，这次改动都不会进去。这个报错提示“Changes not staged for commit”就是这么来的。
工作中的高频场景是只需要提交一部分文件改动，这时可以用：
git add file1.txt file2.txt git commit -m "只提交这两个文件的改动"或者更精细一点，只想提交某个文件中的部分改动：
git add -p这条命令会逐块（hunk）询问你是否要暂存某个改动的片段，适合那种“顺手在一份文件里改了两个无关点”的情况。我几乎每天都在用git add -p，它能帮你把提交记录拆得干净整洁，这也是评审代码的同事对提交粒度比较满意的关键。
3.3 分支管理实操：新建、切换、合并和删除
分支是Git的杀手级能力，但它的开销问题曾让很多SVN用户产生误解——以为分支很重，不敢多用。实际上Git创建分支的成本极低，因为它只是创建一个指向某个提交的指针，不复制文件，所以“早建分支、勤建分支”是靠谱的实践。
常用命令：
# 查看本地和远程的分支列表 git branch -a # 新建并切换到某分支 git checkout -b feature/login # 普通切换 git checkout main # 合并feature分支到当前分支 git merge feature/login # 删除本地分支 git branch -d feature/logingit checkout -b这个复合命令，等价的底层逻辑是先branch再checkout。我在实际工作中发现一个常见的坑：如果当前工作区有未提交的改动，checkout切换分支时可能会把改动带过去。解决方法是提交或stash之后再切换。
合并代码时我倾向用git merge --no-ff保留一条合并记录，便于回溯时确认“这个功能是哪批合并请求带进来的”。如果你想规整历史，那再学git rebase，把一条分支上的多次提交“变基”到目标分支顶部。这里先按个暂停：rebase会重写提交哈希，只在本地未推送的分支上使用，不要在团队共享分支上使用。
3.4 撤销操作的三个维度：工作区、暂存区、提交记录
撤销是Git学习和使用的高频痛点，也是新手最容易把状态搞乱的地方。我按操作对象把撤销策略拆成三层：
第一层：工作区改动未暂存时
git restore file.txt这条命令会把文件还原成最近一次提交或暂存的状态，相当于放弃当前还没add的修改。它是危险命令，一旦执行，未提交的修改无法恢复。
第二层：已经add进暂存区时
git restore --staged file.txt这会把文件从暂存区移出来，变成“已修改未暂存”的状态，但文件内容本身不会动。如果你需要连暂存区的保存内容一起回滚到最新提交的状态，那就：
git reset HEAD file.txt这里的核心思路是：--staged只动索引，不动工作区；想同时清空工作区就把两个参数组合使用（如git reset --hard HEAD）。但注意，reset --hard非常暴力，会同时丢弃工作区和暂存区的全部改动，使用时务必谨慎。
第三层：提交记录需要修正时
- 如果只是commit信息写错了，用
git commit --amend重新编辑上次提交信息； - 如果提交内容有遗漏，用
git add补加文件后再执行git commit --amend，它会合并进上一条记录，不产生额外的新提交； - 如果某个提交已经push到远程，需要撤销这次提交产生的内容变动，用
git revert <commit-hash>。revert会生成一条新的反向提交，保留原有历史，适合团队协作场景。
撤销命令对比速查表
| 操作场景 | 命令 | 是否影响历史 | 适用场景 |
|---|---|---|---|
| 放弃工作区未暂存改动 | git restore file | 否 | 本地改乱了想还原 |
| 撤销暂存但不删文件 | git restore --staged file | 否 | 误add了不想提交的文件 |
| 重置提交指针 | git reset --hard HEAD~1 | 是（本地） | 废弃最近一次本地提交 |
| 新增反向提交以撤销远端改动 | git revert <hash> | 是（追加一条） | 已推送提交需要回滚 |
我从自己多年的实操中总结出一条血泪教训：不确认命令后果前不要带--hard参数。宁可多执行一步git status看清当前工作区状态，也不要莽撞操作后在回收站里找日志。真的碰到误删，还有一个缓兵之计是git reflog，它能查看HEAD和分支引用在过去一段时间内的变动记录，误删的提交往往还能通过它捞回来。
4. 远程仓库与免密配置的完整方案
“Git免密”、“Git下载安装教程”、“git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks”等热词背后，反映出大家真正遇到的问题其实集中在“怎么跟远程仓库舒服地打交道”。这一章我会把远程协作相关的配置和使用讲透。
4.1 添加远程仓库、推送与拉取的操作细节
假设你在GitHub上新建了一个空仓库，回到本地：
# 给当前仓库添加远程地址 git remote add origin git@github.com:username/repo.git # 推送本地main分支到远程，并建立跟踪关系 git push -u origin main-u参数的作用是把本地分支与远程分支关联起来，这样以后直接执行git push或git pull时，Git就知道该跟哪个远程分支交互，无需每次带上仓库名和分支名。
日常开发中，执行git pull之前，我会习惯先看一眼当前工作区是否干净。如果本地有未提交改动，pull可能引发冲突或者报错“Your local changes would be overwritten”，这时要么先提交，要么用git stash把改动暂存起来，pull之后再git stash pop取回。
一个我反复推荐给团队同学的小技巧：push之前先pull，pull之前先stash或commit。这个顺序能规避绝大多数协作冲突。
4.2 SSH免密配置：为什么我推荐它而不是HTTPS输密码
如果不想每次git push都手动输入用户名和密码，就必须做免密配置。Git认证的主流有两种方式：
一是HTTPS + 凭证管理器（credential helper）。Windows上安装Git时通常自带“Git Credential Manager”，第一个推送会弹窗让你输入用户名和Token，此后凭证被加密保存，Git会自动复用。macOS则有“osxkeychain”作为凭据存储。这种方式对新手很友好，简单快捷。
二是SSH密钥对。我本人更推荐这种方式，因为SSH密钥一旦配置好，对后台脚本、持续集成、多仓同步都很友好。说下完整流程：
# 第一步：生成SSH密钥对 ssh-keygen -t ed25519 -C "your@email.com" # 生成结果建议保存在 ~/.ssh/id_ed25519 和 ~/.ssh/id_ed25519.pub # 第二步：启动ssh-agent并添加私钥 eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519 # 第三步：把公钥内容复制到GitHub/GitLab的SSH key设置页 cat ~/.ssh/id_ed25519.pub为什么选择ed25519而不是传统的rsa？因为ed25519密钥更短、生成更快、安全强度也足够，GitHub早在2021年就全面支持了。把公钥加到平台后，我建议用ssh -T git@github.com测试连通性，出现“Hi username!”的提示说明验证通过。
之后，在执行git remote add时选用SSH地址（形如git@github.com:username/repo.git），推送过程就不再要求输入密码了。
HTTPS与SSH免密方案对比
| 维度 | HTTPS + Credential Manager | SSH密钥 |
|---|---|---|
| 首次配置难度 | 低，弹窗引导 | 中，需要理解公钥/私钥 |
| 多设备管理 | 每台设备都要登录授权 | 每台设备生成独立密钥并添加公钥 |
| 适合场景 | 新手、少量克隆公有仓库 | 开发主力、CI脚本、日常多仓库管理 |
| 安全风险 | Token泄露需要到平台撤销 | 私钥泄露等同于账号泄露 |
4.3 git凭据管理器与token登录：别再傻傻输入账号密码了
如果你确实不想生成SSH密钥，但又必须用HTTPS方式操作Github，那么现代GitHub的密码认证已经不能使用账号密码的组合了，必须使用Personal Access Token（PAT）。在GitHub“Settings > Developer settings > Personal access tokens”中生成一个Token，把它当成密码粘贴，或者干脆写进URL里：
git remote set-url origin https://<TOKEN>@github.com/username/repo.git不过直接在remote地址里嵌入Token很容易泄露，我不建议长期使用。更好的做法是使用credential helper缓存一次：
git config --global credential.helper cache # 默认缓存15分钟 git config --global credential.helper "cache --timeout=3600"实际上Windows上的Git Credential Manager和macOS的osxkeychain都能做到持久化存储，第一次输完Token之后就不再重复询问了。
5. 一个冷门但常见的Git命令场景：当你在日志里看到“git -c diff.mnemonicprefix=false ...”
有时候你会在IDE、GUI客户端或自动化工具的运行记录里看到类似git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks ...的命令。很多初学者会被这种超长命令吓到，以为是什么深奥魔法。其实它只是带了一堆临时配置项的普通Git调用。理解它，有助于你看懂GUI工具在后台做了什么。
5.1 拆解这条命令里的三个参数
先看它的结构：git -c <key>=<value> <command>。-c的作用是临时修改一个配置项，只对当次命令生效，不写入配置文件。例如：
diff.mnemonicprefix=false：mnemonicprefix如果为true，Git在diff输出时会把a/和b/前缀换成index/、worktree/之类的语义化前缀；置为false，则保持默认的a/和b/前缀。GUI工具设置成false，往往是为了让输出的patch行为更传统、更便于解析。core.quotepath=false：这个配置很实用。它控制Git对非ASCII文件名的处理。默认情况下，Git为了安全，会把中文或带空格的文件路径转义成八进制字符串（类似"\346\265\213\350\257\225.txt"），很难读。设置为false之后，可以直接显示原始路径。--no-optional-locks：这是一个命令行选项，意思是禁止执行某些可选锁操作。例如，当git命令运行在类似Sourcetree这样的GUI工具里时，工具只看状态但不想改变仓库的访问时间等元数据，加这个参数可以避免不必要的锁等待。
5.2 从这条命令学到的事：Git所有配置都可以临时覆盖
理解这条命令的收获不只是认参数，而是一个底层思路：Git的配置项几乎都能在前缀临时指定。比如你在CI脚本里临时需要用户身份覆盖仓库里的配置，可以不带--global，直接在一条命令前加-c user.name=... -c user.email=...，然后执行commit。脚本里调试也是这么干的。
我遇到一次线上部署脚本因为仓库历史里的user.name不匹配导致审计失败，当时就是用临时覆盖方式快速定位的，并没有改动全局配置。所以不要把-c理解成冷门技能，它是真正能救命的排查工具。
6. 常见问题与排查技巧实录
这一章，我记录一些自己从新手期一路走来实际踩过的坑。它不像前面的章节那样线性，更像一份“速查手册”，你遇到问题时可以按图索骥。
6.1 中文文件名显示成八进制乱码
这是Git老用户都会遇到一次的谜之现象：执行git status，改动的中文文件名显示成"\346\265\213\350\257\225.txt"。
根本原因就是上面提到的core.quotepath默认值为true。Git默认对非ASCII路径做了转义处理，避免不同编码环境下文件名输出不一致。解决方案很朴素：
git config --global core.quotepath false修改后立即生效，中文路径正常显示。开发环境是UTF-8编码的朋友建议直接配成全局，省得每台新机器都踩一次。
6.2 明明文件删了，为什么Git还说有改动
新手常遇到的两张“灵异脸”：移除了文件但Git没感知到；误删了文件想恢复但不知道命令。
如果是在文件管理器里手动删除文件，Git会感知到“deleted”状态，但不会自动暂存。你需要执行：
git rm file.txtgit rm会同时删除工作区文件和暂存区记录。如果你只是想从版本控制里移除文件，但保留本地文件，那就用：
git rm --cached file.txt这个命令适合处理误提交进去的大文件或配置文件。需要注意的是，执行后必须提交，删除操作才会真正记录到版本历史里。
恢复误删文件同样简单：
git restore file.txt只要文件在最近一次提交里存在，它就能被恢复。但前提是你还没有把删除操作提交上去，如果已经提交，那就到对应提交里取文件。
6.3 提交信息写错或漏了文件：善用commit --amend
很多人第一次用git commit --amend都心惊胆战，担心改坏了历史。其实它只是把当前暂存内容合并到上一个提交上，不改变分支脉络。应用场景有两类：
改错别字或规范提交信息：
git commit --amend -m "fix: 修正登录接口参数校验"漏提交了一个文件：
git add forgot-file.txt git commit --amend --no-edit--no-edit表示沿用上一条提交信息，不用重新编辑。
这个命令的唯一坑是：如果那个提交已经push到远程共享分支，amend之后本地和远程的提交哈希会不一致，此时直接push会被拒绝，需要git push --force或git push --force-with-lease。force push是协作禁区，除非你明确知道自己在做什么，否则不建议对共享分支执行。
6.4 误操作的后悔药：reflog到底能救回什么
如果上面的方案都不能解决你的问题，还有一个终极后悔药。Git里有个概念叫“引用日志”（reflog），它记录了HEAD指针的历史移动轨迹。即使你执行了git reset --hard丢弃了某次提交，只要那次提交还在reflog里躺着，就能被找回。
git reflog输出会列出序号、操作前后的commit哈希以及操作描述。找到丢失前的位置后，比如HEAD@{2}，执行：
git reset --hard HEAD@{2}就能回到那个状态。这个命令在找回误删分支、误reset提交时非常管用。注意reflog有保留期，默认是90天，过期后不可恢复，所以挽救要趁早。
6.5 高频问题速查表
| 现象 | 原因 | 处理建议 |
|---|---|---|
| push被拒绝，提示“non-fast-forward” | 远程有新提交，本地落后 | 先pull或fetch再merge/rebase |
| 提交里作者显示的邮箱不对 | user.email配置错误 | 结合filter-branch修正，谨慎操作共享分支 |
| 中文文件名显示乱码 | core.quotepath为true | 设置core.quotepath false |
| pull时报“local changes would be overwritten” | 本地有未提交改动 | commit或stash后再pull |
| 切换分支时未提交改动被带过去 | 工作区状态跨分支延续 | 先checkout前确认干净，或用stash隔离 |
| 某文件无故被标记为已修改 | 换行符不一致 | 用.core.autocrlf和.gitattributes统一换行符 |
| commit --amend之后push失败 | 本地与远端历史哈希不一致 | 改用新提交，或仅在确认安全的情况下force-with-lease |
| 误删分支找不到 | 分支引用已删除 | 用git reflog找回该分支最后一次的commit哈希 |
7. 这份学习的延续思考：到底该怎么继续深入Git
走到这里，你已经把日常开发和团队协作中使用频率最高的Git能力过了一遍。但Git的水远比我现在写到的深得多。比如git bisect定位引入bug的提交、git worktree实现一个仓库同时检出多个分支、git replace和git filter-repo做历史改写，都是进阶路上的好课题。
我自己学Git最深的体会是，一定要想办法把命令和实际场景挂钩。单纯记住git merge是什么意思没有意义，当你真的在分支上写下一天代码之后merge失败，亲历一次冲突解决、亲手逐行选出保留内容，这个知识点才能真正沉淀下来。所以多看官方文档有价值，但更重要的是在自己项目里把每个命令都用一遍。
最后分享一个我保持了很久的习惯：给自己的开源小项目单独建一个仓库，每次想尝试不熟悉的Git操作，就到这个仓库里做实验。分支、reset、rebase、amend，随便折腾，反正只是个测试场。等你在测试仓库里把所有操作跑顺手，再去动自己真正的代码，心里会踏实很多。这也是我在实际使用中觉得最值得推荐的一种学习方式。
