这篇是写给刚开始碰 Git 的新手看的。我在带团队和帮同事解决问题的过程中发现大部分人卡住的地方不是命令本身而是搞不清 Git 的工作机制一会儿改了这个一会儿丢了那个最后吓得只敢用 add、commit、push 三板斧。这篇会把这些常用操作一口气讲透从安装配置讲到日常提交从分支合并讲到各种报错排查全部基于我实际踩坑后的总结你在 Windows 或 macOS 上照着敲就行不用背命令大全把这十几个操作练熟日常开发已经非常够用。1. 环境准备装对 Git少走八成的弯路1.1 Git 到底是什么它和 SVN 有什么本质区别很多人上来就装 Git装完却不知道它到底解决什么问题。Git 是一个分布式版本控制系统和更早的集中式版本管理工具 SVN 是两种思路。SVN 就像公司里的共享文件夹所有版本历史都存在中央服务器上你改了文件必须提交到服务器别人才能看到一旦断网或者服务器挂了你连历史记录都查不到。Git 不一样每个开发者本地都有一份完整的仓库包含全部历史记录日常的提交、查看版本、创建分支在本地就能完成。只有需要跟别人协作时才把本地内容推送到远程仓库比如 GitHub、Gitee 或者 GitLab。这个区别带来的优势很直观你提交速度快因为不依赖网络你可以在飞机上、地铁里随便提交远程仓库哪天挂了随便找一个同事的本地仓库就能完整恢复。Git 的另一个核心概念是分支这是 SVN 很难做到的分支的创建和切换在本地几乎零成本所以 Git 工作流可以轻松应对多版本并行开发这也是它成为如今行业主流的原因。1.2 Windows 和 macOS 的安装细节别在第一步翻车Windows 安装 Git 很简单直接去 Git 官网下载安装包但国内访问官网时不时很慢我一般建议直接用国内镜像比如阿里云或者清华的镜像源下载速度快很多。下载下来的 exe 文件安装时大部分选项保持默认即可只有一个地方要注意在选择默认编辑器那里如果你是新手建议保持默认的 Vim 不变虽然 Vim 的操作很反人类但先用熟它等以后你自然会换掉。还有一步在调整 PATH 环境的页面建议选择“Git from the command line and also from 3rd-party software”这个选项会把 git 命令加进系统 PATH让你可以在 CMD、PowerShell 和 Git Bash 里都能直接用 git。如果选成“only use Git from Git Bash”那你的 IDE 和终端可能就找不到 git 命令了。安装完成后在开始菜单或桌面右键菜单里能看到两个东西Git Bash 和 Git GUI。Git Bash 是一个模拟 Linux 终端的工具在 Windows 上体验非常接近 Mac 和 Linux 的开发环境新手刚开始建议只用 Git Bash 输命令别用纯 CMD因为很多在类 Unix 环境常见的命令和习惯CMD 里根本执行不了。macOS 用户可以打开终端输入git --version如果没有安装系统会提示你安装命令行开发者工具直接按提示走就行。也可以先安装 Homebrew然后执行brew install git。Linux 用户则用apt install gitDebian/Ubuntu或者dnf install gitFedora即可。安装完先确认版本git --version能看到版本号说明安装成功。1.3 首次配置用户名和邮箱不设你连提交都做不了Git 安装完之后第一件事就是配置你的身份信息。这不是让你改 Windows 的用户名而是告诉 Git 每次提交代码时署名用谁的名字。这个信息会永久记录在你所有的提交历史里所以要认真填建议用你真实的姓名、网名加一个常用邮箱。git config --global user.name 你的名字 git config --global user.email 你的邮箱--global表示全局配置对当前用户的所有仓库生效。如果你想针对某个仓库单独设置名字可以去掉这个参数改成git config user.name 项目专用名字配置完成后可以用下面的命令查看git config --list你会看到 user.name、user.email 以及一些其他系统级的配置。这里有个隐藏的小坑如果你配置的邮箱和远程仓库的邮箱不一致比如 GitHub 上的邮箱和 Git 配置的邮箱不同那你的提交虽然能推上去但不会正确关联到你的账号头像和绿色的贡献记录都不会出现。我曾经带着这个错误工作了快一个月贡献图上一片空白后来排查半天才发现是邮箱没对上。Windows 用户还需要额外注意换行符的问题。Git 为了兼容不同操作系统默认有一个 autocrlf 的配置。Windows 建议设置成git config --global core.autocrlf true这样 Git 在提交时会自动把回车换行转成 LF 存储在检出时再转回 CRLF避免团队里 Windows 和 Mac 同事之间因为换行符不同产生大量无意义的文件变更记录。不配置这个你可能提交一个文件Git 显示改动了两千行其实只是换行符变了。2. 本地仓库的日常操作这是你以后每天都要敲的命令2.1 两种开始方式从零初始化还是克隆现成项目使用 Git 管理项目有两种常见的开始方式。第一种本地已经有一个项目文件夹你希望它变成 Git 仓库。在文件夹里打开 Git Bash执行git init该目录下会生成一个隐藏的.git目录这就是 Git 的仓库核心所有历史记录、分支信息、配置都保存在里面。注意千万不要手动修改或删除 .git 目录里的文件新手阶段你基本不需要碰它。第二种远程仓库里已经有一个现成的项目你想把它拉下来开发这是工作中最常用的场景执行git clone https://github.com/用户名/仓库名.git比如你要克隆一个开源项目到本地直接复制仓库的 HTTPS 地址或 SSH 地址git clone后面跟上即可。克隆会直接把远程仓库的完整历史、所有分支以远程分支的形式、默认代码全都拉到本地。克隆完成后你不需要再执行git init因为它已经是一个完整独立的 Git 仓库了。判断当前目录到底是不是 Git 仓库最快的方式git status如果当前目录是仓库你会看到类似“On branch master”或者“On branch main”的信息如果你看到fatal: not a git repository (or any of the parent directories): .git说明你不在仓库内或者还没有初始化。这是我见过新手报错率最高的一条提示其实解决方法就一句话先确认你是不是在正确的目录下或者有没有执行过git init。2.2 用存档点思维理解 add 和 commit游戏玩家对 Git 的理解速度往往很快因为 Git 的核心操作和游戏存档很像。你打副本前要存档Git 的git commit就是你的存档点。但和游戏不太一样的是Git 不允许你直接一步存档它把动作拆成了两步git add和git commit。git add的作用是把文件从工作区放进一个叫“暂存区”的中间地带。你可以一次性添加所有文件git add .也可以指定文件添加git add src/main.py git add README.md然后查看当前仓库状态git status你会看到哪些文件还没被跟踪哪些已经被添加到暂存区哪些是已暂存但还没提交的。第一次执行git add .时新手经常把一些不该提交的文件也加进去了比如下载目录、日志文件、IDE 的配置文件。所以使用 Git 管理项目几乎一开始就要配置一个.gitignore文件用来声明哪些文件 Git 永远不用管。.gitignore文件不是写代码而是列规则比如node_modules/ dist/ *.log .DS_Store .idea/这样后面执行git add .时上面这些路径和文件会被自动忽略不会进入暂存区。接着提交git commit -m 初始化项目添加用户登录模块-m后面是提交说明建议用简洁的话描述这次提交做了什么。好的提交信息对你回头看历史极有帮助我见过老同事用一句话把这次改动的原因、涉及模块说得清清楚楚那次之后我就再也不写“update”“修改”这种没营养的提交信息了。2.3 查看历史记录和文件改动log 与 diff 的正确打开方式提交几次之后你想看看历史用git log这会列出当前分支上的所有提交记录包括提交编号一长串四十位的哈希值、作者、时间和提交信息。新手看这个输出觉得太长可以用这几个参数简化git log --oneline git log --oneline --graph --all -10--oneline把每条提交压成一行--graph用 ASCII 字符画出分支走向图--all显示所有分支的提交而不是只显示当前分支-10表示只看最近 10 条。这个组合是我平时查看历史最高频的命令强烈建议记住。如果你想看某个文件相对于上一次提交改了什么或者某次提交到底改动了什么内容用git diff。查看工作区文件和暂存区的差异git diff查看暂存区与上次提交的差异也就是你已暂存但还没提交的内容git diff --cached查看某次提交的完整改动内容先拿到提交编号然后git show 提交编号我自己排查线上问题时一般流程是git log --oneline找提交再用git show看改动范围这个习惯能比打开 IDE 挨个文件翻快很多。3. 连接远程仓库让你的代码不再锁在本地3.1 配置 SSH 密钥实现免密拉取推送本地练熟之后就要和远程仓库打交道了。远程仓库的访问方式主要有 HTTPS 和 SSH 两种。HTTPS 每次推送都要输账号密码虽然可以通过一些方式缓存但 SSH 的方式配置一次后一劳永逸强烈建议学会。生成 SSH 密钥ssh-keygen -t rsa -b 4096 -C 你的邮箱执行后会提示你选择保存位置直接回车用默认位置即可然后会要求你设置一个 passphrase密钥口令这是访问私钥的口令我建议设一个安全性高一层。设置之后每次用这个密钥都会要求输入口令如果你嫌麻烦也可以在生成时留空但那就相当于私钥裸奔你要是把私钥文件拷给别人别人就能直接用你的身份访问仓库。生成完成后在用户目录下会有.ssh文件夹里面有两个文件id_rsa是私钥绝对不要给别人id_rsa.pub是公钥。打开公钥cat ~/.ssh/id_rsa.pub把输出的内容复制。然后登录你的 Gitee 或 GitHub在设置里找到“SSH 公钥”或“SSH keys”把内容粘贴保存。Gitee 和 GitHub 都要求你把公钥贴进去这样才能识别哪个 SSH 客户端可以推送代码。测试是否配置成功ssh -T gitgitee.com第一次连接会提示确认主机指纹输入 yes 回车即可。如果配置成功Gitee 会返回一句“欢迎你xxx”的提示GitHub 则是“Hi xxx! Youve successfully authenticated”。验证之后克隆远程仓库时尽量选择 SSH 地址例如git clone gitgitee.com:用户名/仓库名.git用这个地址推送和拉取全程免密不会遇到 HTTPS 那种每次输账号的烦心事。3.2 关联远程把本地的提交推送上去如果你是在本地执行git init创建的项目现在想推送到远程空仓库流程是先在 Gitee/GitHub 上创建一个空仓库然后复制这个仓库的地址在本地执行git remote add origin gitgitee.com:用户名/仓库名.gitorigin是远程仓库的默认名字相当于这个远程地址的别名后面你操作远程仓库都用这个名字指代它。你可以用git remote -v查看当前关联了哪些远程地址。然后推送git push -u origin main-u是--set-upstream的缩写它的作用是建立当前本地分支与远程分支的追踪关系。第一次推送时加-u之后直接敲git push就够了Git 知道推到哪里。拉取远程更新用git pullgit pull实际上做了两件事先git fetch把远程的最新提交抓取到本地再把远程分支合并到你的当前分支。如果你只想把更新抓到本地先自己看看再决定怎么合并可以只执行git fetch然后本地查看远程分支的状态。新手最容易困惑的就是 push 和 pull 的先后顺序。记住一个原则pull 下来先解决冲突再 push 上去。在团队协作中你 push 之前别人可能已经推了代码此时直接 push 会被远程拒绝Git 会提示你先 pull。你先 pull合并或解决冲突再 push这样基本不会出错。3.3 清除缓存和账号密码解决买断工龄的登录问题用 HTTPS 方式操作 Git 时Git 可能会把账号密码缓存到本地或者你第一次输入时勾选了“记住凭据”导致之后想换账号都换不掉。这类问题的排查首先要看你用的是哪种凭据管理器。Windows 上比较常见的是 Git Credential Manager它会将凭证存储在 Windows 的“凭据管理器”中。想清除账号密码可以打开 Windows 设置搜索“凭据管理器”找到“Windows 凭据”在列表里搜索git开头的条目展开后直接删除即可。下次执行 git 操作时它会重新弹出登录窗口。命令行方式清除如果你只想让 Git 自己重新要求输入账号可以执行git config --global --unset credential.helper不过这个命令只修改配置不会清理已经保存的凭据所以最彻底的还是去操作系统的凭据管理器里删。如果你使用的是git config --global credential.helper store的方式那么账号密码会明文存放在用户目录的.git-credentials文件里你可以打开看看如果觉得不安全可以删掉这个文件再重新执行凭证配置。很多人问到“如何清除账号密码”本质上就是想换账号登录或者担心密码泄露。删除凭证后记得先去 Gitee/GitHub 设置里检查一下你的访问令牌Personal Access Token很多新式登录已经不支持密码了只支持 token用 HTTPS 方式拉取代码时账号填你的用户名密码填 token而不是你的登录密码。4. 分支与合并团队协作的核心战场4.1 创建、切换、删除分支把平行世界玩明白分支可以理解成项目里的“平行世界”你在分支 A 上改代码完全不影响分支 B 上的内容等改完再把 A 合并回主线。查看当前仓库所有分支git branch当前所在分支前面会有一个*号比如* main dev创建并切换到新分支一步到位git checkout -b feature/login也可以用新版命令git switch -c feature/logincheckout -b是老牌写法switch是后来新增的语义更清晰但很多老教程还是用 checkut两个你都得认识。单纯切换到已存在的分支git checkout main # 或者 git switch main删除分支用git branch -d feature/login注意-d会检查这个分支是否已经合并到其他分支如果没有合并它会拒绝删除避免你误删未合并且包含独特改动的分支。如果你确定要强制删除用-D但强制删除后该分支上的提交只能通过 reflog 找回风险较大谨慎使用。日常开发中我习惯在 main 分支上只保留稳定可发布的代码新功能一律开新分支改完测试通过再合并回 main。这样 main 永远是可以直接部署的状态队友也不会突然拉到一个写到一半的功能分支。这个习惯在团队合作中极其重要相当于给你的代码上了“保险”。4.2 合并分支merge 与 rebase 怎么选把 feature 分支合并到 main 分支最直接的方式是git checkout main git merge feature/loginmerge会把两个分支的历史合并成一次新的“合并提交”它的好处是保留了真实的开发历史谁在什么时间做了什么清清楚楚坏处是如果频繁合并历史图会变得很杂乱出现很多“分叉再合并”的结。另一种合并思路是rebasegit checkout feature/login git rebase main它的作用是把 feature 分支的提交“重新放”到 main 分支的最新提交之上相当于把你的分支基座移动到了主干部的新位置上最终历史是一条直线干净利落。很多开源项目要求提交历史必须是线性的就是提倡用 rebase。但 rebase 有一个大坑它改变了提交历史所以只建议在还没有推送到远程的本地分支上使用。如果这个分支已经推到了远程别人也基于它开发了你再用 rebase 重写历史别人下次拉代码会立刻遇到一堆冲突甚至完全对不上号这就是经典的“改历史被骂”事件。日常团队协作我建议这样对待场景推荐方式原因自己的功能分支并回主线rebase保持历史线性干净避免无意义的合并节点多人长期共享的分支merge保留真实协作历史不会搞乱别人的远端分支只是想快速把别人最新改动同步下来pull默认merge最简单直接出现冲突再手动处理4.3 解决冲突最怕但不难的一关合并或拉取代码时出现冲突是最常见的“翻车现场”。所谓冲突就是两个分支修改了同一个文件的同一段内容Git 不知道你到底想保留哪个版本只能把选择权交给你。冲突发生时Git 会在冲突文件里插入特殊的标记 HEAD 这是当前分支比如 main的代码 这是被合并分支feature/login的代码 feature/login当你看到一堆这种标记时不要慌也不要把文件直接删了重新下做法是打开这个文件把冲突区间中不需要的版本删掉保留你真正想保留的内容同时把 HEAD、、 feature/login这三行标记全部删掉。编辑完成后git add 冲突文件 git commit -m 解决冲突合并登录模块合并操作就完成了。如果你用的是git merge在解决所有冲突后执行git merge --continue也行如果你用的是 rebase 出现冲突解决后执行git rebase --continue会继续完成剩余提交的变基。无论哪种方式如果解决到一半发现情况不对想退回操作之前的状态用git merge --abort或git rebase --abort这个命令会把你安全地带回到冲突发生之前百试百灵。新手解决冲突时最容易犯的错误是直接在冲突标记里删一增一却没有想清楚两个版本的业务逻辑差异结果合出一个半吊子代码测试才炸。我的建议是涉及同一个函数的冲突优先看两个版本各自的上下文理解两边为什么要改再决定是保留一边、两边融合还是找写的同事确认。业务理解不清的冲突宁可多问几句也别硬合。4.4 顺带认识 git worktree多分支并行编辑的利器如果你所在的项目用 Git 多年一定遇到过“我现在在这个分支但需要同时看一下另一个分支里的某个版本代码”这种需求。常规操作是先 commit 当前改动再切换分支看完再切回来来回折腾不仅浪费时间还有可能把还没改完的东西带过去。git worktree能让你在同一个仓库里同时存在多个工作目录每个目录对应一个不同的分支。也就是说你可以一边在 main 分支目录里敲代码一边在另一个目录里打开 feature 分支看旧代码互不干扰git worktree add ../my-project-feature feature/login这会在上级目录创建my-project-feature文件夹并把feature/login分支检出来放在里面。用完想清理git worktree remove ../my-project-feature git worktree prune这个命令对真实项目排查“线上问题但本地正在开发新功能”的场景非常管用你不需要暂停当前进度就能抽出一个干净目录去看线上分支。我第一次用 worktree 时感觉打开了新世界强烈建议所有技术人在本地环境允许时都把它用起来。5. 后悔药系列改错、漏提交、误删分支的补救方法5.1 用 --amend 修改最近一次提交提交写错了比如注释写错字、漏了一个文件就想把这次提交“拆开重来”。Git 提供的补救命令是git commit --amend这个命令会把暂存区里的内容和上一次提交合并生成一个新提交。如果你只是改提交信息直接执行后进入编辑器修改信息保存即可。如果你想追加漏掉的文件先 add 再 amendgit add 漏掉的文件 git commit --amend --no-edit--no-edit表示不修改提交信息只把漏掉的文件补进上一次提交。注意该命令会改写提交编号所以和 rebase 一样如果这个提交已经推送到远程并且别人拉取过就不要 amend 了不然又是一场历史冲突。还没推送的提交请随便 amend。有人问能不能改更早的某一次提交比如倒数第二次这是 rebase 交互模式的领域新手先不要碰先把 amend 用好通常已经解决大多数场景了。5.2 reset 的三种模式以及反悔套娃如果你 add 了一个不该 add 的文件或者提交了一个不该提交的内容想撤销到之前的状态git reset是主要的工具。它有三个核心模式git reset --soft 目标提交 git reset --mixed 目标提交默认 git reset --hard 目标提交区别在于三个状态区工作区你的实际文件内容、暂存区add 之后的中间区、版本库commit 之后的历史。--soft只移动 HEAD 指针工作区和暂存区都不动相当于把提交记录“取消掉”但你的改动全部还在最适合“我 commit 错了但代码本身没问题重新 commit 一次就行”。--mixed是默认模式会把暂存区也清除但工作区文件内容不变相当于把 add 和 commit 都撤销了所有改动回到未 add 状态。--hard最危险它会把工作区、暂存区、版本库全部恢复到目标提交的状态你在工作区里所有未提交的修改都会消失文件直接变成目标提交的那个版本。举个例子你提交了五次想回到前三次提交时的状态但保留当前所有改动的文件内容git reset --mixed 前三次提交的编号执行后最近两次提交被“隐藏”了你的工作区文件还是当前最新的只是不再被 Git 跟踪成已提交状态你可以重新整理后再次提交。如果你想要彻底回到某个历史版本丢弃之后所有提交git reset --hard 历史提交编号这条命令执行前务必确认两点这个分支是不是你专属的分支有没有把所有需要保留的东西都推到了远程我见过不止一个同事在共用的开发分支上执行了--hard然后把队友几天的代码直接“蒸发”了最后靠 reflog 抢回来。5.3 reflog找回丢失的提交git reset和git branch -D之后你可能会误以为某些提交彻底没了。其实 Git 的 reflog 会保留你在本地仓库里的每次 HEAD 移动记录包括 reset、commit、merge、checkout 等所有操作时间窗口通常是 30 天到 90 天。执行git reflog你会看到类似这样的输出a1f2b3c HEAD{0}: reset: moving to a1f2b3c d4e5f6g HEAD{1}: commit: 添加登录功能HEAD{0}是最近一次操作HEAD{1}是上一次。如果你发现自己 reset 太狠了想回到 reset 之前的那个提交找到对应的提交编号然后git checkout d4e5f6g或者把分支指针指回去git reset --hard d4e5f6greflog 是我处理“git 误操作”的最强杀器很多人不知道它的存在遇到误删只会蹲在工位上唉声叹气。记住这句话在 Git 里只要你在本地执行过 commit绝大多数情况下它的数据都能通过 reflog 找回来。唯一让数据彻底消失的方法是执行git gc --prunenow之类的手动清理以及本地仓库文件被物理删除。5.4 用 checkout 恢复单个文件还有一种更常见的“后悔”场景你改了半天代码发现还是回到改之前比较好此时git reset --hard会把所有文件都带回去太重了。单独恢复某一个文件用git checkout -- 文件名这个命令会把工作区里的指定文件恢复到暂存区中的版本。如果你的文件已经修改但还没 addgit checkout -- 文件名会把它恢复成上次提交的样子你的修改全部丢失。如果你已经 add 了想恢复到暂存区的版本也可以但如果你 add 之后又修改了这个命令恢复到的是暂存区的版本也就是 add 那一刻的内容。需要注意恢复文件之前务必看好内容真丢了还没有补救机会。如果想放弃从某个提交开始对文件做的修改直接用那个提交的版本覆盖git checkout 提交编号 -- 文件名这样可以精准恢复任意历史版本的文件而不影响其他文件。6. 新手高频报错排查实录这些问题我都被烦过无数次6.1 fatal: not a git repository 的常见场景“not a git repository (or any of the parent directories): .git”这条错误是新手遇见率最高的三大报错之一但原因其实很简单Git 在当前目录及其父目录里都没找到.git文件夹说明当前目录根本不是仓库或者不在仓库的子目录里。排查思路就这么几步第一确认你对当前目录执行过git init或者这个目录是从别人那里 clone 下来的第二如果你的项目是放在磁盘子目录里的注意你执行命令的终端目录是不是真的在项目目录内有时候你在C:\Users\你的名字下敲git status它当然报 not a repository第三检查你有没有把.git目录删除过。用pwdGit Bash 里或者cd到正确目录然后重新git status就好。碰到这个错误不用重新 init 或者 clone只要定位到正确的仓库根目录就行。6.2 SSH 认证失败Permission denied (publickey)报错长这样gitgitee.com: Permission denied (publickey).多半是本地密钥和远程账号没有建立关联。排查步骤从生成密钥是否成功开始再到公钥是否已粘贴进 Gitee/GitHub再到远程地址是不是用了 SSH 形式。有个超高频的细节错误克隆仓库地址用的是https://开头但本地密钥配的是 SSH 的结果夹在 https 和 ssh 之间自相矛盾。HTTPS 地址不依赖 SSH 密钥它走的是账号密码或者 token只有git开头的地址才走 SSH。补充一个常被忽略的点如果你换了台电脑或者重新装过系统.ssh目录里没有私钥文件Git 不会自动生成你需要先生成密钥、再上传公钥这一套流程配好后才能免密。6.3 IDE 提示 Login failed. Check API Token or GitLab version这个报错通常出现在 IDEA、VS Code 这类 IDE 内置 Git 工具使用 GitLab 时。常见原因是仓库地址变了、密码或 token 过期了或者 GitLab 升级后老版本的 token 接口不再兼容。解决方法不是去改仓库地址而是先找到 IDE 里保存的凭据删掉后重新登录。在 IDEA 中通常是设置里的 Appearance Behavior 下面的 System Settings - Passwords把保存的 GitLab 凭据清掉VS Code 则是通过命令面板输入 “Git: Clear Credentials” 或者清理 Keychain/WinCred。这一步清理完下次 push 时会重新弹出登录窗口输入新的 token 即可。如果你用的是个人访问令牌检查一下 token 权限设置了哪些 scope至少要有read_repository和write_repository。6.4 中文文件名乱码与 core.quotepathWindows 上使用中文文件名执行git status时看到类似\346\265\213\350\257\225.txt这种八进制转义这是 Git 默认行为导致的因为配置项core.quotepath默认为 true会把非 ASCII 路径转义。解决办法git config --global core.quotepath false设置后中文文件名会正常显示。我在团队里要求所有 Windows 同事必须设置这一项否则看 status 和日志时永远看不懂改的是哪个文件。你搜热词时看到的git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks这一长串其实是一些 IDE比如 IDEA在调用 Git 时自动附加的配置参数其中quotepathfalse和这个配置一致。--no-optional-locks则是让 Git 在某些只读操作时不上锁避免和 IDE 自身的文件状态检查冲突。6.5 不要忽视的隐患学 Git 的同时学会保护好仓库最后说一点新手很少注意到的问题不要把本地生成的.git目录误传到线上或者公开到外网。有些朋友项目里包了一层 git 目录打包发布时没排除掉导致线上环境能直接被人顺藤摸瓜下载到完整源代码和历史版本这就是常说的“git 目录泄露”风险。在你自己的项目里养成写.gitignore和检查打包配置的习惯确认.git和敏感配置文件不会被打进部署产物。这个习惯越早养成越好等出了事故再补课成本很高。6.6 报错信息速查表报错/现象核心原因快速解法fatal: not a git repository当前目录无 .git 仓库cd到仓库根目录或git initPermission denied (publickey)SSH 公钥未配置/私钥缺失检查ssh-keygen和远程公钥配置Login failed. Check API TokenIDE 凭证过期或 token 失效清除 IDE 凭据重新登录填 token中文文件名八进制转义core.quotepathtruegit config --global core.quotepath falsepush 被拒non-fast-forward远端有新提交本地落后先git pull解决冲突再 push想放弃合并/变基但一时混乱合并产生了大量冲突git merge --abort或git rebase --abort我建议新手把这张表截个图存着遇事先照表操作再深入理解原理。Git 的报错信息很多时候并不是说“你操作错了”而是在提示你“当前状态不允许这样操作”理解这个思路你会更快从报错中走出来。我个人在实际操作中的体会是Git 看似命令繁多但日常高频使用的核心命令其实就二三十个。先把 init、add、commit、push、pull、branch、merge、log、status 这九个命令练到肌肉记忆再逐步扩展 checkout、reset、reflog、worktree 这些东西你的 Git 使用水平已经能超过大部分同事了。真正的进阶不是记更多命令而是搞懂 Git 的三个区、分支指针、HEAD 这些底层概念当你理解 Git 其实是在操作一个有向图的时候很多命令的行为会自然而然地变得合理。