1. 写在前面的 Git 基本功理解工作区与快照机制先说个我自己的观察。教过不少人用 Git也带过几个刚入行的新人我发现绝大多数“命令记不住”“操作乱套”的问题根源不在于命令本身而在于没搞懂 Git 的三层结构工作区、暂存区、版本库。如果你能把这层窗户纸捅破后面的所有命令都可以顺藤摸瓜地记住根本不需要死记硬背。我把这个三层结构理解成一个快递发货流程工作区Working Directory就是你电脑上肉眼可见的文件目录你在这里写代码、改文档相当于商品还在你的仓库货架上。暂存区Index / Staging Area类似于快递员把已经打包好的包裹放进车上还没发出去。你执行git add就是把文件装上车。版本库Repository / .git快递真正发出去归档记录。你执行git commit就是把车上的包裹正式发出留下一个永久的快照。理解了这层关系再看下面这些高频命令你就明白每一步操作到底在移动什么了。先说状态检查三兄弟这是你每天使用频率最高的命令git status # 查看当前工作区状态红色已修改未暂存绿色已暂存未提交 git diff # 查看工作区与暂存区的具体差异即“我到底改了啥” git diff --staged # 查看暂存区与版本库的差异即“我提交前要确认的东西”我见过不少同事一上来就git commit -m update压根不看git status和git diff。结果提交完了才发现改错文件了或者把自己不想提交的调试代码也带进去了最后又得花时间git reset甚至git revert。你记住我这句话git status是方向盘git diff是后视镜开车前不看不踩雷才怪。然后是文件操作的几个基础命令git add file # 将文件从工作区加入暂存区 git add . # 将当前目录所有改动加入暂存区注意有坑见下文 git commit -m feat: 用户登录模块 # 将暂存区内容提交为一次版本快照 git commit -am fix: 修复空指针 # 跳过 add直接提交已跟踪文件的修改新文件不行这里说个git add .的坑。很多新手习惯无脑git add .如果项目里有临时文件、日志文件、本地的.env配置文件、编译产物这些都会被一股脑地提交进版本库。我踩过最大的一个坑就是早期没有养成写.gitignore的习惯把本地的target/目录Java 构建输出给提交上去了。后来每次拉代码都要忍受一堆无意义的二进制差异而且仓库体积越来越大。正确做法是项目一初始化就写好.gitignore把node_modules/、target/、*.log、.env、.idea/、.vscode/等全部排除掉。你还可以执行git add -p进行交互式暂存逐个 hunk 确认要提交哪些改动这在精细化提交时非常管用。git commit的提交信息建议遵循 Conventional Commits 规范feat表示新功能、fix表示修 Bug、docs表示文档、refactor表示重构、test表示测试相关、chore表示构建或工具变动。团队协作时这种规范化的提交信息配合git log --oneline --graph看历史整个项目脉络一目了然。2. 提交与撤销那些让你头皮发麻的回滚操作讲完“正向操作”我们来聊聊“后悔药”。Git 最强大的能力之一就是“几乎什么都能撤销”但它的撤销体系有点绕我每次培训都用一张逻辑链帮大家梳理改乱了工作区文件想回到上次git add或git commit的状态用git restore新版或git checkout -- file旧版习惯。已经把文件git add进了暂存区想撤出暂存、但保留工作区修改用git restore --staged file或git reset HEAD file。已经git commit提交了但提交信息写错了想重新修改提交信息用git commit --amend。已经提交了但发现漏了文件、想把这个文件并入上一次提交git add之后执行git commit --amend --no-edit。已经提交了想撤销这整次提交的改动、但保留历史记录用git revert commit。已经提交了想彻底抹掉这次提交记录危险软回退git reset --soft HEAD~1保留改动到暂存区。混合回退git reset --mixed HEAD~1默认保留工作区修改取消暂存状态。硬回退git reset --hard HEAD~1直接丢弃所有改动不可恢复慎用。这里有几个实操中最常见的场景我展开说一下。2.1 场景一刚提交完就发现“哎呀少提交了一个文件”这个场景几乎每周都会遇到。你提交了feat: add user profilegit status一查发现还有个UserProfileService.java忘了git add。这时候千万不要慌不要再去新提交一个fix: forgot add file虽然也能用但提交历史会变得很碎而是git add UserProfileService.java git commit --amend --no-edit--no-edit的意思是沿用上一次提交信息不要弹出编辑器让你再写一遍。这样两次操作最终只生成一个提交记录历史干干净净。2.2 场景二提交推到远程了才发现有问题这是大家最怕的。情况分两种如果这个提交还没有被人拉取、或者只有你自己在用这个分支可以放心使用git commit --amend修改或者git reset --hard回退之后强制推送git push --force-with-lease。如果这个分支已经被人共享、已经有同事基于它开发了千万不能使用git reset改写历史否则别人的本地历史就会跟你冲突别人下次git pull会异常痛苦。正确做法是git revert commit它会生成一个新的提交用来抵消目标提交的改动历史不会被改写是多人协作下的安全撤销方案。我个人的习惯是--force-with-lease永远优先于--force。它会在强制推送前检查远程分支是否已经被别人更新过如果别人的提交不是在你本地历史基础上的推送就会被拒绝。这相当于多了一层保险避免你把自己的本地历史强推上去把远端别人的提交给覆盖了。2.3 场景三回退之后想把某次提交“挖回来”git reset --hard之后发现回退错了或者想找回曾经被删除的提交别急Git 有后悔药中的后悔药git reflog # 查看所有 HEAD 指针的历史移动记录包括已删除的提交 git cherry-pick commit # 把指定的提交应用到当前分支git reflog是本地操作日志记录了你所有commit、reset、merge、checkout等操作导致的 HEAD 移动。我印象最深的一次救援是同事误执行了git reset --hard HEAD~10把十个提交全丢掉了。我过去第一件事就是跑git reflog看到 HEAD 移动轨迹找到丢失前的快照 commit hash然后git reset --hard 那个hash全找回来了。记住只要.git目录没有被删除、没有执行git gc --prunenow之类的深度清理大部分丢失的提交都可以找回。3. 分支与合并核心玩法与避免冲突的实操套路分支是 Git 相对传统的 SVN 这类集中式版本控制最大的优势之一。它就像平行宇宙你可以在main主干上稳如泰山同时开一个feature/login分支放飞自我地改代码改完再合并回来。理解 Git 分支的本质其实就是一个指向某个提交的可移动指针切换分支就是切换指针指向而不会把你工作区的文件搞乱前提是工作区是干净的。3.1 分支的日常操作git branch # 查看本地分支* 号标记当前所在分支 git branch -a # 查看本地远程全部分支 git branch -vv # 查看本地分支与远程分支的追踪关系很实用 git checkout -b feature/login # 新建分支并切换过去新版推荐git switch -c feature/login git switch feature/login # 切换分支Git 2.23 新命令语义更清晰 git merge feature/login # 把 feature/login 合并进当前分支 git branch -d feature/login # 删除已合并的分支-D 强制删除未合并分支实测下来我建议新项目尽量使用git switch和git restore来替代git checkout的多重语义因为checkout既可切换分支、又可恢复文件经常让初学者混淆。新版 Git 已经把“切换分支”和“恢复文件”两个职责拆分成switch和restore语义清晰不容易出问题。3.2 合并冲突的完整处理流程合并冲突并不可怕可怕的是你不会看冲突标记。当两个分支同时修改了同一个文件的同一部分Git 无法自动合并时它会把这个文件标记为冲突状态并在文件内部插入冲突标记 HEAD 这是当前分支HEAD的内容 这是你要合并进来的分支feature/login的内容 feature/login处理流程是git status # 1. 查看哪些文件产生冲突例如 both modified: UserController.java vim UserController.java # 2. 打开冲突文件手动解决根据业务逻辑决定保留哪些代码 git add UserController.java # 3. 解决完毕标记为已解决 git commit # 4. 完成合并且提交Git 会生成一个 merge commit冲突中有一类特别恶心的是“假冲突”两边其实改的是不同地方但因为 Git 的 diff 算法把相邻行也识别成了重叠就会产生额外的冲突。遇到这种别慌着改代码先打开文件仔细审一遍看看是不是同一区块的改动。有时候直接采用某一侧的全部内容然后把另外一侧的无关改动保留下来就能解决。3.3 避免冲突的四个实操技巧第一勤 pull。每天开始干活之前先git pull把远端的新提交拉下来。很多人习惯一天拉一次甚至改完才拉结果累积了大量分叉合并时自然冲突爆炸。第二小步提交。把你的改动拆成多个小的逻辑单元每个单元一个提交而不是攒了一周再一次性提交。提交粒度小冲突时定位范围和影响面都小得多。第三善用git stash。正在feature/a上写了一半代码临时要去main分支改个紧急 Bug但工作区还没写完不想提交这时候git stash # 把当前未提交的改动保存到堆栈工作区变为干净状态 git switch main # 切去改紧急 Bug git switch feature/a # 改完回来 git stash pop # 恢复之前保存的改动这个命令救了我无数次。但要注意git stash pop也可能产生冲突如果恢复时文件已经被其他操作改动过解决思路和合并冲突一样打开冲突文件手动处理处理完git add后执行git stash drop手动丢弃该条 stash 记录。第四从 main 分支拉取最新代码而不是直接在主分支上开发。可以在你的 feature 分支上执行git merge main把它同步过来或者用git rebase main把你的改动“变基”到最新主干之上。我个人的建议如果本地分支还没有推送到远程、只有自己在用用 rebase 保持线性历史如果分支已经公开共享老老实实用 merge。4. 远程仓库协作从 clone 到 push 的完整链路多人协作时远程仓库通常是 GitHub、GitLab、Gitea 或者公司内部的 GitLab是所有人的“中央节点”。这一部分我要讲几个非常高频、且热词中被反复搜索的点clone、pull、push、免密配置、以及远程分支追踪。4.1 最基础的远程命令git clone url # 克隆远程仓库到本地 git remote -v # 查看远程仓库地址origin 是默认名称 git remote add upstream url # 添加一个额外的远程Fork 协作常用 git pull # 拉取远程并合并等价于 git fetch git merge git fetch origin # 只拉取远程数据但不自动合并 git push origin main # 推送本地 main 分支到远程 origin git push origin --delete feature/x # 删除远程分支这里我重点解释一下git pull和git fetch的区别。很多新手会觉得“反正都是拉代码”但其实差别很大git fetch只是把远程仓库的最新提交下载到本地“远程追踪分支”例如origin/main上你的工作分支完全不动而git pull在 fetch 之后还会自动执行一次合并把你的本地分支和远程分支融合。假如你本地有未提交的改动或者本地提交与远程提交产生冲突git pull就会立刻触发合并流程。如果你只是想看看远端有什么新东西、不着急合入建议先git fetch再git log origin/main --oneline对比一下然后再决定要不要合。4.2 解决“每次 push 都要输账号密码”的免密配置这个是真高频热搜词。每次git push都提示输入用户名密码特别烦人。Git 提供了多种免密方案我按推荐顺序说方案一使用 SSH 协议推荐最安全ssh-keygen -t ed25519 -C your_emailexample.com # 生成密钥一路回车即可 cat ~/.ssh/id_ed25519.pub # 查看公钥 # 将公钥添加到 GitLab/GitHub 的 SSH Keys 设置中 git remote set-url origin gitgithub.com:username/repo.git # 把远程地址改成 SSH 格式方案二使用凭据管理器适合 HTTPS 协议Windows 推荐git config --global credential.helper manager-core # Windows 新版 Git 自带管理器 # 之后第一次输入账号密码会被持久化保存后续自动使用方案三本地明文缓存简单但不安全不推荐在生产环境用git config --global credential.helper store # 第一次 push 输入账号密码后明文保存在 ~/.git-credentials 中这里提醒一下公司内部如果禁用了 SSH 端口就只能用 HTTPS 凭据管理器的方式。另外如果你在用 GitHub2018 年之后就不能用自己的账号密码做 HTTPS 认证了得去生成 Personal Access TokenPATtoken 的格式就是ghp_xxxxxxxx把它当密码输入一次凭据管理器记住之后就行。GitLab 也有类似的 Personal Access Token 机制。4.3 分支追踪关系与 push 的坑用git push第一次推一个新分支时常见报错是fatal: The current branch feature/login has no upstream branch.这是因为你的本地分支还没有和远程分支建立追踪关系。解决办法git push -u origin feature/login-u全称--set-upstream会建立本地分支与远程分支的关联以后直接git push、git pull都能自动识别该往哪个远程分支操作。如果不加-u每次都得写完整的git push origin feature/login太啰嗦了。查看追踪关系用git branch -vv输出里会显示每个本地分支对应的远端分支以及领先/落后几个提交例如[origin/main] ahead 2意思是本地比远程领先两个提交还没推上去。4.4 处理 push 被拒绝的常见场景push 被拒绝最常见的原因是远程有本地不存在的提交典型报错是! [rejected] main - main (fetch first)这表示有人抢在你之前推了新代码上去。处理方式git pull --rebase # 拉取远程改动并将本地提交“变基”到远程最新提交之上 git push # 再次推送变基和合并的区别在于合并会生成一个 merge commit而变基会把你本地的提交一个个“搬”到最新提交之后历史是一条直线更清爽。但变基的前提是你本地提交还没有被公开使用一旦你变基后强推会影响其他基于你旧提交开发的人。所以核心原则公开分支不乱 rebase私有分支随便 rebase。5. 历史查看与代码审查log、diff、blame 的组合拳到了团队协作和代码审查环节光会用 add、commit、push 是不够的。你需要能够快速回顾历史、定位某一行代码是谁在什么提交里引入的。这一节我聊几个真正高价值的历史命令组合。5.1 log 系列花式看提交历史git log --oneline # 一行显示一个提交短哈希 提交信息 git log --oneline --graph --all # 图形化显示所有分支的分叉和合并关系强烈推荐 git log --oneline -10 # 只看最近 10 条 git log --author张三 --oneline # 只看某人的提交 git log --since2025-01-01 --until2025-06-30 # 按时间过滤 git log -p -- file # 查看某个文件的详细修改历史每次 diff git log -S 某个函数名 --oneline # 搜索“新增或删除该字符串”的提交pickaxe 搜索以前我看项目演进就靠git log --oneline --graph --all。一眼扫过去哪条分支合并过几次、哪里分叉很大、哪个提交是消防式修复全都能看出来。新人在接手陌生项目时我强烈建议先跑一遍这个命令能在五分钟内快速理解项目的演进脉络。5.2 精准定位这行代码到底谁写的接到一个需求要改动某段业务逻辑但你不确定这段逻辑当初是谁加的、为什么这么写这时候git blame file # 逐行显示每行代码的提交哈希、作者、提交时间 git blame -L 100,120 file # 只看指定行范围适合定位局部问题git blame输出格式是提交哈希 作者 日期 行号 代码内容。我再配合git show commit-hash就能看到那次完整提交里作者改了哪些文件、提交信息是什么、当时的完整 diff 是什么。这三件套blame 定位、show 看详情、log 看上下文在代码审查和 Bug 溯源时就是神器。5.3 diff 系列看清每一次改动git diff # 工作区 vs 暂存区 git diff --staged # 暂存区 vs 版本库 git diff commit1 commit2 # 两个提交之间的差异 git diff --stat # 只显示文件级别的增删统计不显示具体内容 git diff --word-diff # 按单词级别显示差异英文文档和注释时很好用我刚工作时有个很不好的习惯git add完直接git commit从不回头看 staged diff。后来 code review 被导师逮到几次“需求不相关改动混入提交”才老老实实地把git diff --staged养成条件反射。我也建议你提交前花 30 秒跑一下这个命令确认这次提交只包含与需求相关的改动别把无关的调试打印、格式化改动、临时文件混进来。6. 疑难杂症与配置项网上搜不到的避坑经验最后一部分我把这些年被搜索次数最多的 git 疑难杂症和几个容易忽略的配置项汇总一下大家直接抄作业。6.1 中文文件名乱码、显示成八进制转义有些同学git status或git log时中文文件名显示成一堆\345\274\200\345\217\221之类的转义序列很难受。原因就是 Git 默认为了兼容性对非 ASCII 字符做了转义。解决方案git config --global core.quotepath false设置之后中文文件名就能正常显示。这个命令我记得在某些项目里也以-c core.quotepathfalse的临时参数形式出现例如git -c core.quotepathfalse status不加--global的-c表示仅对当前这条命令生效临时用挺方便但我还是建议直接写进全局配置一劳永逸。6.2 换行符问题CRLF vs LF 引发的全文件 diff在 Windows 上开发git 默认可能会把仓库里的 LF 自动转换成 CRLF 写入工作区提交时转回 LF。如果团队混用 Windows 和 Linux/macOS很容易出现“我明明只改了一行怎么 diff 显示整个文件都变了”的情况。核心配置# Windows 用户提交时把 CRLF 转成 LF检出时转换成 CRLF git config --global core.autocrlf true # Linux/macOS 用户提交时把 CRLF 转成 LF检出时不转换 git config --global core.autocrlf input # 更推荐的方式在仓库根目录提交 .gitattributes 文件统一团队行为.gitattributes示例* textauto *.sh text eollf *.bat text eolcrlf这个文件提交到仓库里后所有克隆该仓库的成员的换行符行为都会被统一不会因为个人全局配置差异产生噪音 diff。我吃过一次大亏一个同事的 IDE 自动把整个文件的 CRLF 换成了 LF提交之后 diff 铺天盖地全是“删除一行空格再添加一行空格”的伪变化。从此团队项目里.gitattributes就成了标配。6.3 Git 凭据过期或失效如果你用的 HTTPS 凭据管理器某天突然报Authentication failed通常是 token 过期或密码改了。处理方式打开 Windows 的“凭据管理器”找到对应 Git 条目删除或者 macOS 的“钥匙串访问”里删掉对应记录下次 push 重新输入新的 token 即可。如果是在公司环境大概率是开启了 SSO 单点登录token 有有效期限制需要定期去生成新 token。6.4 “fatal: 拒绝合并无关的历史”错误当你git pull两个完全没有共同祖先的仓库时比如把本地初始化的仓库强行关联到远端已有仓库会报fatal: refusing to merge unrelated histories解决方案是git pull origin main --allow-unrelated-histories这个场景常见于本地先跑了git init并提交了若干次然后又git remote add origin xxx并git pull远端代码。加了--allow-unrelated-histories后 Git 会强制把两条独立历史合并在一起但冲突会非常多建议谨慎操作。更好的做法是如果你要克隆一个远程仓库直接git clone不要本地先 init省得给自己挖坑。6.5 常用配置项整理最后我把个人常用的全局配置一次性列出来你可以直接复制git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global core.editor vim # 设置默认编辑器 git config --global core.quotepath false # 中文文件名正常显示 git config --global push.default simple # 只推送当前分支到同名远程分支 git config --global init.defaultBranch main # 默认主分支名为 main新版本自带 git config --global alias.lg log --oneline --graph --all --decorate # 自定义别名敲 git lg 即可这里顺带说个我自己的使用习惯别名简直是你提高效率的加速器。除了上面的lg我还会配git st代替git status、git ci代替git commit、git br代替git branch。但注意别名别配得太多太花否则换台电脑不习惯了反而痛苦。团队协作时大家最好统一使用原生命令别把个人别名带到公共文档和沟通中。7. 写在最后把这些命令串成你的工作流我个人在实际操作中的体会是Git 命令不在于多而在于你能否把高频命令内化成一套行云流水的工作流。每天早上到工位我一般是git switch main git pull git switch feature/xxx git rebase main这套动作保证我的分支始终基于最新主干合回 main 时基本不会撞车。开发过程中是“小步提交”改好一个功能点就git add对应文件git commit写清楚信息写了一半被打断就git stash暂存提交前必看git diff --staged如果推到远程被拒先git pull --rebase再git push。至于那些背不下来的高级命令我从来不硬背。用的时候git help、git log --help这么敲过去或者直接在命令行里输git回车、Git 自己会把所有命令列出来给你看。在交互式面板里多翻翻比任何教程都直观。还有一点想多说一句现在各种 GUI 客户端VS Code 自带的源代码管理、Sourcetree、GitKraken 等已经很成熟但我的建议是——命令行永远是底座。GUI 能帮你可视化看历史、看 diff效率确实高但当你遇到 GUI 无能为力的错误时只有命令行能让你精准地控制每一层操作。两条腿走路才是真稳。