喂今天救公主了吗如果你搜过“Git基本操作”，大概率会看到一张命令清单：git init、git add、git commit、git push……照着敲一遍，仓库建了、代码推了，一切看起来顺顺当当。但等到真要撤销一次错误的提交、给某次提交补个文件、或者在 IDEA 里看到一堆红色报错时，很多人就开始手忙脚乱了。这篇文章想做的事，就是把这套“基本操作”从“能跑命令”推进到“知道每一步发生了什么”。
内容围绕日常开发中最常用到的 Git 操作展开，包括安装与首启配置、完整的提交流程、分支与合并、撤销与回滚、远程仓库协作，以及高频报错的排查思路。适合刚接触 Git 的初学者，也适合已经用了一段时间但总感觉“哪里没搞透”的同学。我不会罗列一份枯燥的命令大全，而是把每个操作为什么要这么做、底层发生了什么讲清楚，再配上我实际踩过的坑和验证过的方法。
1. 装完 Git 之后，真正该花时间的其实是配置
1.1 Windows 下安装：官网、镜像与 Git Bash 的选择
Windows 下最主流的安装方式是下载 Git for Windows，也就是大家通常说的“Windows 版 Git”。安装包里自带了 Git Bash，它是一个模拟 Linux 终端环境的程序，很多在 Windows 命令行里跑不通的指令，在 Git Bash 里都能正常运行。如果你后续要在 Windows 上用 SSH 密钥或执行 shell 脚本，Git Bash 是绕不开的工具。
下载渠道有两个：一是去 Git 官网，版本肯定是最新的；二是国内镜像站，比如清华大学开源软件镜像站、阿里云镜像站，下载速度快，对国内网络环境更友好。实际使用中，镜像站的版本和官网保持一致，安全性也没有问题，放心用。
安装过程中基本可以一路 Next，但有几个选项建议留意一下：
- 默认编辑器：建议选 Vim 或者你熟悉的编辑器。如果选 Vim，新手在 commit 时误入 vim 界面会不知道怎么退出，所以直接选 Notepad++ 或 VS Code 更省心。
- 调整 PATH 环境变量：默认选项是“Git from the command line and also from 3rd-party software”，建议保持默认，这样无论在 cmd 还是 PowerShell 里都能直接执行 git 命令。
- 行尾转换（Line Ending Conversions）：默认的
Checkout Windows-style, commit Unix-style通常不用改，跨平台协作时这个设置最省事。
安装完成后，打开命令行执行 git --version，能输出版本号就说明装好了。这个检查步骤虽然简单，但我见过不少人在环境变量出问题时卡在这一步，后面第 6 章会专门讲。
1.2 首次提交前的身份声明与全局配置
很多人第一次用 Git 时都遇过这个场景：git add 没问题，一执行 git commit 就报错，提示 “Please tell me who you are”。原因是 Git 需要知道提交人是谁，它会把 user.name 和 user.email 写进每一条提交记录里，作为作者信息。
配置方法很简单：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱@example.com"
--global 表示全局生效，写在用户级别配置文件中，之后这台机器上的所有仓库默认都会使用这套身份。如果某个项目需要单独使用不同的身份（比如工作电脑上分公司项目和私人项目），可以在项目目录里去掉 --global 重新设置，这个写入的是仓库级别的 .git/config，优先级更高。
查看当前配置用 git config --list，里面会列出所有生效的配置项。有一点容易被忽略：提交邮箱最好用你在 Git 托管平台（比如 GitHub、Gitee）上绑定的邮箱，这样平台才能把你的提交正确关联到账号，绿点统计和提交记录归属才会对得上。
1.3 SSH 密钥生成与远程平台配置
日常操作远程仓库有两种认证方式：HTTPS 和 SSH。HTTPS 方式每次 push/pull 都可能要求输入账号密码（取决于你是否配置了凭据管理器）；SSH 方式只要把公钥添加到托管平台，之后就能免密操作，这也是我推荐的方式。
生成密钥的步骤如下：
bash复制# 先检查是否已有密钥
ls ~/.ssh
# 没有就生成一个新的，-C 参数填你的邮箱
ssh-keygen -t ed25519 -C "你的邮箱@example.com"
一路回车即可，默认会生成一对密钥文件：私钥 id_ed25519 和公钥 id_ed25519.pub。私钥保存在本地，绝不能泄露；公钥可以公开，把它复制出来，添加到你所用平台（GitHub 或 Gitee）的设置页面里的 “SSH Keys” 区域。
验证是否配置成功：
bash复制ssh -T git@gitee.com
首次连接会提示确认主机的指纹，输入 yes 即可。如果返回 “Hi xxx! You've successfully authenticated” 之类的提示，就说明 SSH 密钥已经生效。
这里多说一句，公钥是绑定“机器”的，换了电脑就要重新生成一份并添加到平台。同一个账号下面可以添加多台机器的公钥，Git 会自动匹配。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从工作区到远程仓库：一条提交命令的完整旅程
2.1 三个区域的概念和为什么要先 add 再 commit
Git 的日常操作绕不开三个区域：工作区、暂存区和版本库。
用个生活化的类比：工作区是你的书桌，草稿和资料都摊在上面；暂存区是文件袋，你决定好哪些资料要归档，就把它们装进文件袋；版本库是档案柜，文件真正入库后就有了编号，可以随时翻阅历史版本。
对应到操作上：
- 你在工作区新建或修改文件，这些改动还没有被 Git 跟踪。
git add把指定文件放入暂存区，相当于装进文件袋。git commit把暂存区里已有的改动打包成一个提交，写入版本库。
为什么不直接一步到位，非要先 add 再 commit？因为实际开发中，一个项目可能同时存在多个文件的改动，有些改动属于这个功能，有些属于那个修复。通过 add 可以精确挑选哪些文件进入这次提交，做到“一次提交只做一件事”，后续回溯和 review 都会轻松很多。这是一开始就该养成的习惯，而不是觉得多了一步就图省事。
2.2 日常往返：status、add、commit、log 怎么配合
一条典型的提交链路长这样：
bash复制# 查看当前仓库状态，确认改动了哪些文件
git status
# 把改动的文件添加到暂存区
git add .
# 查看已经暂存的内容，和未暂存的改动区分开
git status
# 创建一次提交
git commit -m "fix: 修复登录页在移动端显示异常的问题"
# 查看提交历史，确认刚才的提交已经落库
git log --oneline -5
git status 是每天使用频率最高的命令，它告诉你当前仓库里“工作区有改动没暂存”“暂存区有东西没提交”“当前在哪个分支”，还会给出下一步操作的提示。我刚用 Git 那会儿很依赖它，基本每执行一步就敲一次 git status，宁可多看一眼也不做盲操作。
git add . 把当前目录下所有改动加入暂存区，日常很常用，但对初学阶段我反而建议多用 git add <具体文件>，逼自己清楚每次提交的边界。等熟练之后，再该用 . 时用 .。
git log --oneline 以一行一条的方式显示提交历史，内容包含提交的短哈希和提交信息。看历史时用这个命令最直观，能看到仓库的演进脉络。
还有一件事，创建项目时建议尽早补一个 .gitignore 文件。Node 项目的 node_modules、Java 项目的 target 或 out 目录、IDE 的 .idea 和 .vscode 配置、系统生成的 .DS_Store 文件，都不应该进入版本库。把需要忽略的路径整理到 .gitignore 里，能让 git status 的输出干净很多，也能避免别人 clone 下来后运行不了的问题。
2.3 push 与 pull：本地和远程的同步逻辑
有了本地提交之后，要把代码同步到远程仓库，最常见的是 push 和 pull 这两个方向的操作。
推送代码的第一步通常是关联远程仓库：
bash复制git remote add origin git@gitee.com:yourname/yourproject.git
origin 是远程仓库的默认别名，之后的 push、pull、fetch 都用这个名字指代远程地址。
首次推送时需要指定上游分支：
bash复制git push -u origin main
-u 参数把本地 main 分支和远程 main 分支关联起来，之后在这个分支上直接敲 git push 和 git pull 即可，不用再带仓库名和分支名。
拉取远程代码时，git pull 是初学者最先遇到的命令，但它实际上做了两件事：先 git fetch 把远程的最新提交拉取到本地（不合并），再执行合并操作把远程改动合并到当前分支。正因为如此，pull 有时会触发冲突提示。
如果本地和远程都产生了新的提交，直接 pull 会遇到 “non-fast-forward” 的错误提示。这种情况的常规解法是先执行 git pull --rebase，把本地提交“挪”到远程提交之后，再推送到远程，这样能保持提交历史的线性整洁。至于 rebase 和 merge 的取舍，第 3 章会细说。
3. 分支操作：开发和救火之间的安全隔离带
3.1 什么时候建分支、分支怎么命名
分支是 Git 绕不开的核心操作，也是一个很容易从一开始就被忽略的基础能力。很多人用 Git 默认分支一行走到黑，开发新功能、修线上 bug、做实验性改动全在 main 上直接动，出了问题很难回退。
一个更稳的协作习惯是：主分支永远保持可发布状态，日常开发在独立分支上进行。新建功能时从主分支拉一个功能分支，代码通过评审后再合回主分支。线上突然出问题了，也能立刻从稳定的主分支拉一个修复分支，修完合并，不用被未完成的功能代码拖累。
分支的命名建议用“用途/描述”的结构，方便一看就懂：
text复制feature/user-login 功能分支，开发用户登录模块
bugfix/fix-payment-error 修复分支，修复支付报错
hotfix/3.2.1-urgent-fix 热修复分支，紧急修线上问题
创建和切换分支有几种等价写法：
bash复制git checkout -b feature/user-login # 创建并切换（老写法）
git switch -c feature/user-login # 创建并切换（自 Git 2.23 起）
git branch feature/user-login # 只创建，不切换
git switch feature/user-login # 切换到已有分支
git switch 是较新版本新增的专门用于分支切换的命令，语义比 checkout 更清晰。但从通用性来说，老版本 Git 上只有 checkout，习惯了 checkout 也不用刻意改。
分支在 Git 里的本质是一个指向某个提交的可移动指针，创建分支几乎没有成本，因为只是多了一个指针而已。所以不用有心理负担，该开分支就开分支。本地分支可以完全不推送到远程，直到你觉得这个分支需要被人协作或备份，再执行 git push -u origin 分支名。
3.2 merge、rebase 与冲突解决的实操细节
合并分支有两种方式：merge 和 rebase。
merge 的特点是“合并即记录”，它会生成一个新的合并提交（merge commit），把两个分支的修改历史汇拢到一起。合并后的历史中能看到清晰的“分叉再汇合”的脉络，适合公共分支的合并，因为它不会改写已有提交。
bash复制git switch main
git merge feature/user-login
rebase 的特点是“改写历史”，它把当前分支的提交逐个取下，再依次放到目标分支的最新提交后面。优点是提交历史是一条干净的直线；缺点是提交的哈希会被改写，所以不要对已经被推送并且有多人协作的公共分支做 rebase。
bash复制git switch feature/user-login
git rebase main
那实际项目里怎么选？我的经验是：个人功能分支在合回主分支前，先用 rebase 把主分支最近的提交吸收进来，让本地功能分支基于最新代码；合入公共分支时用 merge，保留合并记录。这样既有清晰的线性开发历史，又不会因为改写公共历史引发问题。
无论 merge 还是 rebase，只要两个分支改了同一个文件的同一块区域，就会出现冲突。冲突发生后，Git 会在受影响的文件中插入类似这样的标记：
text复制<<<<<<< HEAD
你当前分支的内容
=======
对方分支的内容
>>>>>>> feature/user-login
处理方式是打开文件，去掉 <<<<<<<、=======、>>>>>>> 这几行标记，把代码手动调整为最终想要的版本，然后：
bash复制git add 冲突文件
git merge --continue # 或 git rebase --continue
会弹出编辑框让你写合并提交信息，确认后合并就完成了。刚遇到冲突时不要慌，这只是 Git 内部机制的正常行为，不是项目出问题了。解决冲突本身也是个校验你对业务理解的过程，多来几次就会习惯。
4. 提交出错后的三类后悔药：amend、revert 与 reset
4.1 amend：想改最近一次提交信息或补文件
提交之后发现信息写错了，或者漏掉了一个文件，这些是每天都可能碰到的小失误。如果这个提交还没有推送，修复起来非常简单：
bash复制# 修改最近一次提交的说明信息
git commit --amend -m "fix: 正确的提交说明"
# 给最近一次提交补一个漏掉的文件
git add 忘记提交的文件
git commit --amend --no-edit
--amend 的意思不是“修改”原有提交，而是用一个新的提交替换原提交。新提交会包含原来的改动，加上你新增的修改，产生一个新的提交哈希。所以如果原提交已经推送到了远程公共分支，就不要用 amend 了，它会破坏其他同学基于该提交的本地记录。那该怎么办？用下面的 revert。
4.2 revert：让远程历史也能安全撤销
git revert 用于撤销某个提交的改动，但它不会删除那个提交，而是生成一个反向的新提交。也就是说，被撤销的提交依然留在历史里，整体脉络是完整的，这非常适合用在已经推送到远程的公共分支上。
bash复制# 撤销指定提交，需要拿到它的提交哈希
git revert a1b2c3d
执行后 Git 会创建一个新的反向提交，记录里能看到“谁在什么时候撤销了哪个提交”，审计性比直接删提交好得多。
revert 和 reset 是两类不同场景的工具，我把区别整理成了一张表：
| 对比项 | git revert | git reset |
|---|---|---|
| 是否改写历史 | 不改写，新增一个反向提交 | 改写，移动 HEAD 指针 |
| 适用场景 | 已推送的公共分支 | 尚未推送的本地提交 |
| 风险级别 | 低，可追溯 | 较高，特别是 --hard |
| 对工作区的影响 | 有独立的提交记录 | 取决于模式 |
记住一个原则：凡是已经推送出去、别人也可能基于它继续开发的提交，优先用 revert；凡是只存在于你本地的提交，才考虑用 reset。
4.3 reset：本地回退的三种模式
git reset 用于把当前分支的 HEAD 指针移动到某个更早的提交，影响范围由模式决定。
bash复制# 只移动 HEAD，保留暂存区和工作区改动（回到 git add 之前）
git reset --soft HEAD~1
# 移动 HEAD 并清空暂存区，但工作区里的文件改动保留
git reset --mixed HEAD~1
# 移动 HEAD，暂存区和工作区都回到指定提交的状态，之后的改动会被丢弃
git reset --hard HEAD~1
HEAD~1 表示当前提交的父提交，也就是“上一个提交”。如果只是觉得最近一次提交的内容不对，但文件本身还需要保留，用 --soft 或 --mixed 就能把提交“拆开”，重新整理后再提交。--hard 是最危险的模式，它会彻底丢弃工作区里未提交的改动，使用前务必确认这些改动真的不要了。
我自己的习惯是：commit 后发现漏了内容，先用 --soft 退回来，补全后再重新提交；只有确定一整批提交都是废操作才会考虑 --hard。另外，git reset --hard 之前最好先记录当前的提交哈希，万一后悔还能找回来。
5. 远程仓库、IDE 与小乌龟：把 Git 按自己的习惯组装起来
5.1 clone 的认证细节：HTTPS 带口令与 SSH 免密
从远程仓库拉取一个全新仓库，用的是 git clone：
bash复制git clone git@gitee.com:yourname/yourproject.git
这是 SSH 方式，免密且安全。但有时候别人给你分享的是 HTTPS 链接，比如 https://gitee.com/yourname/yourproject.git，直接用这个地址 clone，push 时会被要求输入账号和密码。如果你需要在不配置凭据管理器的情况下自动认证，可以在 URL 里带上账号和密码：
bash复制git clone https://用户名:密码@gitee.com/yourname/yourproject.git
但我个人不推荐这种做法：密码会出现在终端历史记录和克隆目录的配置里，存在泄露风险。更好的做法是配置凭据管理器（Windows 上装 Git 时默认选项里就有这个）或直接用 SSH 方式。这里提醒一句，如果看到别人分享的 clone 命令里带有密码，请提醒对方尽快修改密码，因为这种形式的地址一旦被截图或复制出去，密码就暴露了。
5.2 IDEA 和 VSCode 里的 Git 操作差异
很多初学者是从 IDE 里的 Git 功能入门的。VSCode 左侧的“源代码管理”面板可以看到所有改动文件，有暂存、提交、推送的按钮；IDEA 则有专门的 Git 工具窗口，支持图形化查看提交历史、分支图和 diff。
但 IDE 的 Git 功能偶尔会出幺蛾子，热搜里“idea git 不显示 commit”就是典型问题。排查思路通常分三步：
- 确认当前项目是不是 Git 仓库，目录下有没有
.git文件夹；不是就用git init初始化。 - 检查 IDEA 的 Version Control 设置里，Git 可执行文件路径是否正确，指向了
git.exe。 - 确认 Java 环境没问题（IDEA 的 Git 功能依赖 JDK），部分异常在升级 IDEA 或 JDK 后自动消失。
对于初学者，我的建议是：日常操作先用命令行，把 add、commit、push、分支这些概念搞懂，IDE 的图形面板用来“看”而不是“做”。等你对命令足够熟悉，再切换到 IDE 提交也不迟，这时即使 IDE 报错，你也能判断出问题出在 Git 本身还是 IDE 的集成上。
5.3 命令行和图形化工具如何混用
TortoiseGit（小乌龟）是 Windows 上的老牌 Git 图形客户端，安装后会在右键菜单中提供 Git 操作，很适合习惯资源管理器操作的用户。Git 官方也自带一个 git gui，能完成基本的暂存、提交、查看历史操作。
工具之间不是非此即彼的关系。我的实际使用组合是：命令行负责一切关键操作（创建分支、合并、回滚、变基），IDE 负责查看（阅读 diff、浏览历史、查看分支拓扑），偶尔用 TortoiseGit 做文件级别的比较和提交。这种组合方式的好处是既能在命令行中保持对操作逻辑的清醒，又能在图形界面里快速获得直观信息。
工具选什么样的不重要，重要的是有一个清晰的 Git 心智模型。概念通了，任何工具在你手里都只是换了一层皮。
6. 高频报错实录：从环境变量到编码问题的排查思路
6.1 “git”无法识别为 cmdlet、函数脚本文件或可运行程序的名称
这个报错在 Windows 上出现频率极高，信息大致是：“git : 无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称。” 它本身不是代码问题，而是系统找不到 git 可执行文件。
排查顺序是这样的：
- 先确认 Git 是否真的安装了，打开开始菜单找一下有没有 Git Bash 或 Git GUI。
- 如果安装过，检查环境变量 PATH 里有没有 Git 的
cmd目录，比如C:\Program Files\Git\cmd。 - 改完环境变量后，务必重开一个终端窗口。环境变量的变化不会自动同步到已打开的窗口。
执行 where git 能在 Windows 上显示 git 实际路径，如果命令能找到路径但 PowerShell 还是报错，通常就是终端没重启的问题。这类问题排查起来不难，难的是对“环境变量”本身缺乏概念，所以多说一句：系统环境变量是全局的，用户环境变量只对当前用户生效，把 Git 的路径配到哪一层要看你的需求。
6.2 中文文件名显示为八进制转义的处理
另一个让很多国内开发者困惑的现象：git status 或 git log 里，中文文件名显示成了一大串类似 "\344\270\255\346\226\207.txt" 的内容，完全看不出是什么文件。
这不是乱码，而是 Git 默认把非 ASCII 字符转义成了八进制表示，为了保证跨平台兼容性。如果想直接显示中文文件名，只需要执行一次：
bash复制git config --global core.quotepath false
改完之后，中文文件名就会正常显示。这个配置对仓库内容没有任何影响，纯粹是显示层的行为。连续输入中文文件名时，尽量用双引号包住完整路径，避免空格和中文混在一起时出现解析问题。
6.3 一长串 git -c 参数到底是什么
用过 IDEA、Android Studio 或者 TortoiseGit 的人，可能在 IDE 的 Git 控制台里见过这样一条命令：
bash复制git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks -c credential.helper= -c core.quotepath=false -c receive.denyCurrentBranch=... ...
看着吓人，实际上就是图形工具在底层调用 Git 时附加的运行时参数。-c key=value 的语法表示临时覆盖某个配置项，只在这一次命令执行中生效，不改动仓库或全局配置。例如 diff.mnemonicprefix=false 是让 diff 输出用 a/ b/ 这样的前缀，方便 IDE 解析；core.quotepath=false 是避免中文路径被转义；--no-optional-locks 表示不获取可选锁，避免某些只读操作（比如 status）意外触发索引刷新导致性能抖动。
看到这种长命令不用慌，它是 IDE 在替你调用 Git，本质上和你手敲命令没有区别。如果你想验证，把这段命令复制到终端手动执行，结果和界面里看到的行为是一致的，只是 IDE 加了一些便于它解析的参数罢了。
6.4 带账号密码的 clone 命令与安全提醒
前文提到过，如果非要通过 URL 内嵌账号密码来 clone，格式是：
bash复制git clone https://用户名:密码@gitee.com/yourname/yourproject.git
执行完记得检查仓库目录下的 .git/config，其中 remote.origin.url 会保留这个带密码的地址。无论如何都不建议把这样的配置提交到任何仓库，或者截图分享出去。
更稳妥的方案是用 Windows 的凭据管理器：第一次输入密码时勾选记住凭据，之后 Git 会调用系统的凭据存储机制完成认证，密码不会明文出现在配置里。Linux/macOS 下也可以启用对应的 osxkeychain 或 cache 凭据助手。
6.5 关于 .git 目录泄露的防御建议
有一个比较特殊但真实存在的风险点：把项目部署到服务器时，误将 .git 目录一起打包和发布。.git 目录里存着完整的提交历史、远程仓库地址，有时候还包括被删除过的敏感配置，一旦被暴露，相当于把项目的“内脏”全部摊开。
防御方法不复杂：
- 部署前用
.gitattributes或发布脚本显式排除.git目录。 - 在 Nginx、Apache 等 Web 服务器配置中禁止
/\.git路径的访问。 - 代码导出时用
git archive而不是直接复制整份工作目录。 - 定期检查线上返回的响应，避免
.git/config、.git/HEAD这类路径可被公开访问。
这类问题的核心是“不把不该暴露的东西放到线上”，属于部署安全的基础工作，但实际中依然有不少项目因此中招。如果你接手的历史项目里存在这种情况，尽快修正部署流程会是一个非常值得的投入。
最后说一点我个人的使用体会。如果你让我从这么多操作里挑出每天最常用的组合，那一定是：git status 看状态、git diff 看改动、git log --oneline 看历史。这三个命令成本最低、信息量最大，能看到你改了什么、还差什么、走过了哪几步。提交之前先 diff 一遍，提交之后马上 log 确认，再进入下一项工作——这套习惯能让大多数低级失误在变成麻烦之前就被拦截下来。Git 的“基本操作”其实没有想象中那么多，真正拉开差距的是对每次操作背后机制的把握，以及对出错后处理路径的熟悉程度。把这篇文章里的内容过一遍，日常开发中绝大多数场景你都能应对自如了。