Git这个东西说难也难说简单也简单。难点在于它不是一个“命令词典”而是一套需要先建立心智模型的工作机制简单在于一旦你理解了工作区、暂存区、版本库这三个概念之间的关系后面所有命令都只是在“操作这三块区域之间怎么流动”而已。我接触Git这么多年经历过最痛苦的阶段就是“背命令”。今天查git merge怎么用明天查git rebase是什么后天又忘了git reset和git revert的区别。等后来我把学习方式从“逐个命令记参数”换成“按场景梳理操作闭环”之后才真正把这套工具用明白了。这篇总结归纳不是网上那些命令大全的搬运而是把我实际使用过程中踩过的坑、理清的思路、常用的操作场景全部串起来从安装配置、日常提交、分支合并到疑难杂症排查一条线讲完。不管你是刚装好git还只会clone的纯新手还是已经接手多人协作项目但总在分支操作上犯迷糊的同学这篇内容都能给你一个相对完整的参考。我先把最核心的框架讲清楚再展开操作细节。1. 先把Git的地图装进脑子三个区与状态流1.1 一次永久消除困惑的核心模型Git和SVN最大的不同在于Git是“分布式”的每个本地目录都拥有一份完整的历史仓库。但分布式这个概念太抽象实际学习时最先要搞定的其实是另一件事Git的三个区。所谓三个区指的就是工作区、暂存区也叫索引区、版本库本地仓库。我用一个生活化的场景来解释这三者的关系你把一份文档写到一半这算“工作区”里的产出你把其中的某些段落用荧光笔标记出来准备最终定稿放进文件夹这是“暂存区”文件夹锁进柜子并编号存档这就是“版本库”。Git的每次commit本质上就是一次“存档进柜子”的动作。在命令行里看这三个区非常直观。git status是最重要的命令没有之一。它会在任何时刻告诉你工作区有哪些改动没被标记暂存区有哪些内容等待提交以及你跟远端相比领先还是落后。很多初学者总是记不住git add和git commit到底谁先谁后其实只要记住“先加进暂存区再存档”这条流水线就够了。我再补充一个关键概念HEAD。HEAD是一个指针指向你当前所在的提交节点通常它就是最近一次commit。你执行的git diff、git log、git reset等操作很多都是在拿“HEAD指向的版本”跟当前状态做对比。理解了三个区和HEAD至少80%的日常操作都不会迷失方向。1.2 从Git安装到基础配置一次搞定不返工先说安装。Windows用户建议直接去Git官网下载Git for Windows安装时绝大部分选项用默认值就行。需要留意的是一步选择默认编辑器我吃过亏选了Vim后来每次commit弹出Vim都一脸懵不知道怎么保存退出。建议选Notepad或者VS Code按自己习惯来。还有一个容易被忽略的选项是PATH环境变量选“Git from the command line and also from 3rd-party software”确保在CMD和PowerShell里都能直接敲git命令。装完之后第一件事不是clone代码而是配置身份信息。Git每次提交都会记录提交人不配置你就提交不了或者提交记录里留一堆乱名字。git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global init.defaultBranch main第二件事是处理换行符问题。这是Windows用户必踩的坑。CRLF和LF的差异导致你一提交代码Git就提示整个文件都被修改了因为每一行结尾都被重写了。git config --global core.autocrlf truecore.autocrlf true的意思是检出代码时把LF转换成CRLF提交时把CRLF转换回LF。团队开发时建议统一让Git自己处理代码库里永远存LFWindows本地工作区显示CRLF。这套组合拳打完Windows上因为换行符导致的diff混乱就能消停。至于SSH密钥配置我在后面“疑难杂症”章节里展开因为那是新手报错最多的环节。这里先记住一点配置全局身份、换行符、默认分支名这三件事是在跑通任何真实项目之前就该做好的基本功。2. 日常开发里最常用的一组命令闭环2.1 提交、撤销与后悔药的正确吃法日常开发的核心操作其实非常固定改代码 → 看改动 → 暂存 → 提交 → 推送。但真正让新手犯晕的是“改错了想撤销”这个场景因为Git提供了好几种撤销方式而且适用的阶段完全不同。我直接按阶段来说。如果你还没有git add只是在工作区改动后发现不对想恢复原样git restore 文件名这行命令会用HEAD里的版本覆盖工作区改动。注意这个操作不可逆改动的内容会直接消失。如果你已经git add了文件进入了暂存区想从暂存区撤出来但工作区改动保留git restore --staged 文件名这个场景我经常遇到本想把文件A一起提交后来发现A还没做完先把它“撤下舞台”。git restore --staged执行完之后A还在工作区改动没丢只是暂存区里没了它。再来说git reset。它有三个模式--soft、--mixed、--hard。git reset --soft HEAD~1 # 撤销上一次提交但保留改动到暂存区 git reset --mixed HEAD~1 # 撤销上一次提交改动回到工作区 git reset --hard HEAD~1 # 撤销上一次提交改动全部丢弃--hard是核弹慎用。--soft和--mixed的区别只在于撤销后代码处于哪个区。实际开发中如果你提交后发现漏了一个文件或者注释写错了更推荐用另一个命令git commit --amend这个命令会把当前暂存区的改动合并进上一次提交同时可以修改上一条commit的注释。它的意义在于避免为了一个拼写错误制造两条提交记录让历史保持干净。注意--amend只适合处理还没有推送到远端的历史如果已经push了就不要再amend了否则会把别人基于旧提交的工作搞乱。git revert则完全是另一套逻辑。它是生成一条新的提交用来反向抵消某一次旧的提交历史是向前增加的不会改写已有记录。适合处理已经推送到远端的错误提交。我把这一串串起来说工作区改错用restore暂存区加错用restore --staged本地提交错用reset或amend远端提交错用revert。这个决策链记住了撤销类操作就不会再犯迷糊。2.2 clone、fetch、pull与推送凭据那些事很多新手分不清git fetch和git pull的区别还经常有人打成“pick”。其实核心区别就一句话fetch只是把远端更新下载到本地但不合并到你当前工作分支pull等于fetch加merge会直接改变你本地的分支状态。为什么这个区别重要因为多人协作时你不一定希望远端一变就自动合并到你的工作区。比如远端有个提交你只想看看不想马上合并就先用fetch然后git log FETCH_HEAD查看差异确认没问题再决定是否合并。这里要解释清楚的是fetch不会破坏本地状态是最安全的获取远端信息的方式。再说clone。克隆仓库时默认会把远端的所有分支和历史都下载到本地但只会给你在本地建一个当前默认分支一般是main或master。如果你想看其他分支git branch -a # 查看所有本地和远端分支 git checkout 分支名 # 切换分支 git switch 分支名 # 新版本Git推荐用switch切换推送到远端最常见的方式有两种。第一种是HTTPS加Token第二种是SSH密钥。个人开发者和公司内部现在用Token的越来越多。配置Token的方式很简单GitHub或Gitee的“个人访问令牌”页面生成一个token把它作为密码填入推送时的认证框。为了让Git记住tokenWindows上装了Git for Windows后默认会使用Git Credential Manager第一次输入时勾选记住之后就不用重复输入了。这里我重点提醒一件事想要“免密”推送最省心的方案不是每次都输token也不是反复配置SSH而是把凭据缓存管好。Windows下如果怀疑Git记住了错误的账号密码导致推送一直失败可以清除缓存git config --global credential.helper git credential-manager github logout # 或对应平台的登出命令清除后再推送Git会重新弹认证窗口。我用这个办法解决过很多次“明明密码改了却一直认证失败”的问题。3. 分支与多人协作合并不再是噩梦3.1 git merge背后的三种模式与冲突处理分支是Git最强大的能力也是让新手最恐慌的地方。其实分支操作没那么多花活核心就两件事切分支、合并分支。git merge最简单的场景是快速前进合并fast-forward。比如你在dev分支开发master分支没有新提交把dev合并到master时Git直接把master的指针往前移动到dev的最新提交就行不用生成新的合并节点。但实际开发中我建议写清楚合并意图使用git merge --no-ff dev--no-ff的意思是不允许快速前进强制生成一个合并节点。这样做的价值在于保留“这里发生过一次分支合并”的历史痕迹方便以后追溯。如果你希望把dev上的多个提交压缩成一个干净的提交合并进来可以用--squashgit merge --squash dev git commit -m 将dev上的改动合并为一个提交squash合并不但让主干历史变得很线性也方便code review。不过它有个副作用dev分支上原本的提交记录会被压平如果你还需要保留那段开发过程的细节就要慎用。再说冲突。很多人一看到“CONFLICT”就慌其实冲突只是Git在告诉你两边的改动在同一个位置重叠了我不知道该听谁的。解决冲突的流程是固定的打开冲突文件搜索 HEAD到 分支名之间的内容。 HEAD下面是当前分支的内容到之间是对方分支的内容。按你的业务逻辑保留其中一部分或两者都留把冲突标记行全部删掉。保存文件后执行git add再git commit完成合并。我用过最实用的技巧是冲突解决过程中别急着重启IDE或乱执行命令先用git status看哪些文件是“both modified”状态一个个处理完再统一git add。处理到一半想放弃就执行git merge --abort回到合并之前的状态。这个命令是后悔药别忘。3.2 同场加映worktree、submodule与IDEA里的合并操作先说一个被低估的功能git worktree。它解决的是“我想同时打开两个分支做开发但一个本地目录只能在一个分支上”的痛点。git worktree add可以在另一个目录里挂载同一份仓库的不同分支git worktree add ../project-dev dev这样你既能在主目录的master上做热修又能在新目录的dev上继续开发两个目录互不干扰。worktree和branch的区别在于branch只是创建了一个新指针而worktree是真正让你“同时展开两个工作现场”。对于经常需要并行处理多个需求的人来说这个功能能省掉大量来回切换分支的折腾。再聊git submodule。它用于在一个仓库里引用另一个仓库的特定提交。典型场景是项目需要依赖某个公共组件库你又希望这个组件库保持独立版本迭代。操作方式git submodule add 仓库地址 path/to/submodule git submodule update --init --recursive第一次clone带submodule的项目时默认子模块是空的必须先update --init拉下来。很多新人被这个坑绊过代码clone成功了但依赖目录是空的编译直接失败。记住一句话凡是带submodule的仓库clone之后先执行一次update --init --recursive再开始干活。至于IDEA里怎么合并分支其实只是把命令行操作图形化了。点右下角的分支名弹出分支列表在目标分支上选择“Merge into Current”IDE就会执行合并操作。如果出现冲突IDEA会列出冲突文件你逐个人工处理同命令行流程完全一致。IDEA里创建新项目拉取Git也很简单File → New → Project from Version Control粘贴仓库地址就能拉下来。实际用下来IDE看diff和解决冲突的体验确实比命令行舒服但懂了命令行逻辑再去点图形界面你会更明白每一步到底在干什么而不是纯靠肌肉记忆。4. 疑难杂症排查实录4.1 SSH认证失败与本地代理端口残留问题Git的认证问题里最劝退新人的就是“ssh: connect to host github.com port 22: Connection refused”这类报错。其实排查思路很简单就三件事密钥是否存在、密钥是否注册到托管平台、网络是否通畅。先检查本地密钥ls ~/.ssh/id_rsa.pub cat ~/.ssh/id_rsa.pub如果没有密钥用ssh-keygen -t rsa -b 4096 -C 你的邮箱生成一个新的。生成完把id_rsa.pub里的内容复制到GitHub或Gitee的SSH公钥设置页面。配置完了想本地自检执行ssh -T gitgithub.com ssh -T gitgitee.com看到“successfully authenticated”就代表通了。如果这一步就报错优先检查你是不是曾经给Git配置过代理。这是很多人会忽略的坑以前用过代理工具给Git设置过http.proxy现在代理关了但配置还留在Git里。于是每次git clone或git push就报错git clone failed to connect to 127.0.0.1 port 7890: Connection refused这个报错信息已经把答案写在脸上了Git在尝试连接本地127.0.0.1的7890端口但那个端口上现在已经没有服务了。解决办法是查看并清除代理配置git config --global --list git config --global --unset http.proxy git config --global --unset https.proxy还有一种情况是~/.gitconfig文件里有残留直接编辑该文件删掉proxy相关行就行。我把这类问题统一归类为“环境残留问题”建议你排查任何网络类Git报错时第一件事永远是执行git config --global --list看有没有不该存在的配置。4.2 大文件、gitignore不生效与/dev/null dup failed先说大文件。Git的默认单文件限制没有硬性规定但托管平台有限制GitHub上超过100MB的文件会被直接拒绝Gitee是50MB。想提交大文件正道是使用Git LFSLarge File Storage。简单来说LFS把大文件内容存放在专门的存储服务里仓库里只保留一个文本指针git lfs install git lfs track *.psd git add .gitattributes配置完再把文件add、commit、push就行。需要注意LFS不是“超大包一切”它适合二进制文件、设计稿、音视频素材这类不经常变动的文件。如果你推大文件失败报错信息一般会提示“file is too large”这时候一定不要试图用git reset强行糊弄该用LFS就老实配置。再说gitignore不生效这个经典老问题。很多人在.gitignore里加了node_modules/但git status里还是能看见相关文件原因几乎只有一个这些文件在添加.gitignore之前已经被Git跟踪了。.gitignore只对未跟踪的文件生效已经入库的文件并不会自动被忽略。解决办法git rm -r --cached node_modules--cached参数的意思是只把文件从版本库里移除保留工作区文件。执行完后重新提交一次再往.gitignore里加规则后续就不会再跟踪这些文件了。这个操作我几乎每周都会帮同事处理一次属于高频问题。最后说一个比较冷门但Windows用户可能遇到的报错git open /dev/null or dup failed: no such file or directory。这个错误通常和Git Bash的stdin/stdout重定向有关常见于你在非Git Bash的终端里执行某些Git交互命令或者MSYS环境异常。我实测有效的解法是关闭当前的Shell窗口直接用Git Bash重开一个再尝试同样的操作。如果还不行检查一下系统临时目录权限或重新安装Git for Windows。这类问题往往不是命令错而是环境配置错。4.3 效率习惯与安全意识除了修复报错Git使用中更应该养成一些好习惯。Git Bash里的复制粘贴跟Windows常规习惯不一样默认选中文本就是复制右键或ShiftInsert是粘贴。很多人刚用时点CtrlC发现没反应其实是终端窗口上下文菜单在作怪。建议在Git Bash窗口右键选择Options → Mouse勾选“Copy on select”这样用起来顺手很多。安全方面要特别提醒一点永远不要在生产环境目录下暴露.git文件夹。如果部署时把整个项目目录直接丢到Web服务器而且没有对.git目录做访问限制别人理论上就能通过访问/.git/HEAD、/.git/objects/等路径把源码历史拉下来。这是一个非常严重的信息泄露风险但很多人完全没意识到。正确的做法是部署时打包构建产物即可不要把源码目录整个扔上去如果必须保留也要在Nginx或Apache层面对.git目录做拒绝访问配置。工具本身没问题用错了姿势就会变成事故。最后给一份我自己总结的高频命令速查表覆盖日常90%以上需求场景命令说明查看状态git status任何时候先跑这个暂存文件git add -p只看单个文件逐块暂存比Add All安全提交git commit -m 说明注释写清楚“做了什么”撤销工作区改动git restore file目标文件回到上次提交的状态撤销暂存git restore --staged file从暂存区撤出但保留改动改上次提交git commit --amend合并改动进上一次提交看历史git log --oneline --graph图形化查看提交历史切换分支git switch name新写法语义清晰合并分支git merge --no-ff name保留合并历史拉取远端git pull --rebase尽量用rebase方式拉取历史干净推送远端git push origin branch首次推送加-u建立跟踪我把git pull --rebase单独提出来说一下。常规git pull是fetch加merge如果远端有提交而你本地也有提交会产生一个自动的merge节点提交历史里会出现一堆“Merge branch”的记录。加上--rebase后Git会把你本地的提交“挪”到远端提交的后面历史变成一条干净的直线。多人协作时大家都用pull --rebase主干历史会清爽很多。5. 最后的几句实在话我学Git最大的感受是千万别抱着命令手册从头背到尾那样三天就放弃了。更好用的方法是“场景卡片”思维——把你经常遇到的操作场景一个个写下来然后为每个场景配命令。比如“重新提交一次commit”就记--amend“临时切走分支干活”就记git stash“把dev的某次提交复制到master”就记git cherry-pick。场景会重复卡片越积累越多命令自然就熟了。分享一个我自己的小习惯每次准备提交代码前先看一眼git status和git diff确认只有打算提交的改动再执行git add。这个习惯看起来很基础但它帮我挡掉了无数次把调试代码、临时配置文件不小心提交进版本库的事故。提交信息也建议坚持写清楚不要用“update”糊弄以后回看历史能省下大量考古时间。Git这工具属于典型的“用进废退”。你只要把它当“本地版本存档系统”来用别被那些高阶功能吓住从日常提交、分支合并、冲突解决一步步走很快你也会发现它其实就是个有肌肉记忆的伙伴。真遇到搞不定的报错按这篇文章里的排查顺序走一遍大部分问题都能在不折腾环境的前提下解决掉。