这篇文章不打算从版本控制的学术定义讲起也不会在开头堆一堆“Git是分布式版本控制系统”之类的标准解释。我直接按一个日常写代码的人的实际需求来说在一台新电脑上把 Git 装好让 IntelliJ IDEA 能正常拉取和提交项目再把平时敲得最多、又最容易记混的那批命令梳理一遍。这三个点串起来基本就是新人入职配环境、老手换电脑恢复开发状态的完整闭环。如果你属于下面几种情况这篇文章正好能帮你省时间刚入职需要在新电脑上配置环境用 IDEA 很长时间但只知道点右上角那几个按钮命令行一窍不通或者每次提交代码都顺利一旦遇到冲突、回退、合并出错就懵住不知道怎么用 Git 自己解决。这套流程我自己走过很多遍所以下面写得比较细能带参数的地方就带参数能解释“为什么”的地方也不会跳过毕竟一条命令出错的原因往往藏在当初安装时漏掉的一个勾选里。1. 动手之前先搞明白Git到底在帮你管什么1.1 Git不是网盘理解这一点很重要很多人第一次接触 Git 时会习惯性把它理解成“一个用来存代码的网盘”。这个类比能帮你快速上手但也会埋下隐患。网盘的核心是“同步”你把文件拖进去云端有一份别人也能看到而 Git 的核心是“版本快照”它记录的是每次提交之后整个项目的状态而不是单纯的文件本体。Git 采用分布式架构每个开发者git clone下来的仓库都是一个完整副本包含全部历史提交记录。这意味着即使没有网络、远程服务器挂了你依然可以本地提交、查看历史、创建分支。等网络恢复后再把本地提交推送到远程。这个特性在你通勤路上、飞机上写代码时非常有用也是 Git 区别于 SVN 这类集中式版本管理工具的根本原因。理解这一点后你就能明白为什么 Git 里最常见的操作是“先提交到本地仓库再推送到远程”而不是直接“保存到服务器”。很多人刚入门时总是分不清commit和push其实就是没建立本地仓库与远程仓库的概念。1.2 三个区域与一条完整流程Git 的日常操作围绕三个区域展开工作区、暂存区、本地仓库。工作区就是你在 IDEA 里看到的那些文件暂存区是提交前的临时存放点本地仓库则是已经提交、有了版本记录的历史存档。远程仓库不属于本地它是你与他人协作的中转站。一次标准的提交流程是这样的修改工作区文件 →git add把改动加入暂存区 →git commit把暂存区内容固化为本地仓库的一个新版本 →git push推送到远程仓库。很多人最初只点 IDEA 的 Commit 按钮没意识到 IDEA 在背后帮你做了一次add和一次commit所以当命令行出现“Changes not staged for commit”这种报错时完全不知道是什么意思。我建议初学者不要把三个区域当成死记硬背的概念而是用一个场景去理解你正在写一篇论文工作区是书桌上摊开的稿纸暂存区是你挑出来准备放进信封的几页纸本地仓库是已经塞进抽屉的信封远程仓库则是寄到导师手里的那份。想清楚自己当前的文件到底在哪个位置Git 的大部分命令出错原因都能自己定位。1.3 别慌IDEA和Git命令并不冲突有一部分开发者坚持只在 IDEA 图形界面里操作 Git另一部分坚持纯命令行两边互相看不顺眼。我的看法是这两者完全可以混合使用而且应该混合使用。IDEA 的图形化操作适合查看文件状态、做代码审查、处理冲突这种需要可视化信息的场景命令行则适合批量操作、写脚本、在服务器上处理问题时使用。说白了你不需要在 IDEA 里禁用 Git 插件去练命令行也不需要为了显得专业而强迫自己在终端里敲所有命令。两种方式操作的是同一个.git目录结果完全一致。这篇文章后半部分会同时给出对应的图形操作和命令行操作方便你在两种方式之间自由切换。2. 安装配置从下载到敲出第一条git命令2.1 Windows安装勾选选项比想象中更重要Windows 用户要做的第一件事是去 Git 官网下载安装包。官网地址是 git-scm.com下载页面会自动识别你的操作系统直接点 Windows 版本就好。这里要提醒一句Git 官网的下载速度偶尔会不稳定如果打不开或速度很慢也可以从国内一些正规软件源下载但要学会比对安装包的版本号和哈希值避免下载到被篡改的文件。下载好 exe 后双击运行安装向导里大部分选项保持默认即可但有几步需要认真对待。第一步是选择安装路径建议不要装在带空格的目录直接C:\Program Files\Git通常没问题不过如果你有洁癖可以放到D:\Git后面配置 PATH 时更方便。第二步是选择组件默认勾选 “Git Bash Here” 和 “Git GUI Here” 就行这是右键菜单里快速打开终端的功能实测在 IDEA 里遇到问题时非常好用。真正需要动脑子的是 “Choosing the default editor” 这一步我默认你是用 IDEA 写代码的所以选 “Use Visual Studio Code” 或 “Use Nano” 都行但千万别选 Vim。不是 Vim 不好而是对一个不熟悉 Vim 操作的人来说某天 commit 时需要输入提交信息结果终端卡在 Vim 界面里无法退出那种感觉真的很崩溃。最关键的选项是 “Adjusting your PATH environment”。这里一定要选 “Git from the command line and also from 3rd-party software”也就是第二个选项它会把 Git 加入系统 PATH让你能在 CMD 和 PowerShell 里直接使用git命令。如果这里误选了 “Use Git Bash only”后面在 IDEA Terminal 面板里运行git会直接提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”到时候还得手动去改环境变量非常麻烦。2.2 macOS和Linux用户安装GitmacOS 用户可能觉得系统自带 Git因为在终端里输入git --version一般都有输出。但那实际上是系统自带的 Xcode Command Line Tools 版本版本号可能比较旧。建议通过 Homebrew 安装最新版brew install git安装完成后留意一下终端提示Homebrew 会告诉你新 Git 的实际路径通常出现在/opt/homebrew/bin/git。如果运行git --version仍然显示旧版本需要检查 PATH 顺序确保 Homebrew 的 bin 目录在/usr/bin之前。这步完成后Git 就是真正属于你自己的版本了。Linux 用户更简单Debian/Ubuntu 系使用sudo apt update sudo apt install git -yCentOS/RHEL/Fedora 系使用sudo yum install git -y不要为了追求最新版本去编译源码大多数发行版仓库提供的 Git 版本已经足够日常使用编译安装只会浪费时间还可能引入系统库依赖问题。2.3 验证安装结果无论哪个平台装完后的第一步都是打开终端输入git --version能看到类似git version 2.39.2.windows.1的输出说明安装成功。接着输入git --help如果弹出帮助信息而不是报错说明 Git 已经被正确加入 PATH。我见过最典型的安装问题是安装时没注意 PATH 选项终端里输什么都说“命令不存在”但 Git Bash 却能用。如果你正卡在这一步最快解决办法是重装一遍 Git在 PATH 选项处选择第二项然后重启终端这个坑基本就能绕过去。到这里你的电脑已经具备 Git 能力了。但先别急着 clone 项目要是不做下面这步基础配置提交代码时会遇到一些让人困惑的问题。3. 新装Git后第一时间要完成的3个配置3.1 告诉Git你是谁的两种方式安装完 Git 后第一件事是配置用户名和邮箱。这个配置不是可有可无的因为你每次git commit时Git 都会把这两个信息写入提交记录代码评审人、团队其他成员看到的提交者姓名就是从这来的。git config --global user.name Your Name git config --global user.email youexample.com--global表示全局生效也就是说这台机器上所有仓库的提交都会使用这个身份。如果你在不同平台比如 GitHub、GitLab、公司内网 Git有不同的账号可以考虑不用--global而是进入单个仓库目录后去掉--global为当前仓库单独设置。但绝大多数情况下一台电脑一个身份就够了配置太复杂反而容易在多个账号间来回切换时出错。验证配置是否生效git config --global --list执行后能看到类似下面的输出说明配置成功user.nameYour Name user.emailyouexample.com这里要特别提醒一个细节这里的邮箱配置不一定要和你的登录邮箱完全一致但最好保持一致这样你的提交才能和你的账号头像关联起来。有些 Git 平台支持“私人邮箱”功能比如 GitHub 提供usernameuser.noreply.github.com这类匿名邮箱你要想隐藏真实邮箱可以使用这种格式但必须先在平台后台查看你的专属 noreply 地址。3.2 配置SSH密钥以后不用每次输账号密码配置好身份信息后第二个重要步骤是设置免密登录。如果你用 HTTPS 方式 clone 项目每次 push 都需要输入账号密码某些平台甚至要求输入 Personal Access Token操作很繁琐。改成 SSH 方式后只要把公钥放到 Git 平台后台以后就可以完全免密操作。首先生成 SSH 密钥对ssh-keygen -t ed25519 -C youexample.com-C后面的注释建议填你的邮箱不是必须但多平台使用时会帮你区分密钥用途。执行后终端会提示你选择保存路径直接回车使用默认的~/.ssh/id_ed25519即可接着会提示设置 passphrase如果设置了每次使用密钥时都要输入一次密码不设置则直接回车跳过。这里我推荐设置一个简单的 passphrase虽然多了一步输入但私钥泄露后还有一道防线。如果你觉得麻烦也完全可以不设置。生成后查看公钥内容cat ~/.ssh/id_ed25519.pub把输出的整段内容复制然后登录你的 Git 平台GitHub、GitLab、Gitee 等在个人设置里找到 “SSH Keys” 或 “SSH and GPG keys”粘贴保存即可。测一下连通性ssh -T gitgithub.com首次连接会提示是否确认 host key输入yes回车。看到类似Hi username! Youve successfully authenticated, but GitHub does not provide shell access.的输出说明 SSH 配置成功。接下来 clone 项目时选择 SSH 链接以后 push 和 pull 都不需要输入密码了。3.3 处理换行符差异CRLF与LF问题这是 Windows 用户最容易遇到的坑也是最容易被忽略的问题。Windows 系统里的文本文件默认用\r\n作为换行符Linux 和 macOS 则用\n。如果同一个文件在不同系统间反复切换换行符Git 会认为整个文件都发生了变化代码评审时看到一堆毫无意义的 diff非常难受。Git 提供core.autocrlf参数来解决这个问题。如果你主要在 Windows 上开发建议设置git config --global core.autocrlf true这个配置的意思是提交时把 CRLF 自动转换成 LF 存入仓库检出时再把 LF 转换回 CRLF。这样仓库里保存的统一是 LF但工作区在 Windows 上保持 CRLF编辑器不会因为换行符告警。纯 macOS 或 Linux 用户则可以设置git config --global core.autocrlf input表示提交时把 CRLF 转成 LF检出时不转换也就是保持 LF。如果你的团队已经约定统一使用 LF并且编辑器和 IDE 都已配置为“强制 LF”也可以把这项设为false完全不转换。但跨平台协作项目里true和input这两个值基本覆盖了绝大多数场景。检验换行符是否正常的方式是打开命令提示符对某个文件执行file命令或者用编辑器右下角的状态栏查看当前文件的换行符。一个成熟的项目仓库里应该保持统一的行尾风格你可以通过仓库根目录的.editorconfig文件来约束也可以在.gitattributes文件里标记哪些文件使用什么换行符。后者更强大以后有机会可以单独写一篇展开。3.4 顺手创建全局.gitignore有些文件你永远不希望提交到 Git比如 IDE 的配置文件、操作系统生成的临时文件、依赖包目录。IDEA 项目里常见的被忽略内容有.idea/目录、*.iml文件、target/目录、.DS_Store文件、node_modules/目录、*.log文件等。你可以用一条命令创建全局忽略文件git config --global core.excludesfile ~/.gitignore_global然后编辑这个文件把常见的 IDE 临时文件、系统文件写进去。平时在项目仓库存活率高的时候应该在各自的.gitignore里维护项目级的忽略规则团队保持一致。全局忽略只负责“本机通用”的那部分比如Thumbs.db这类 Windows 缩略图缓存或者.idea/workspace.xml这种个人状态文件。我在实际工作中见过不少人因为没配.gitignore把node_modules提交进了仓库结果仓库体积飞速膨胀clone 一次要等很久。这种问题一旦发生要从历史记录中彻底清理非常麻烦所以防患于未然永远是第一位的。4. 用IDEA把一个Git项目导入并跑起来4.1 方式一直接从IDEA克隆远程仓库IntelliJ IDEA 自带 Git 集成这是目前最省事的项目导入方式。打开 IDEA在欢迎界面点击 “Get from VCS”或者菜单栏选择 “File” → “New” → “Project from Version Control”输入远程仓库 URL选择保存目录点击 Clone 即可。IDEA 会自动识别你当前使用的 Git 版本如果 Git 没有正确安装或配置这里会直接报错。首次 Clone 完成后IDEA 右下角会弹出通知提示是否导入为 Maven 或 Gradle 项目这时候要根据你的项目类型来选择。如果你打开的是一个 Spring Boot 项目右下角会有 “Load Maven Project” 或 “Load Gradle Project” 的提示点击后 IDEA 开始下载依赖。这一步会根据网络情况持续一段时间你需要耐心等待。等依赖下载完、控制台不再刷日志后项目就可以跑了。一个容易忽略的细节是clone之后 IDEA 默认会切换到你在远程仓库默认分支上的最新代码通常是main或master分支。如果你发现自己看不到某些分支不是代码丢了而是本地还没有创建对应的跟踪分支通常git fetch一下就能看到所有远程分支。4.2 方式二先clone再用IDEA打开严格来说 IDEA 已经替代了手动 clone 的必要性但有些场合你还是需要先在终端里 clone。比如你想把项目放到某个特定的深层目录或者需要套一层代理、带一系列 clone 参数时终端操作会更灵活。手动 clone 的命令是git clone gitgithub.com:some-user/some-project.git命令执行完成后工作目录下会生成一个与仓库同名的文件夹。接着打开 IDEA选择 “Open”定位到这个文件夹选中后 IDEA 会校验它是否包含构建系统文件。如果包含pom.xml会按 Maven 项目打开如果包含build.gradle会按 Gradle 项目打开如果只有package.json会根据你安装的 Node 插件情况提示。这种方式的优点是可以控制更多细节例如只克隆指定的分支git clone -b develop gitgithub.com:some-user/some-project.git如果仓库很大、历史提交特别多甚至可以只克隆最近一次提交git clone --depth 1 gitgithub.com:some-user/some-project.git但注意--depth浅克隆会丢失历史后续需要深挖历史时会很不方便一般不建议在常规项目里使用。如果你只是在临时验证某个功能浅克隆能省下不少时间。4.3 导入Maven/Gradle项目时最容易漏的坑很多新人在 IDEA 里打开项目后源码一片飘红第一反应是代码有问题。其实多半是依赖没下载完或者本地 Maven 仓库里没有对应版本的依赖包。如果你用的是 Maven 项目打开设置窗口找到 “Build, Execution, Deployment” → “Build Tools” → “Maven”确认“Maven home path”指向的是你本机安装的 Maven 目录。如果你没有单独安装 Maven也可以用 IDEA 自带的 Bundled Maven但要确保它和项目期望的版本兼容。接着检查 “User settings file” 是否引用到了正确的settings.xml很多公司会用私服地址或镜像仓库缺少这个配置会导致依赖下载失败。最后检查 “Local repository” 路径默认在用户目录的.m2/repository下如果你想换个更大的盘符存放依赖可以在这里调整。Gradle 项目则要留意 Gradle 版本与 JDK 版本的兼容性。比如项目要求 Gradle 7.6 和 JDK 17但你的 IDEA 默认运行环境是 JDK 8Gradle 会直接罢工。IDEA 一般会提示你下载合适的 Gradle 版本此时选择信任项目并等待下载即可。打开项目后的第一件事我建议按顺序做这么几步先看看项目是否自动识别了 JDK快捷键CtrlShiftAltS打开 Project Structure确认 Project SDK然后看看 Maven 面板或 Gradle 面板是否能正常刷新最后找项目里有没有README.md很多项目会在里面写清楚前置环境要求。顺序反了的话你可能到最后都不知道自己缺的是 JDK 还是 Maven 还是某个环境变量。4.4 IDEA里常用的Git操作入口导入项目后你要尽快熟悉 IDEA 里的几个关键 Git 操作入口。右上角工具条里的“对勾”图标是 Commit“向下箭头”图标是 Pull“向上箭头”图标是 Push有时候还会有一个 “Update Project” 按钮它会顺手做pull但可能引入额外的 merge 行为。左下角的 Git 窗口默认展开后会显示 “Local Changes”这里可以看到所有被修改的文件。点开文件可以看到 diff红色代表删除、绿色代表新增、蓝色代表修改。默认情况下 IDEA 把文件分成 受版本控制 和 未受版本控制 两个 Section未受版本控制的文件通常是新添加的但没有git add过的文件。IDEA 勾选这些文件执行提交时会自动帮你add。最实用的快捷键建议记牢几个CtrlK调出提交面板CtrlShiftK推送Alt9打开 Git 窗口有些 IDEA 版本也有Alt0或Alt9的差异你可以在菜单里查看当前版本的键位设置。使用图形界面从来不是什么丢人的事关键是你要知道每一步操作背后的 Git 命令是什么这样遇到 IDEA 抽风或执行结果与预期不符时马上开一个终端查看实际状态。5. 常用Git命令按使用场景分组整理命令这一节我不会按git add、git commit、git push的顺序平铺直叙而是按“你当时到底想干什么”来分组。因为实际工作中没有人会背命令字典大家都是遇到具体问题比如“代码提交错了”“分支搞乱了”“临时要切到另一个任务”才知道自己需要哪条命令。5.1 每天都用的本地提交操作改动代码后第一件事是查看当前仓库状态git status这个命令会告诉你有几个文件被修改、哪些是新增的未跟踪文件、当前在哪个分支。git status的提示风格取决于你的 Git 版本新版本会用中文输出简洁的提示如果你的系统语言是中文旧版本则全英文。如果你觉得默认输出太长可以试试git status -s-s表示 short 格式每条记录只占一行修改状态用M、新增用??、删除用D表示一眼扫过去就能知道项目全局。个人非常推荐将git status -s作为高频命令记下来。把文件加入暂存区git add filename.txt # 添加指定文件 git add . # 添加当前目录所有变动 git add -u # 只添加已跟踪文件的改动不添加新增文件git add .是个大招但也容易误伤。如果你没配好.gitignore一条git add .可能把日志文件、打包产物一股脑加进来。更稳妥的做法是先用git status看清哪些文件会被加入再执行git add .或者用git add -p进入交互式暂存一条条预览并确认每个 hunk 是否加入。刚开始用可能觉得繁琐但用过一段时间后反而会喜欢这种可掌控感。提交到本地仓库git commit -m feat: 添加用户登录接口提交信息建议按照团队规范写最常见的风格是 Conventional Commits类型feat/fix/docs/style/refactor/test/chore加冒号加描述。这样通过git log --oneline就能快速定位某个类型的改动。如果你提交时发现git commit自动打开了文本编辑器而你并没有加-m参数那说明你这次提交想写多行信息。多行提交信息在正式项目里很常用它允许你在标题行下空一行再写正文解释背景、影响范围、关联 issue 编号。提交后发现漏了文件可以用git commit --amend --no-edit它会把你暂存区里新增的改动合并进上一次提交且不改变提交信息。--amend还能修改上一次提交的信息git commit --amend -m 新的提交信息需要小心的是--amend会改变提交的 hash所以只适用于还没有推送的本地提交。如果已经 push 到远端再 amend 会造成本地与远端历史不一致强行 push 会非常麻烦。5.2 撤销与回退undo功能要分清楚对象撤销操作是 Git 最容易让人望而生畏的地方因为同样叫“撤销”实际场景千差万别。文件还在工作区、还没执行git add时想把某个文件恢复到上一次提交的状态git checkout -- filename.txt这里的--是告诉 Git 后面跟的是文件路径而不是分支名防止你刚好有一个分支叫filename.txt造成歧义。这条命令会直接丢弃工作区所有未暂存改动请确保你是真的想放弃这些改动再执行。如果你在做实验性修改先git stash会更安全。文件已经git add了、想取消暂存但保留文件内容git reset HEAD filename.txt新版本 Git 也支持git restore --staged filename.txt两条命令效果一样reset是老牌命令restore是 Git 2.23 以后提供的新命令语义更清晰。我建议你新学的话直接用git restore老手用reset也能理解。已经 commit 了、但还没有推送到远程想回退到上一个提交git reset --soft HEAD~1--soft表示只移动 HEAD 指针不修改暂存区和工作区也就是说你回退后改动还留在暂存区可以直接重新 commit。另一个选项是git reset --hard HEAD~1--hard会把工作区和暂存区一起还原到上一个提交回退后所有的代码改动都会丢失非常危险。使用前至少确认自己没有未提交的重要改动。一般我会先运行git log --oneline看清楚提交记录再决定回滚到哪个版本。已经 commit 且已经推送到远程此时不应该再使用git reset因为修改历史会影响其他协作者。正确方式是新增一条反作用的提交git revert HEADgit revert会生成一个新的提交把指定提交的改动全部反向应用。提交历史保持线性不会造成远端历史冲突团队协作时这是最安全的回退方式。如果只想回退某一次特定的提交找到它的 hash 后git revert abc123这个操作会把那次提交改动的代码“反向执行”一遍其他的提交不受影响。5.3 分支操作日常开发离不开这些命令分支是 Git 最重要的设计之一。查看本地分支git branch带-a查看所有分支包括远程分支git branch -a创建并切换分支的几种方式git branch feature/login # 创建分支 git checkout feature/login # 切换分支 git checkout -b feature/login # 创建并切换 git switch -c feature/login # 新版推荐写法git switch是 Git 2.23 后为区分“切换分支”和“回溯文件”两种场景推出的命令语义更清晰。不过git checkout仍然被大量使用两种命令共存于大多数项目里。我个人用git switch处理分支切换用git restore处理文件恢复时间久了感觉大脑记忆负担反而更小。合并其他分支到当前分支git merge feature/login如果你想保持提交历史线性也可以使用 rebasegit rebase feature/loginmerge和rebase的区别是 Git 新人最容易纠结的点。简单说merge保留所有分支的分叉历史可能会产生一个 merge commitrebase把当前分支的提交“搬移”到目标分支顶端让历史变成一条直线。两者没有绝对的优劣关键在于团队约定。团队协作时公共分支上尽可能少用会影响他人的 rebase功能分支上则可以根据喜好自由选择。如果你想彻底弄懂两者的差别实际演练是最快的先开两个分支各自做一些提交merge一次看 log 图谱再rebase一次看 log 图谱一对比就全明白了。删除分支git branch -d feature/login # 删除已合并的分支 git branch -D feature/login # 强制删除未合并的分支强制删除分支时分支上的所有提交都会跟着消失执行前多确认几遍。我一般先用git log --oneline查看一遍确认没有需要保留的提交再执行。5.4 与远程仓库同步fetch、pull、push的细节同步操作是多人协作时最频繁、也最容易出错的地方。先区分一组概念git fetch只把远程仓库的最新状态下载到本地但不会自动合并到你当前的分支git pull则是fetch加自动合并或 rebase。执行完git fetch后你可以通过git branch -r看到远程分支的最新状态然后决定怎么处理。最常见的日常更新命令是git pull但git pull默认采用 merge 合并方式如果本地有提交、远程也有新提交就会产生一个 merge commit。为了保持历史整洁很多人推荐使用 rebase 方式拉取git pull --rebase--rebase会先把本地未推送的提交暂存起来拉取远程最新代码后再把本地提交“叠”到远端提交后面这样历史就不会出现多余的 merge 节点。团队对 Git 历史有洁癖的话建议设置git config --global pull.rebase true这样以后每次git pull都默认使用 rebase。推送代码git push如果是第一次推送新分支到远程需要设置上游分支git push -u origin feature/login之后再次推送只需git push。如果远程已经有人提交了新代码你的 push 会被拒绝Git 会提示你 “non-fast-forward” 或 “fetch first”。此时按顺序执行git pull --rebase # 先拉取并变基 # 解决可能的冲突 git push这是多人协作时的标准节奏。不要用git push --force强制覆盖除非你完全清楚自己在做什么。特别在 public 分支上--force可能会覆盖别人的提交这种事故在团队里屡见不鲜一般是要被严厉批评的。查看本地分支与远程分支的对应关系git remote -v git branch -vv第二条命令会显示当前分支跟踪了哪个远程分支以及领先落后状态。5.5 临时保存stash命令是个救场神器开发中经常出现这种情况正在功能 A 上开发到一半突然被叫去修复线上一个紧急 bug。此时你不想提交半成品代码又需要切换到另一个分支。git stash就是干这个用的。git stash # 保存当前工作区改动回到干净的提交状态 git stash list # 查看保存列表 git stash pop # 恢复最近一次保存的改动并删除记录 git stash apply # 恢复最近一次保存的改动但不删除记录git stash pop和git stash apply的区别在于 pop 会同时从 stash 列表中移除该条目apply 则保留。如果恢复时与当前工作区有冲突Git 会像处理 merge 冲突一样要求你手动解决。此时 stash 不会自动删除你需要解决完冲突后再手动执行git stash drop清理。git stash默认不包含未跟踪的新文件。如果你新建的文件也需要一并保存增加-u参数git stash -u因为网络搜索结果里有人提到过git stash的疑难杂症这里补充一点常用技巧如果你有多个 stash 需要管理可以用git stash list查看序号然后用git stash apply stash{2}指定恢复某一条。保存时附带信息也是好习惯git stash push -m 登录功能开发中这条命令在 stash 列表里会显示你写的备注一个月后回过头来看不会分不清哪条是哪个功能。5.6 速查一页纸的常用场景对照表为了方便收藏我把上面这些命令整理成一张速查表日常想不起来时可以直接翻。场景命令查看状态git status -s查看历史git log --oneline --graph --all添加所有改动git add .提交git commit -m type: message修改上次提交git commit --amend --no-edit放弃工作区改动git restore filename.txt撤销暂存git restore --staged filename.txt回退一个提交git reset --soft HEAD~1安全撤销已推送提交git revert hash创建并切换分支git switch -c feature/name切换分支git switch feature/name查看所有分支git branch -a合并分支git merge feature/name变基git rebase target-branch同步远端git pull --rebase推送git push设置上游git push -u origin feature/name临时保存git stash push -m 说明恢复临时保存git stash pop查看提交改动git show hash这张表建议放在顺手就能看到的位置。你不需要第一天就把所有命令背下来只要每次遇到场景能够查表并执行用熟了自然就记住了。6. 我踩过的坑常用问题排查与避坑实录6.1 “git不是内部或外部命令”到底怎么破我在前文提到过这个报错绝大多数是因为安装 Git 时 PATH 选项没选对。如果你是重装后发现git依旧无法识别可以检查一下系统环境变量。右键“此电脑” → 属性 → 高级系统设置 → 环境变量在“系统变量”里找到Path确认里面有没有 Git 的安装路径。Windows 默认安装路径一般是C:\Program Files\Git\cmd把这个路径追加进去保存后重启终端。一个容易被忽略的细节是如果你是在 IDEA 的 Terminal 面板里执行git报错还需要重启 IDEA。IDEA 启动时会读取一次系统 PATH修改环境变量后不重启 Idea 一般不会生效。还有你在 Windows 的 CMD 里能用 Git但 IDEA Terminal 却不行那就检查一下 IDEA 的 Terminal 设置里是否指定了自定义的 Shell 路径某些终端模拟器不会继承最新的系统环境变量。PowerShell 用户可能还会遇到执行策略限制运行git时提示“无法加载文件 ps1因为在此系统上禁止运行脚本”。这是因为 PowerShell 默认执行策略为 Restricted但不影响 git.exe 这种原生可执行文件如果你遇到类似问题多半是用了某些 Git 辅助脚本执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned可以解决大多数情况。6.2 推送失败提示 login failed 或 api token 错误有一部分人在 IDEA 里配置 GitLab 账号时会遇到一个直接报错“Login failed. Check API token or GitLab version. Log in via Git if the version policy is not determined.” 这类报错表面上是“登录失败”但常见原因不是账号密码错而是 IDEA 与 GitLab 之间没有建立有效的授权连接。现在很多 Git 平台纷纷取消用户名密码直连方式改用 Personal Access Token个人访问令牌。你在 GitLab 后台生成一个 token勾选read_repository和write_repository权限然后在 IDEA 的设置窗口里找到 Version Control → GitLab填入 GitLab 服务器地址和 token。如果填完后依然报错请检查你的 GitLab 服务器版本是否过老IDEA 对老版本 GitLab 的 API 兼容性可能存在问题。另一个办法是用 Git 命令行创建凭据让 IDEA 在 push 时直接调用系统凭据管理器git config --global credential.helper managerGit for Windows 自带 Credential Manager首次 push 时会弹出窗口让你登录凭据保存后后续不再询问。用这种方式绕开 IDEA 的 API token 校验很多“login failed”问题能直接解决。6.3 IDEA中执行了merge后如何回退热门搜索词里有一条“idea中如何回退merge操作”说明这是很多人实操中的痛点。场景一般是这样你在 IDEA 的右下角把develop分支合并进了自己的工作分支却发现合并后冲突太多、代码不兼容想撤销这次 merge回到合并前的状态。如果 merge 操作还没有产生新的提交IDEA 的图形界面会显示 Merge 按钮与你当前分支的状态。你可以打开 Git 窗口查看这次 merge 是否已经生成提交。最稳妥的撤销方式是找到 merge 提交的父提交然后 reset。在 IDEA 中打开 Git 窗口点击 Log找到你执行 merge 之前的那个提交右键选择 “Reset Current Branch to Here”弹出对话框里三个选项分别对应--soft、--mixed、--hard。如果合并过程中产生了一堆改动并且全部不想要选择 Hard如果还想保留一些文件内容选择 Mixed 或 Soft它们都会保留或部分保留工作区文件。使用命令行则直接git reset --hard HEAD{1}HEAD{1}是 reflog 里记录的“上一次 HEAD 位置”也就是执行 merge 之前所在的位置。这个方法之所以可靠是因为 Git 的 reflog 会记录所有 HEAD 移动历史哪怕你以为自己已经完全把代码弄丢了git reflog通常还能帮你找回。执行完 reset 后如果这次 merge 已经推送到远程情况会复杂一些。你需要谨慎使用--force推送覆盖远端但确保没有其他人已经合入了你的分支。团队协作时更推荐用git revert -m 1 merge-commit-hash来在远端生成一条安全的反向提交保留完整历史避免强制推送引发的事故。6.4 .gitignore文件已经写了规则却不生效很多人都遇到过明明在.gitignore里写了target/但执行git status时target目录依然出现在未跟踪列表里。最常见的原因是.gitignore是在文件已经被 Git 跟踪之后才添加的规则。Git 的忽略规则只对未被跟踪的文件生效如果某个文件已经被git add或者commit过那么它已经进入了 Git 的索引后续再设置忽略也不会自动“请出”仓库。解决办法是先停止跟踪该文件或目录git rm -r --cached target/--cached表示只从 Git 索引中移除保留磁盘上的文件。执行完后再执行git add .gitignore和git commit目标文件就从仓库中移除了之后的改动也会被正常忽略。还有另一个细节某些 IDE比如 IDEA会自动生成.iml文件、.idea/workspace.xml这类个人配置文件如果你在.gitignore里写了*.iml但仓库因为历史原因仍然保留着这些文件那么新同事 clone 下来仍会看到它们。此时同样用上面的命令移除即可但要做好心理准备这个操作会改动项目历史中曾经存在的文件列表需要团队一起协调提交。6.5 误提交了敏感信息不能只靠删除解决热门搜索里有一条“git目录泄露如何下载”虽然这更多是安全攻防语境下的词但反过来也提醒开发者敏感信息一旦进入 Git 历史后续删除并不能完全毁灭它。Git 的每个提交对象都保存着一份完整快照历史记录里每一个版本的文件都处于“只增不减”状态。你在最新提交中删除了application.yml里的数据库密码但之前提交里那份带密码的版本依然存在于.git目录中。如果敏感信息还没推送到远程最简单的处理办法是修改文件内容后使用git commit --amend覆盖提交同时确认没有其他提交包含该信息。如果已经推送更彻底的做法是用git filter-repo或 BFG Repo-Cleaner它们能遍历历史把指定文件从历史快照中抹掉。处理完之后因为提交 hash 全部改变所有的协作者都需要重新 clone这是一个很麻烦的流程。遇到这种事故必须诚实面对如果数据库密码、API 密钥真的泄露了最安全的做法是立即重置这些密码或密钥而不是只依赖 Git 历史清理。Git 历史清理解决的是“代码仓库里不再出现敏感字符串”的问题线上安全问题是另一道防线两条腿都要走。我在真实工作中见过有人费了很大劲清理历史结果忘了改服务器上的密码最后仍然遭受攻击。6.6 IDEA常见设置与性能优化建议有些开发者反馈 IDEA 集成了 Git 后仓库较大时会出现卡顿。IDEA 的 Git 状态刷新机制默认在文件变更后自动运行如果你的仓库包含海量文件每次改动都会触发一次全量扫描。可以尝试在 “File” → “Settings” → “Version Control” → “Git” 里减少刷新间隔或者在右下角手动切换为 “Local Changes only” 模式。除此之外把target、node_modules、out这类构建目录加入.gitignore后IDEA 需要扫描的文件数量会直线下降这是最直接有效的优化。IDEA 默认显示的文件变更面板会跟踪所有修改过的文件如果你在一个非常庞大的旧仓库里工作面板上的文件变更列表可能多达几万条建议过滤掉“未受版本控制”的文件。默认情况下 IDEA 有 “Show Unversioned Files” 选项关闭后新建文件不会立即刷进 Git 窗口但提交时依然可以手动加入。这样界面清爽不少也不影响任何 Git 操作。7. 说点个人的体会Git 用得越久我越觉得它真正的难点不是命令语法而是对“提交历史”的态度。命令可以查文档但什么时候该提交、什么时候该开分支、什么时候改用rebase而不是merge这些判断没法靠死记硬背解决需要你在实际项目中慢慢体会。我自己在刚接触 Git 的头一年几乎每次遇到问题都靠搜索引擎找答案大部分时候照着命令敲一遍确实能解决但始终没形成系统性的理解。后来花了一个周末把自己关在房间里造了两个临时分支故意制造冲突、故意在错误的时机切换分支、故意reset --hard弄丢代码再靠reflog找回来才真正把那些网上抄来的命令变成了自己的工具。如果你看完这篇文章还觉得有些地方没吃透最好的办法不是反复看而是拿一个不重要的测试仓库实际踩一遍。把代码搞乱了顶多重来真正把reflog、reset、revert这些命令都亲手用过一次之后下次遇到类似的事故心里才有底气。这就像学骑自行车看再多教程不如摔两跤学得快。最后一个小建议尽早在自己的全局配置里把pull.rebase true和core.autocrlf配好给项目写上规范的.gitignore提交信息按团队约定写清楚。这些都属于“开始看着不起眼后面越来越香”的投入。环境配置这件事前期多花五分钟后面能省一整天。