尧图网站建设 
刚接手一个项目第一件事就是git clone把代码拉下来改完代码要提交git add、git commit、git push三连分支乱了要合并改错了要回滚远程仓库连不上要排查。这套流程只要是写代码的人几乎每天都离不开。但说实话很多人在Git上栽跟头不是栽在功能复杂的操作上而是栽在最基础的常用命令没吃透——要么是不理解每个命令背后的机制要么是遇到报错不知道怎么排查。这篇文章我想从一个多年实际使用的角度把Git最常用的一批命令重新梳理一遍。不会止步于“这条命令是干什么的”而是会讲清楚它为什么这么设计、在什么场景下用、有哪些容易踩的坑。不管你是刚接触Git的新人还是用了很久但总是靠复制粘贴救火的开发者这篇文章都值得花二十分钟读一遍。1. 从零开始一次完整的Git安装与全局配置1.1 安装GitWindows、Linux和macOS各有各的坑先解决“有没有”的问题。很多新手遇到的第一道坎就是在终端里敲git却提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”或类似的“command not found”。这个提示的意思是你的系统里压根没装Git或者装了但没把可执行文件所在目录加进环境变量。Windows上安装Git最主流的方案是去Git官网下载安装包一路下一步。但有几个选项需要留意安装路径尽量避免带空格的路径虽然Git官方安装包能处理空格但后续某些脚本工具可能因为路径空格出问题。默认编辑器安装过程中会让你选Git使用的默认编辑器建议选Vim以外的简单编辑器或者干脆选Notepad避免新手误入Vim不知道怎么退出。PATH环境变量建议选“Git from the command line and also from 3rd-party software”这样Git会注册到系统PATH里你在任何终端都能直接用git命令而不用每次都打开Git Bash。Linux上就简单多了不同发行版用对应的包管理器# Debian / Ubuntu sudo apt update sudo apt install git -y # CentOS / RHEL / Fedora sudo yum install git -y装完以后验证一下版本确认安装成功git --version这里补充一个被问得很多的细节Git for Windows 自带的 Git Bash 是什么它本质上是在Windows上模拟了一套类Unix终端环境让你能使用Linux风格命令如ls、pwd、grep来操作文件同时直接调用Windows里安装的Git。所以不少Linux常用命令迁移到Windows后第一反应就是打开Git Bash这也是“linux常用命令”和“git bash”这两个热词经常一起出现的真实原因。但注意Git Bash并不是完整的Linux虚拟机它不包含apt这类包管理器也不能直接运行所有Linux软件只能在它提供的工具集范围内使用。1.2 安装后的全局配置身份、编辑器、换行符都要设好Git装好以后第一件事不是急着clone代码而是先配置你的身份。Git每次提交都会记录“作者”和“提交者”这个信息来自全局配置如果没配提交时会报错或者使用一个默认的占位信息。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个容易混淆的点user.email只影响提交记录的展示并不会真的去验证这个邮箱是否存在。很多人在公司代码库里用私人邮箱提交导致代码统计漏掉自己的贡献这类问题就是配置不当引起的。建议公司项目配置公司邮箱开源项目可以用个人邮箱如果项目内部要求统一也可以在具体仓库里覆盖全局配置cd 项目目录 git config user.name 项目专用名字 git config user.email 项目专用邮箱除了身份信息还有两个值得在全局配置里提前设好的选项。第一个是提交时使用的默认编辑器避免某些场景下Git会突然弹出Vim界面让你措手不及git config --global core.editor vim如果实在不会用Vim可以换成nano或者VS Code的等待模式。注意如果你在Windows上配置VS Code作为编辑器命令要写成code --wait的形式否则Git无法感知编辑器窗口已关闭。第二个是换行符处理。Windows和Linux/macOS的换行符不一样Windows用CRLFLinux和macOS用LF。如果不做任何配置跨平台协作时会出现“明明没改代码git diff却显示整文件都变了”的情况。建议统一配置# Windows上提交时转成LF检出时转成CRLF git config --global core.autocrlf true # Linux/macOS上提交时转成LF检出时保持LF git config --global core.autocrlf input这里面的原理可以简单理解成Git在存储文件内容时有自己的内部对象数据库它会按配置把工作区的换行符转换成仓库里统一的形式。autocrlf true表示在提交时把CRLF转成LF检出时把LF转成CRLFinput表示只做提交时的转换检出时不转。另外仓库根目录下的.gitattributes文件可以更精细化地控制换行符规则如果团队有统一要求建议以.gitattributes为准。1.3 查看和维护配置git config 的常用组合配置设完随时可以用git config --list查看当前生效的所有配置项。这个命令会把系统级、全局级、仓库级的配置全部列出来后设置的项会覆盖前面同名的项。如果你想只查看某一项配置git config user.name git config --global --get core.editor配置文件的存储位置也值得知道全局配置文件在用户主目录下的.gitconfig文件仓库级配置文件在项目目录下的.git/config文件系统级配置文件通常在/etc/gitconfig。有时候删配置比加配置还常用比如你想去掉全局配置中某个设错了的项git config --global --unset user.email很多人的Git行为异常最终定位原因都是“某个配置项在哪个层级被覆盖了”所以掌握查看与删除配置的基本方法排查问题会快很多。2. 日常高频命令从git init到git commit的完整闭环2.1 初始化与克隆git init和git clone的区别Git操作有两个起点要么在本地把一个目录变成Git仓库要么从远程克隆一个已有仓库。本地初始化mkdir my-project cd my-project git init执行git init后当前目录下会生成一个隐藏的.git目录这个目录就是Git的“数据库”存储了所有提交历史、分支指针、配置信息等。此时你的工作区还是空的Git还没有开始跟踪任何文件。有一点要注意很多人以为git init之后马上就可以提交代码其实还要先添加文件git add并提交git commit这个我们后面详细说。从远程克隆仓库则是另一回事git clone https://github.com/gaoshu705/qzonearchive.git cd qzonearchivegit clone不仅会把远程仓库的文件拉到本地还会把整个提交历史、所有分支以远程跟踪分支的形式都完整复制下来。克隆完以后本地会自动建立master或main分支并跟踪远程对应的分支。这里要特别提醒一下git clone后面可以加参数控制克隆的深度。有些仓库历史非常庞大比如某些大型开源项目经过多年迭代.git目录可能有几个GB。如果你只是临时想看看代码可以用浅克隆git clone --depth 1 https://github.com/gaoshu705/qzonearchive.git--depth 1表示只拉取最近一次提交的历史这样克隆速度快很多。但浅克隆也有代价你不能查看历史提交、不能切换到老的提交、某些需要完整历史的操作如git log看全部记录会受到限制。如果你要参与开发而不是随便看看建议不要用浅克隆。另一个常见参数是-b指定分支git clone -b dev https://github.com/gaoshu705/qzonearchive.git这个用法适用于默认分支不是你要的分支或者你明确知道要拉取某个功能分支的场景。2.2 工作区、暂存区、版本库三个区域是理解一切命令的钥匙在正式讲add和commit之前必须先讲清楚Git的三个核心区域因为后面所有命令的“为什么”都能用这三个区域解释清楚。工作区Working Directory你当前能看到的、正在编辑的文件目录。这里面的文件是给人看的、给编辑器用的。暂存区Staging Area / Index一个中间缓冲区。git add就是把你对工作区文件的改动“暂存”到这个区域相当于告诉Git“我准备把这些改动打包提交”。版本库Repository / .git目录提交后内容真正保存的地方。git commit会把暂存区的内容永久记录成一个提交节点形成提交历史。日常编辑文件的流程是你在工作区改文件改完觉得这部分的改动可以作为一次独立的提交就git add放进暂存区然后git commit把暂存区的内容固化到版本库。这个设计的好处是能精细控制提交的粒度——同一批文件改动可以分成多次不同主题的提交而不是一股脑全提交上去。一个新手最容易犯的错误是修改了文件直接执行git commit结果发现提示“nothing to commit, working tree clean”。原因很简单——你从来没有git addGit根本不知道你要把哪些改动包含进这次提交。记住一个口诀改完文件先addadd完再commit。git commit只会把暂存区里的内容提交上去不会自动包含工作区里的新改动。2.3 git add的进阶用法按需提交和撤销暂存git add最常见的用法是把所有改动加入暂存区git add . git add -A这两个写法的细微区别是git add .只会添加当前目录及其子目录下的改动git add -A会添加整个工作区所有改动包括删除的文件。如果你在仓库根目录执行两者没什么区别但在子目录里执行时行为可能不同。日常我习惯用git add -A避免漏掉父目录里的删除操作。更精准的用法是按文件或按目录添加git add src/utils/format.js git add docs/按文件添加能帮你做更细粒度的提交控制。比如你改了三个文件其中两个文件是修bug相关的另一个是改样式相关的你就可以分两次添加、两次提交让提交历史更清晰。这个习惯在团队协作中很受欢迎因为review代码的人可以按提交逐个查看而不用把一堆不相干的改动搅在一起。如果需要把某个文件从暂存区撤回来用git restore --stagedgit restore --staged src/utils/format.js注意git restore --staged只是把文件从暂存区移回工作区不会撤销你对文件的改动文件内容还在只是不再处于“已暂存”状态。如果是旧版Git也可以用git reset HEAD file达到同样效果。2.4 git commit的规范与技巧写得清楚后面才查得明白git commit是把暂存区内容固化为提交记录的操作。最基础但够用的三种写法# 单行提交信息 git commit -m 修复登录页按钮错位问题 # 多行提交信息 git commit -m 标题 -m 具体描述 # 打开编辑器编写完整提交信息 git commit如果不加-m参数Git会打开默认编辑器让你输入提交信息这对写详细提交说明有帮助。提交规范这个话题是团队协作里绕不开的。业界最流行的提交规范是Conventional Commits简单说就是把提交信息按“类型(范围): 描述”的格式组织feat: 新增用户注册功能 fix: 修复列表加载超时的问题 docs: 更新README文档 refactor: 重构登录模块代码结构 test: 补充单元测试用例 chore: 更新依赖版本我自己的体会是提交规范的核心价值不是“好看”而是生成changelog、定位问题版本、做代码回溯时能靠提交信息快速过滤。比如线上出了个bug你可以用git log --oneline --grepfix快速找到所有修复类提交缩小排查范围。commit还有一个高频操作是“把当前修改追加到上一次提交”。如果刚才提交完发现漏了一个文件或者提交信息写错了git add 漏掉的文件 git commit --amend--amend会创建一次新的提交替换掉上一次提交并且会打开编辑器让你修改提交信息。这样最终历史里只有一个提交而不是“提交A”加“补充提交B”两个。但务必注意--amend会改写提交历史如果这个提交已经被推送到远程并且别人已经在基于它开发就不要amend了。这个原则适用于所有“改写历史”的操作后面讲到reset时还会再强调。2.5 查看状态与对比git status、git diff、git log日常最常敲的命令之一就是git status。它会告诉你当前工作区处于什么状态哪些文件修改了、哪些文件在暂存区、哪些文件还未被跟踪。建议养成一个习惯每次提交前先跑一遍git status确认要提交的内容确实是你想提交的再执行add和commit。尤其是多人协作时一个不小心把无关的临时文件提交进仓库后面清理起来相当麻烦。git diff用于查看具体的改动内容# 查看工作区与暂存区的差异也就是未add的改动 git diff # 查看暂存区与版本库的差异也就是已add但未commit的改动 git diff --staged这两条命令的区别人容易记混。简单理解默认git diff比较的是“工作区 vs 暂存区”加了--staged比较的是“暂存区 vs 版本库上一次提交”。一个是看还没add的一个是看已经add但还没commit的。git log用于查看提交历史# 简洁的一行一条记录 git log --oneline # 图形化展示分支合并情况 git log --graph --oneline --all # 查看某个文件的提交历史 git log --oneline -- src/utils/format.js--oneline是最实用的参数每条提交只显示一行包含短的提交哈希和提交信息看历史一目了然。--graph会用ASCII字符画出分支合并的结构图对于理解仓库的分支演化非常有帮助。--all会展示所有分支的提交记录而不只是当前分支的。-p可以显示每次提交的具体diff内容调试问题时很好用。3. 分支与远程协作团队开发的核心操作3.1 分支的本质一个指向提交的指针很多人对分支有误解觉得分支就像复制了一份代码。实际上Git的分支本质上只是一个“指向某个提交对象的指针”。创建分支的成本极低因为它不复制任何文件只是新建了一个指针。而HEAD则是“你当前所在位置”的指针指向当前分支。常用分支操作# 查看本地分支当前分支前会有*号标识 git branch # 查看所有分支包含远程跟踪分支 git branch -a # 创建新分支不切换 git branch feature/login # 创建并切换到新分支最常用 git checkout -b feature/login # 或者新版写法 git switch -c feature/login # 切换分支 git checkout master git switch mastergit switch是Git 2.23引入的新命令专门用于分支切换和git checkout做分支切换的效果相同但语义更清晰。git checkout还承担了“恢复文件”等职责职责比较混杂。日常建议想切换分支就用switch想恢复文件或者撤销改动就用restore或checkout职责分开后不容易出错。这里要提醒一个常见问题切换分支时如果工作区有不干净未提交的改动Git可能不允许切换或者会把改动带到目标分支上。处理思路通常是先git stash暂存改动切换完分支后再git stash pop取出。3.2 合并分支git merge的三种情况和fast-forward合并分支是团队协作里最频繁的操作。最常见的合并场景是你在feature/login分支开发完功能要把代码合回master。git checkout master git merge feature/logingit merge有一个重要概念叫fast-forward快进合并。如果当前分支master从分叉点之后没有任何新的提交那么直接把master指针移动到feature分支的最新提交上即可这就是fast-forward合并历史是一条直线没有额外的合并节点。但如果master在分叉后也有了新的提交Git就必须创建一个新的合并提交把两条分支的历史汇合起来。合并过程可能产生冲突conflict提示“Automatic merge failed; fix conflicts and then commit the result”。这时不要慌Git已经把冲突文件标出来了。打开冲突文件你会看到类似这样的内容 HEAD 当前分支的内容 被合并分支的内容 feature/login你需要手动决定保留哪部分、删除哪部分、还是两者都保留然后保存文件。处理完所有冲突后执行git add 冲突文件 git merge --continue或者直接git commit完成合并提交。这里的关键是冲突并不可怕它是版本控制的正常机制真正要避免的是“看到冲突就乱删一通”应该在理解双方改动意图的基础上做合并。3.3 git pull与git fetch弄清“拉的到底是什么”git pull是把远程仓库的最新提交拉下来并且自动合并到当前分支。它的本质是git fetch加上git merge或git rebasegit fetch只从远程下载最新的提交和分支信息到本地的远程跟踪分支如origin/master不会改动你的工作区。git pullfetch之后自动执行合并操作把远程分支合并到当前本地分支工作区代码会发生变化。很多人刚接触时分不清fetch和pull的区别这里打个比方fetch相当于你从网上下载了一个文件到下载目录但没解压没安装pull是下载后自动解压并安装到系统里你的电脑环境立刻变了。日常使用# 拉取并合并 git pull # 拉取并变基后面细说 git pull --rebase # 只拉取不合并 git fetch关于pull用默认的merge还是--rebase团队里经常有争论。简单说如果你的本地分支有未推送的提交而远程也有新提交用默认merge会产生一个合并节点用--rebase则是把你的本地提交“重新播放”到远程最新提交之上历史是线性的看起来更干净。我个人的偏好是git pull --rebase因为线性历史在git log --graph里更清晰但前提是你理解rebase的含义并且本地没有太多复杂的合并操作需要保留。3.4 推送与远程分支git push的使用场景和坑git push是把本地提交推送到远程仓库。最常用的写法git push origin master这个命令会把本地master分支推送到远程origin对应的master分支。如果你已经设置了上游分支upstream直接git push就可以。第一次推送新分支时Git会提示你设置上游git push -u origin feature/login-u参数会建立本地分支和远程分支的跟踪关系之后在这个分支上执行git pull或git push就不必再指定远程分支名了。推送时报错是最常见的场景之一。报错“failed to push some refs”通常意味着远程分支有你本地没有的提交——可能是别人往同一个分支提交了新代码。解决办法是先把远程改动拉下来合并或变基再重新推送。整个过程总结成标准的“提交三步走”git add . git commit -m 提交信息 git pull --rebase git push参考这个流程能省掉大量因推送失败引发的临时处理。pull --rebase的时候如果遇到冲突处理方式和merge冲突一样解决后用git add加git rebase --continue继续。4. 撤销与回滚git reset、git revert、git stash4.1 git reset回到过去但要分清三种模式git reset可能是Git里被误解最多的命令。它的作用是把当前分支的HEAD指针移动到某个历史提交并同时改变暂存区和工作区的状态。具体行为取决于你选的模式# 软重置只移动HEAD保留暂存区和工作区所有改动 git reset --soft HEAD~1 # 混合重置默认移动HEAD并重置暂存区保留工作区改动 git reset --mixed HEAD~1 git reset HEAD~1 # 硬重置移动HEAD并重置暂存区和工作区所有改动全部丢弃 git reset --hard HEAD~1结合前面讲的三区域模型来理解--soft只动版本库指针--mixed动版本库加暂存区--hard三个区域全部重置。日常最常见的场景是“提交写错了想撤销这次提交但保留代码改动”可以用--mixed默认或--soft区别是你想不想保留暂存状态。如果只想撤销提交、让文件回到已修改未暂存的状态用默认模式即可如果想撤销提交后直接重新add用--soft更快。--hard要格外谨慎。它会把你工作区里所有未提交的改动、暂存区的改动全部抹掉而且这些改动无法通过Git恢复。我见过太多人敲了git reset --hard才发现自己有一堆没提交的重要代码。如果你确实需要硬重置但心里不踏实可以先用git stash把你当前改动存起来后续反悔了还能git stash pop找回。基于提交哈希也能resetgit reset --hard commit-hash任何没有推送过的提交都可以放心reset但已推送的提交就不建议reset了因为会改写历史团队其他人拉代码时会遇到大量冲突。已推送且需要撤销的情况推荐用下一节的git revert。4.2 git revert安全地“反向提交”git revert和git reset最大的区别是revert不会移动分支指针而是创建一个新的提交这个提交的内容是“撤销目标提交的改动”。它相当于把之前某个提交做的修改再做一次反向修改生成一个新提交。# 撤销某个历史提交 git revert commit-hash # 撤销最近一次提交 git revert HEAD执行revert后Git会自动打开编辑器让你输入提交信息默认信息是Revert 被撤销的提交信息。确认后一个新的提交就生成了历史完整保留原来的提交依然存在只是它的改动被新提交抵消了。revert的适用场景是代码已经推送到远程甚至已经上线了发现某个提交有问题需要撤回。此时用revert不会改写历史团队其他人pull后自然就得到了“撤销”的效果不会有历史不一致的问题。这是它在协作项目里替代reset的核心原因。4.3 git stash临时保存现场随时回来切换分支时工作区有未提交的改动Git往往会阻止你切换。这时候git stash就是救命的# 保存当前所有改动到stash堆栈 git stash # 查看stash列表 git stash list # 恢复最近一次stash的改动并从堆栈中移除 git stash pop # 恢复最近一次stash的改动但保留stash记录 git stash apply # 丢弃指定stash git stash dropgit stash的原理是把你当前工作区和暂存区的改动保存到一个独立的暂存堆栈里然后让工作区恢复到干净状态。切分支、处理后随时git stash pop取回。这里有个实操细节如果在同一时间存了多个stash默认pop会取出最近保存的那个。如果想指定取出某个用git stash pop stash{1}这种语法。git stash list会显示类似stash{0}: WIP on feature/login: 3f4d5a6 提交信息的记录stash{0}就是索引。stash还有一个进阶场景值得掌握只stash已跟踪的改动不stash新文件git stash --keep-index这个命令会临时保存所有未暂存的改动但保留已经暂存的改动。适合的场景是“改了一堆文件但我想先只提交其中一部分剩下的暂时放一边”。4.4 撤销工作区修改git restore和git checkout有时候改了半天发现方向错了想把某个文件恢复到上次提交的状态# 丢弃工作区中指定文件的改动恢复到暂存区或版本库的状态 git restore src/utils/format.js # 旧版写法和checkout也可以 git checkout -- src/utils/format.js这条命令会把工作区中该文件的所有未提交改动直接丢弃恢复成它最近一次提交或暂存的状态。注意这个操作不可逆一旦执行文件里未提交的改动就找不回来了。如果不确定是否要放弃先备份或者先用git stash。4.5 独立修剪提交git cherry-pick的精确打击最后提一个非常实用但经常被归入“进阶”的命令git cherry-pick。它可以把其他分支上的某个提交原样“复制”到当前分支上生成一个新的提交。# 把另一个分支上的指定提交捡到当前分支 git cherry-pick commit-hash场景举例你在feature/login上修复了一个bug提交为a1b2c3d但master分支现在也需要这个修复又不想把整个feature/login合过来这时就可以在master上git cherry-pick a1b2c3d。它和git merge的本质区别是merge合并的是整个分支的差异cherry-pick挑的是单个提交的改动。如果cherry-pick遇到冲突解决思路和其他冲突一样改完git add后执行git cherry-pick --continue。想放弃这次pick用git cherry-pick --abort。5. 免密配置与效率提升少敲几次密码少走几步弯路5.1 三分钟配置SSH免密提交每次git push都要输用户名密码对高频操作来说非常折磨。Git支持两种主流认证方式的免密HTTPS和SSH。HTTPS免密用credential helper把凭证缓存到本地。Windows上一般安装Git时默认就启用了manager会弹出窗口让你登录一次之后就不再询问Linux上可以用git config --global credential.helper storestore模式会把明文密码保存在~/.git-credentials文件里第一次输入后就不再询问。优点是简单缺点是明文保存安全性稍差。如果不想明文存密码用cache模式把凭证缓存在内存中一段时间git config --global credential.helper cache --timeout3600SSH免密是更推荐的方式。原理是本地生成一对公私钥公钥放到Git服务器上之后Git协议通过SSH通道传输时服务器会用公钥验证你的身份不再需要输入密码。配置步骤如下# 1. 生成密钥对一路回车即可 ssh-keygen -t rsa -b 4096 -C 你的邮箱 # 2. 查看公钥并复制 cat ~/.ssh/id_rsa.pub然后登录你的Git托管平台GitHub、GitLab、Gitee等在设置里找到SSH Keys把公钥粘贴进去保存。之后把远程地址改成SSH格式git remote set-url origin gitgithub.com:用户名/仓库名.git再执行git push就不再需要输入密码了。这里要提醒一点用SSH方式克隆时远程仓库地址必须是git...格式而不是https://...格式。很多人在“为什么我配了SSH密钥还要输密码”的问题上卡住原因往往就是当前远程地址还是HTTPS格式。5.2 配置别名把长命令缩短到两三个字母Git命令本身不长但组合起来就长了。可以通过别名把常用命令缩写git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg log --oneline --graph --all配置完后git st等同于git statusgit co等同于git checkoutgit lg直接看图形化历史。这个配置极大提升日常效率尤其是git lg几乎成了我打开终端后的第一个动作。如果团队有统一的别名规范有经验的开发者建议把别名配置同步到自己的全局配置里。5.3 其他提升效率的小技巧还有一个常用技巧是查看某个命令的详细帮助git help command git command --help遇到不确定的用法直接用git help查官方文档比在网上搜来历不明的命令行组合要靠谱得多。另外git log有很多实用组合比如查看某段时间的提交git log --since2024-01-01 --until2024-06-01 --oneline查看当前分支相对远程分支领先还是落后git status -sb-sb会显示当前分支和上游分支的比较情况[ahead 2]表示本地领先两个提交[behind 1]表示落后一个提交。这是我每天开工后必敲的第一条命令用来快速了解有没有需要推送或拉取的提交。6. 常见问题与排查技巧实录6.1 “无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这是Windows上最常见的Git报错之一。原因有两个要么Git没安装要么安装了但PATH环境变量里没有包含Git的目录。排查步骤先确认安装没安装到“控制面板 - 程序和功能”里看有没有“Git”。如果装了但没用去安装目录确认可执行文件位置默认通常在C:\Program Files\Git\cmd\git.exe。在“系统属性 - 环境变量 - Path”里加上这个目录。重新打开终端执行git --version确认。如果这一切都做对了还是不行试试重启终端或重启电脑环境变量修改在已打开的终端里不会立即生效。6.2 clone报错“Failed to connect”或“unable to access”git clone时遇到网络连接问题原因很多最常见的是代理设置和DNS问题。排查思路# 查看是否配置了代理 git config --global --get http.proxy git config --global --get https.proxy # 如果有代理配置且已不需要取消代理 git config --global --unset http.proxy git config --global --unset https.proxy注意代理问题在国内可能需要格外谨慎务必遵循相关法律法规使用合法的网络环境。如果是企业内网环境需要访问内部Git服务器确认终端是否配置了正确的代理变量或是否在允许列表内。6.3 推送被拒绝“failed to push some refs”这个报错几乎每个团队协作的人都遇到过。原因就是远程分支有了你本地没有的提交你的推送会覆盖别人的提交Git出于安全考虑拒绝执行。解决办法git pull --rebase git pushpull --rebase会把远程新提交拉下来并把你的本地提交“垫”到远程提交之后然后push就能成功了。如果rebase过程中冲突逐个解决冲突后执行git add和git rebase --continue。如果处理到一半想放弃rebase用git rebase --abort回到rebase之前的状态。6.4 提交错了分支怎么办场景是你本来想在feature/login上开发结果不小心在master上提交了好几个commit。这时候不用慌用git cherry-pick就能解决。# 在当前feature分支上 git cherry-pick master分支上的提交哈希把需要的提交“复制”到正确的分支后再回到master分支用git reset --hard origin/master把错误的提交从本地master分支上移除。前提是这些提交还没有推送到远程如果已经推送了要跟团队成员确认后再做处理。6.5 误操作后如何“后悔”reflog的救命用法git reflog是我眼里Git里最被低估的命令。它记录了你本地仓库的所有HEAD移动历史包括reset、commit、checkout、merge等操作。当你误操作了git reset --hard之后发现丢了一个提交可以用它找回。git reflog输出会显示类似a1b2c3d HEAD{0}: reset: moving to a1b2c3d b2c3d4e HEAD{1}: commit: 修复bug如果你想找回HEAD{1}那个提交只需要git reset --hard b2c3d4ereflog只能找回“你的HEAD曾经指向过”的提交git reset --hard丢掉的提交只要在reflog里有记录就还有救。这也是为什么我建议在误操作后不要马上关闭终端——reflog记录在本地终端关不关都不影响但越快回去找回越保险。6.6 仓库越来越大的处理思路仓库体积膨胀是长期项目几乎必遇的问题。常见原因有把大文件二进制、压缩包、模型文件直接提交进了Git历史里积累了多个版本.git目录积累了大量对象文件。处理思路使用.gitignore从源头阻止大文件和临时文件进入仓库。对已经提交的大文件用git rm --cached从版本库移除跟踪但这不会清历史。如果需要清历史里的大文件可以用git filter-repo等工具重写历史但这是高风险操作必须在团队确认且所有人都已clone最新代码的情况下进行。轻量方案是重新clone仓库用--depth 1浅克隆减小体积。.gitignore的正确使用也值得多说一句仓库根目录下创建.gitignore文件里面写要忽略的模式比如node_modules/ target/ *.log .DS_Store这样git add .时匹配这些模式的文件会被自动跳过不会进入暂存区从源头避免了“误提交依赖目录”的尴尬。注意.gitignore只对“未被跟踪”的文件生效如果文件已经被Git跟踪加入.gitignore并不会让它从仓库消失需要先git rm --cached file。7. 实操总结把常用命令串成一套日常流程聊了这么多细节最后把日常开发中的Git操作串成一套完整的流程供你直接参考。这套流程是我在多人和单人项目里都验证过的对新人尤其友好。场景一接手一个新项目git clone 远程地址 cd 项目目录 git status -sb git config user.name # 确认身份必要时在仓库级覆盖 git config user.email场景二开发新功能git switch -c feature/xxx # ...写代码... git status # 查看改动 git diff # 看具体改了啥 git add 涉及文件 # 按需添加别一股脑add . git commit -m feat: 描述 git pull --rebase # 推送前先同步远程 git push场景三发现上个提交写错了git add 漏掉的文件 git commit --amend # 如果还没有推送 # 如果已经推送用 amend 需要 force push不建议直接操作场景四改到一半要切分支git stash git switch 目标分支 # ...处理完... git switch 原分支 git stash pop场景五推上去的代码有问题git log --oneline # 找到有问题的提交哈希 git revert 哈希 git push这套流程覆盖了绝大多数日常工作场景。说句实在话很多人在Git上反复踩坑不是因为某个命令不会而是因为不理解命令背后的数据流转逻辑。理解了三区域模型理解了fetch和merge的区别理解了reset和revert的不同绝大多数问题都能自己分析出答案。以我个人的经验学会Git最好的方式不是背命令而是在真实的项目里反复操作、故意制造几次冲突、亲手解决掉。你可以找个测试仓库把reset、revert、cherry-pick、stash、rebase全部实操一遍体会每个命令对工作区、暂存区、版本库的影响。等这套“手感”建立起来以后Git对你来说就不再是“一堆需要背的命令”而是一套顺手的工具。到时候再看任何Git教程或者文档都会轻松很多。 Git常用命令深度解析：从安装配置到分支回滚的完整指南
刚接手一个项目第一件事就是git clone把代码拉下来改完代码要提交git add、git commit、git push三连分支乱了要合并改错了要回滚远程仓库连不上要排查。这套流程只要是写代码的人几乎每天都离不开。但说实话很多人在Git上栽跟头不是栽在功能复杂的操作上而是栽在最基础的常用命令没吃透——要么是不理解每个命令背后的机制要么是遇到报错不知道怎么排查。这篇文章我想从一个多年实际使用的角度把Git最常用的一批命令重新梳理一遍。不会止步于“这条命令是干什么的”而是会讲清楚它为什么这么设计、在什么场景下用、有哪些容易踩的坑。不管你是刚接触Git的新人还是用了很久但总是靠复制粘贴救火的开发者这篇文章都值得花二十分钟读一遍。1. 从零开始一次完整的Git安装与全局配置1.1 安装GitWindows、Linux和macOS各有各的坑先解决“有没有”的问题。很多新手遇到的第一道坎就是在终端里敲git却提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”或类似的“command not found”。这个提示的意思是你的系统里压根没装Git或者装了但没把可执行文件所在目录加进环境变量。Windows上安装Git最主流的方案是去Git官网下载安装包一路下一步。但有几个选项需要留意安装路径尽量避免带空格的路径虽然Git官方安装包能处理空格但后续某些脚本工具可能因为路径空格出问题。默认编辑器安装过程中会让你选Git使用的默认编辑器建议选Vim以外的简单编辑器或者干脆选Notepad避免新手误入Vim不知道怎么退出。PATH环境变量建议选“Git from the command line and also from 3rd-party software”这样Git会注册到系统PATH里你在任何终端都能直接用git命令而不用每次都打开Git Bash。Linux上就简单多了不同发行版用对应的包管理器# Debian / Ubuntu sudo apt update sudo apt install git -y # CentOS / RHEL / Fedora sudo yum install git -y装完以后验证一下版本确认安装成功git --version这里补充一个被问得很多的细节Git for Windows 自带的 Git Bash 是什么它本质上是在Windows上模拟了一套类Unix终端环境让你能使用Linux风格命令如ls、pwd、grep来操作文件同时直接调用Windows里安装的Git。所以不少Linux常用命令迁移到Windows后第一反应就是打开Git Bash这也是“linux常用命令”和“git bash”这两个热词经常一起出现的真实原因。但注意Git Bash并不是完整的Linux虚拟机它不包含apt这类包管理器也不能直接运行所有Linux软件只能在它提供的工具集范围内使用。1.2 安装后的全局配置身份、编辑器、换行符都要设好Git装好以后第一件事不是急着clone代码而是先配置你的身份。Git每次提交都会记录“作者”和“提交者”这个信息来自全局配置如果没配提交时会报错或者使用一个默认的占位信息。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个容易混淆的点user.email只影响提交记录的展示并不会真的去验证这个邮箱是否存在。很多人在公司代码库里用私人邮箱提交导致代码统计漏掉自己的贡献这类问题就是配置不当引起的。建议公司项目配置公司邮箱开源项目可以用个人邮箱如果项目内部要求统一也可以在具体仓库里覆盖全局配置cd 项目目录 git config user.name 项目专用名字 git config user.email 项目专用邮箱除了身份信息还有两个值得在全局配置里提前设好的选项。第一个是提交时使用的默认编辑器避免某些场景下Git会突然弹出Vim界面让你措手不及git config --global core.editor vim如果实在不会用Vim可以换成nano或者VS Code的等待模式。注意如果你在Windows上配置VS Code作为编辑器命令要写成code --wait的形式否则Git无法感知编辑器窗口已关闭。第二个是换行符处理。Windows和Linux/macOS的换行符不一样Windows用CRLFLinux和macOS用LF。如果不做任何配置跨平台协作时会出现“明明没改代码git diff却显示整文件都变了”的情况。建议统一配置# Windows上提交时转成LF检出时转成CRLF git config --global core.autocrlf true # Linux/macOS上提交时转成LF检出时保持LF git config --global core.autocrlf input这里面的原理可以简单理解成Git在存储文件内容时有自己的内部对象数据库它会按配置把工作区的换行符转换成仓库里统一的形式。autocrlf true表示在提交时把CRLF转成LF检出时把LF转成CRLFinput表示只做提交时的转换检出时不转。另外仓库根目录下的.gitattributes文件可以更精细化地控制换行符规则如果团队有统一要求建议以.gitattributes为准。1.3 查看和维护配置git config 的常用组合配置设完随时可以用git config --list查看当前生效的所有配置项。这个命令会把系统级、全局级、仓库级的配置全部列出来后设置的项会覆盖前面同名的项。如果你想只查看某一项配置git config user.name git config --global --get core.editor配置文件的存储位置也值得知道全局配置文件在用户主目录下的.gitconfig文件仓库级配置文件在项目目录下的.git/config文件系统级配置文件通常在/etc/gitconfig。有时候删配置比加配置还常用比如你想去掉全局配置中某个设错了的项git config --global --unset user.email很多人的Git行为异常最终定位原因都是“某个配置项在哪个层级被覆盖了”所以掌握查看与删除配置的基本方法排查问题会快很多。2. 日常高频命令从git init到git commit的完整闭环2.1 初始化与克隆git init和git clone的区别Git操作有两个起点要么在本地把一个目录变成Git仓库要么从远程克隆一个已有仓库。本地初始化mkdir my-project cd my-project git init执行git init后当前目录下会生成一个隐藏的.git目录这个目录就是Git的“数据库”存储了所有提交历史、分支指针、配置信息等。此时你的工作区还是空的Git还没有开始跟踪任何文件。有一点要注意很多人以为git init之后马上就可以提交代码其实还要先添加文件git add并提交git commit这个我们后面详细说。从远程克隆仓库则是另一回事git clone https://github.com/gaoshu705/qzonearchive.git cd qzonearchivegit clone不仅会把远程仓库的文件拉到本地还会把整个提交历史、所有分支以远程跟踪分支的形式都完整复制下来。克隆完以后本地会自动建立master或main分支并跟踪远程对应的分支。这里要特别提醒一下git clone后面可以加参数控制克隆的深度。有些仓库历史非常庞大比如某些大型开源项目经过多年迭代.git目录可能有几个GB。如果你只是临时想看看代码可以用浅克隆git clone --depth 1 https://github.com/gaoshu705/qzonearchive.git--depth 1表示只拉取最近一次提交的历史这样克隆速度快很多。但浅克隆也有代价你不能查看历史提交、不能切换到老的提交、某些需要完整历史的操作如git log看全部记录会受到限制。如果你要参与开发而不是随便看看建议不要用浅克隆。另一个常见参数是-b指定分支git clone -b dev https://github.com/gaoshu705/qzonearchive.git这个用法适用于默认分支不是你要的分支或者你明确知道要拉取某个功能分支的场景。2.2 工作区、暂存区、版本库三个区域是理解一切命令的钥匙在正式讲add和commit之前必须先讲清楚Git的三个核心区域因为后面所有命令的“为什么”都能用这三个区域解释清楚。工作区Working Directory你当前能看到的、正在编辑的文件目录。这里面的文件是给人看的、给编辑器用的。暂存区Staging Area / Index一个中间缓冲区。git add就是把你对工作区文件的改动“暂存”到这个区域相当于告诉Git“我准备把这些改动打包提交”。版本库Repository / .git目录提交后内容真正保存的地方。git commit会把暂存区的内容永久记录成一个提交节点形成提交历史。日常编辑文件的流程是你在工作区改文件改完觉得这部分的改动可以作为一次独立的提交就git add放进暂存区然后git commit把暂存区的内容固化到版本库。这个设计的好处是能精细控制提交的粒度——同一批文件改动可以分成多次不同主题的提交而不是一股脑全提交上去。一个新手最容易犯的错误是修改了文件直接执行git commit结果发现提示“nothing to commit, working tree clean”。原因很简单——你从来没有git addGit根本不知道你要把哪些改动包含进这次提交。记住一个口诀改完文件先addadd完再commit。git commit只会把暂存区里的内容提交上去不会自动包含工作区里的新改动。2.3 git add的进阶用法按需提交和撤销暂存git add最常见的用法是把所有改动加入暂存区git add . git add -A这两个写法的细微区别是git add .只会添加当前目录及其子目录下的改动git add -A会添加整个工作区所有改动包括删除的文件。如果你在仓库根目录执行两者没什么区别但在子目录里执行时行为可能不同。日常我习惯用git add -A避免漏掉父目录里的删除操作。更精准的用法是按文件或按目录添加git add src/utils/format.js git add docs/按文件添加能帮你做更细粒度的提交控制。比如你改了三个文件其中两个文件是修bug相关的另一个是改样式相关的你就可以分两次添加、两次提交让提交历史更清晰。这个习惯在团队协作中很受欢迎因为review代码的人可以按提交逐个查看而不用把一堆不相干的改动搅在一起。如果需要把某个文件从暂存区撤回来用git restore --stagedgit restore --staged src/utils/format.js注意git restore --staged只是把文件从暂存区移回工作区不会撤销你对文件的改动文件内容还在只是不再处于“已暂存”状态。如果是旧版Git也可以用git reset HEAD file达到同样效果。2.4 git commit的规范与技巧写得清楚后面才查得明白git commit是把暂存区内容固化为提交记录的操作。最基础但够用的三种写法# 单行提交信息 git commit -m 修复登录页按钮错位问题 # 多行提交信息 git commit -m 标题 -m 具体描述 # 打开编辑器编写完整提交信息 git commit如果不加-m参数Git会打开默认编辑器让你输入提交信息这对写详细提交说明有帮助。提交规范这个话题是团队协作里绕不开的。业界最流行的提交规范是Conventional Commits简单说就是把提交信息按“类型(范围): 描述”的格式组织feat: 新增用户注册功能 fix: 修复列表加载超时的问题 docs: 更新README文档 refactor: 重构登录模块代码结构 test: 补充单元测试用例 chore: 更新依赖版本我自己的体会是提交规范的核心价值不是“好看”而是生成changelog、定位问题版本、做代码回溯时能靠提交信息快速过滤。比如线上出了个bug你可以用git log --oneline --grepfix快速找到所有修复类提交缩小排查范围。commit还有一个高频操作是“把当前修改追加到上一次提交”。如果刚才提交完发现漏了一个文件或者提交信息写错了git add 漏掉的文件 git commit --amend--amend会创建一次新的提交替换掉上一次提交并且会打开编辑器让你修改提交信息。这样最终历史里只有一个提交而不是“提交A”加“补充提交B”两个。但务必注意--amend会改写提交历史如果这个提交已经被推送到远程并且别人已经在基于它开发就不要amend了。这个原则适用于所有“改写历史”的操作后面讲到reset时还会再强调。2.5 查看状态与对比git status、git diff、git log日常最常敲的命令之一就是git status。它会告诉你当前工作区处于什么状态哪些文件修改了、哪些文件在暂存区、哪些文件还未被跟踪。建议养成一个习惯每次提交前先跑一遍git status确认要提交的内容确实是你想提交的再执行add和commit。尤其是多人协作时一个不小心把无关的临时文件提交进仓库后面清理起来相当麻烦。git diff用于查看具体的改动内容# 查看工作区与暂存区的差异也就是未add的改动 git diff # 查看暂存区与版本库的差异也就是已add但未commit的改动 git diff --staged这两条命令的区别人容易记混。简单理解默认git diff比较的是“工作区 vs 暂存区”加了--staged比较的是“暂存区 vs 版本库上一次提交”。一个是看还没add的一个是看已经add但还没commit的。git log用于查看提交历史# 简洁的一行一条记录 git log --oneline # 图形化展示分支合并情况 git log --graph --oneline --all # 查看某个文件的提交历史 git log --oneline -- src/utils/format.js--oneline是最实用的参数每条提交只显示一行包含短的提交哈希和提交信息看历史一目了然。--graph会用ASCII字符画出分支合并的结构图对于理解仓库的分支演化非常有帮助。--all会展示所有分支的提交记录而不只是当前分支的。-p可以显示每次提交的具体diff内容调试问题时很好用。3. 分支与远程协作团队开发的核心操作3.1 分支的本质一个指向提交的指针很多人对分支有误解觉得分支就像复制了一份代码。实际上Git的分支本质上只是一个“指向某个提交对象的指针”。创建分支的成本极低因为它不复制任何文件只是新建了一个指针。而HEAD则是“你当前所在位置”的指针指向当前分支。常用分支操作# 查看本地分支当前分支前会有*号标识 git branch # 查看所有分支包含远程跟踪分支 git branch -a # 创建新分支不切换 git branch feature/login # 创建并切换到新分支最常用 git checkout -b feature/login # 或者新版写法 git switch -c feature/login # 切换分支 git checkout master git switch mastergit switch是Git 2.23引入的新命令专门用于分支切换和git checkout做分支切换的效果相同但语义更清晰。git checkout还承担了“恢复文件”等职责职责比较混杂。日常建议想切换分支就用switch想恢复文件或者撤销改动就用restore或checkout职责分开后不容易出错。这里要提醒一个常见问题切换分支时如果工作区有不干净未提交的改动Git可能不允许切换或者会把改动带到目标分支上。处理思路通常是先git stash暂存改动切换完分支后再git stash pop取出。3.2 合并分支git merge的三种情况和fast-forward合并分支是团队协作里最频繁的操作。最常见的合并场景是你在feature/login分支开发完功能要把代码合回master。git checkout master git merge feature/logingit merge有一个重要概念叫fast-forward快进合并。如果当前分支master从分叉点之后没有任何新的提交那么直接把master指针移动到feature分支的最新提交上即可这就是fast-forward合并历史是一条直线没有额外的合并节点。但如果master在分叉后也有了新的提交Git就必须创建一个新的合并提交把两条分支的历史汇合起来。合并过程可能产生冲突conflict提示“Automatic merge failed; fix conflicts and then commit the result”。这时不要慌Git已经把冲突文件标出来了。打开冲突文件你会看到类似这样的内容 HEAD 当前分支的内容 被合并分支的内容 feature/login你需要手动决定保留哪部分、删除哪部分、还是两者都保留然后保存文件。处理完所有冲突后执行git add 冲突文件 git merge --continue或者直接git commit完成合并提交。这里的关键是冲突并不可怕它是版本控制的正常机制真正要避免的是“看到冲突就乱删一通”应该在理解双方改动意图的基础上做合并。3.3 git pull与git fetch弄清“拉的到底是什么”git pull是把远程仓库的最新提交拉下来并且自动合并到当前分支。它的本质是git fetch加上git merge或git rebasegit fetch只从远程下载最新的提交和分支信息到本地的远程跟踪分支如origin/master不会改动你的工作区。git pullfetch之后自动执行合并操作把远程分支合并到当前本地分支工作区代码会发生变化。很多人刚接触时分不清fetch和pull的区别这里打个比方fetch相当于你从网上下载了一个文件到下载目录但没解压没安装pull是下载后自动解压并安装到系统里你的电脑环境立刻变了。日常使用# 拉取并合并 git pull # 拉取并变基后面细说 git pull --rebase # 只拉取不合并 git fetch关于pull用默认的merge还是--rebase团队里经常有争论。简单说如果你的本地分支有未推送的提交而远程也有新提交用默认merge会产生一个合并节点用--rebase则是把你的本地提交“重新播放”到远程最新提交之上历史是线性的看起来更干净。我个人的偏好是git pull --rebase因为线性历史在git log --graph里更清晰但前提是你理解rebase的含义并且本地没有太多复杂的合并操作需要保留。3.4 推送与远程分支git push的使用场景和坑git push是把本地提交推送到远程仓库。最常用的写法git push origin master这个命令会把本地master分支推送到远程origin对应的master分支。如果你已经设置了上游分支upstream直接git push就可以。第一次推送新分支时Git会提示你设置上游git push -u origin feature/login-u参数会建立本地分支和远程分支的跟踪关系之后在这个分支上执行git pull或git push就不必再指定远程分支名了。推送时报错是最常见的场景之一。报错“failed to push some refs”通常意味着远程分支有你本地没有的提交——可能是别人往同一个分支提交了新代码。解决办法是先把远程改动拉下来合并或变基再重新推送。整个过程总结成标准的“提交三步走”git add . git commit -m 提交信息 git pull --rebase git push参考这个流程能省掉大量因推送失败引发的临时处理。pull --rebase的时候如果遇到冲突处理方式和merge冲突一样解决后用git add加git rebase --continue继续。4. 撤销与回滚git reset、git revert、git stash4.1 git reset回到过去但要分清三种模式git reset可能是Git里被误解最多的命令。它的作用是把当前分支的HEAD指针移动到某个历史提交并同时改变暂存区和工作区的状态。具体行为取决于你选的模式# 软重置只移动HEAD保留暂存区和工作区所有改动 git reset --soft HEAD~1 # 混合重置默认移动HEAD并重置暂存区保留工作区改动 git reset --mixed HEAD~1 git reset HEAD~1 # 硬重置移动HEAD并重置暂存区和工作区所有改动全部丢弃 git reset --hard HEAD~1结合前面讲的三区域模型来理解--soft只动版本库指针--mixed动版本库加暂存区--hard三个区域全部重置。日常最常见的场景是“提交写错了想撤销这次提交但保留代码改动”可以用--mixed默认或--soft区别是你想不想保留暂存状态。如果只想撤销提交、让文件回到已修改未暂存的状态用默认模式即可如果想撤销提交后直接重新add用--soft更快。--hard要格外谨慎。它会把你工作区里所有未提交的改动、暂存区的改动全部抹掉而且这些改动无法通过Git恢复。我见过太多人敲了git reset --hard才发现自己有一堆没提交的重要代码。如果你确实需要硬重置但心里不踏实可以先用git stash把你当前改动存起来后续反悔了还能git stash pop找回。基于提交哈希也能resetgit reset --hard commit-hash任何没有推送过的提交都可以放心reset但已推送的提交就不建议reset了因为会改写历史团队其他人拉代码时会遇到大量冲突。已推送且需要撤销的情况推荐用下一节的git revert。4.2 git revert安全地“反向提交”git revert和git reset最大的区别是revert不会移动分支指针而是创建一个新的提交这个提交的内容是“撤销目标提交的改动”。它相当于把之前某个提交做的修改再做一次反向修改生成一个新提交。# 撤销某个历史提交 git revert commit-hash # 撤销最近一次提交 git revert HEAD执行revert后Git会自动打开编辑器让你输入提交信息默认信息是Revert 被撤销的提交信息。确认后一个新的提交就生成了历史完整保留原来的提交依然存在只是它的改动被新提交抵消了。revert的适用场景是代码已经推送到远程甚至已经上线了发现某个提交有问题需要撤回。此时用revert不会改写历史团队其他人pull后自然就得到了“撤销”的效果不会有历史不一致的问题。这是它在协作项目里替代reset的核心原因。4.3 git stash临时保存现场随时回来切换分支时工作区有未提交的改动Git往往会阻止你切换。这时候git stash就是救命的# 保存当前所有改动到stash堆栈 git stash # 查看stash列表 git stash list # 恢复最近一次stash的改动并从堆栈中移除 git stash pop # 恢复最近一次stash的改动但保留stash记录 git stash apply # 丢弃指定stash git stash dropgit stash的原理是把你当前工作区和暂存区的改动保存到一个独立的暂存堆栈里然后让工作区恢复到干净状态。切分支、处理后随时git stash pop取回。这里有个实操细节如果在同一时间存了多个stash默认pop会取出最近保存的那个。如果想指定取出某个用git stash pop stash{1}这种语法。git stash list会显示类似stash{0}: WIP on feature/login: 3f4d5a6 提交信息的记录stash{0}就是索引。stash还有一个进阶场景值得掌握只stash已跟踪的改动不stash新文件git stash --keep-index这个命令会临时保存所有未暂存的改动但保留已经暂存的改动。适合的场景是“改了一堆文件但我想先只提交其中一部分剩下的暂时放一边”。4.4 撤销工作区修改git restore和git checkout有时候改了半天发现方向错了想把某个文件恢复到上次提交的状态# 丢弃工作区中指定文件的改动恢复到暂存区或版本库的状态 git restore src/utils/format.js # 旧版写法和checkout也可以 git checkout -- src/utils/format.js这条命令会把工作区中该文件的所有未提交改动直接丢弃恢复成它最近一次提交或暂存的状态。注意这个操作不可逆一旦执行文件里未提交的改动就找不回来了。如果不确定是否要放弃先备份或者先用git stash。4.5 独立修剪提交git cherry-pick的精确打击最后提一个非常实用但经常被归入“进阶”的命令git cherry-pick。它可以把其他分支上的某个提交原样“复制”到当前分支上生成一个新的提交。# 把另一个分支上的指定提交捡到当前分支 git cherry-pick commit-hash场景举例你在feature/login上修复了一个bug提交为a1b2c3d但master分支现在也需要这个修复又不想把整个feature/login合过来这时就可以在master上git cherry-pick a1b2c3d。它和git merge的本质区别是merge合并的是整个分支的差异cherry-pick挑的是单个提交的改动。如果cherry-pick遇到冲突解决思路和其他冲突一样改完git add后执行git cherry-pick --continue。想放弃这次pick用git cherry-pick --abort。5. 免密配置与效率提升少敲几次密码少走几步弯路5.1 三分钟配置SSH免密提交每次git push都要输用户名密码对高频操作来说非常折磨。Git支持两种主流认证方式的免密HTTPS和SSH。HTTPS免密用credential helper把凭证缓存到本地。Windows上一般安装Git时默认就启用了manager会弹出窗口让你登录一次之后就不再询问Linux上可以用git config --global credential.helper storestore模式会把明文密码保存在~/.git-credentials文件里第一次输入后就不再询问。优点是简单缺点是明文保存安全性稍差。如果不想明文存密码用cache模式把凭证缓存在内存中一段时间git config --global credential.helper cache --timeout3600SSH免密是更推荐的方式。原理是本地生成一对公私钥公钥放到Git服务器上之后Git协议通过SSH通道传输时服务器会用公钥验证你的身份不再需要输入密码。配置步骤如下# 1. 生成密钥对一路回车即可 ssh-keygen -t rsa -b 4096 -C 你的邮箱 # 2. 查看公钥并复制 cat ~/.ssh/id_rsa.pub然后登录你的Git托管平台GitHub、GitLab、Gitee等在设置里找到SSH Keys把公钥粘贴进去保存。之后把远程地址改成SSH格式git remote set-url origin gitgithub.com:用户名/仓库名.git再执行git push就不再需要输入密码了。这里要提醒一点用SSH方式克隆时远程仓库地址必须是git...格式而不是https://...格式。很多人在“为什么我配了SSH密钥还要输密码”的问题上卡住原因往往就是当前远程地址还是HTTPS格式。5.2 配置别名把长命令缩短到两三个字母Git命令本身不长但组合起来就长了。可以通过别名把常用命令缩写git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg log --oneline --graph --all配置完后git st等同于git statusgit co等同于git checkoutgit lg直接看图形化历史。这个配置极大提升日常效率尤其是git lg几乎成了我打开终端后的第一个动作。如果团队有统一的别名规范有经验的开发者建议把别名配置同步到自己的全局配置里。5.3 其他提升效率的小技巧还有一个常用技巧是查看某个命令的详细帮助git help command git command --help遇到不确定的用法直接用git help查官方文档比在网上搜来历不明的命令行组合要靠谱得多。另外git log有很多实用组合比如查看某段时间的提交git log --since2024-01-01 --until2024-06-01 --oneline查看当前分支相对远程分支领先还是落后git status -sb-sb会显示当前分支和上游分支的比较情况[ahead 2]表示本地领先两个提交[behind 1]表示落后一个提交。这是我每天开工后必敲的第一条命令用来快速了解有没有需要推送或拉取的提交。6. 常见问题与排查技巧实录6.1 “无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这是Windows上最常见的Git报错之一。原因有两个要么Git没安装要么安装了但PATH环境变量里没有包含Git的目录。排查步骤先确认安装没安装到“控制面板 - 程序和功能”里看有没有“Git”。如果装了但没用去安装目录确认可执行文件位置默认通常在C:\Program Files\Git\cmd\git.exe。在“系统属性 - 环境变量 - Path”里加上这个目录。重新打开终端执行git --version确认。如果这一切都做对了还是不行试试重启终端或重启电脑环境变量修改在已打开的终端里不会立即生效。6.2 clone报错“Failed to connect”或“unable to access”git clone时遇到网络连接问题原因很多最常见的是代理设置和DNS问题。排查思路# 查看是否配置了代理 git config --global --get http.proxy git config --global --get https.proxy # 如果有代理配置且已不需要取消代理 git config --global --unset http.proxy git config --global --unset https.proxy注意代理问题在国内可能需要格外谨慎务必遵循相关法律法规使用合法的网络环境。如果是企业内网环境需要访问内部Git服务器确认终端是否配置了正确的代理变量或是否在允许列表内。6.3 推送被拒绝“failed to push some refs”这个报错几乎每个团队协作的人都遇到过。原因就是远程分支有了你本地没有的提交你的推送会覆盖别人的提交Git出于安全考虑拒绝执行。解决办法git pull --rebase git pushpull --rebase会把远程新提交拉下来并把你的本地提交“垫”到远程提交之后然后push就能成功了。如果rebase过程中冲突逐个解决冲突后执行git add和git rebase --continue。如果处理到一半想放弃rebase用git rebase --abort回到rebase之前的状态。6.4 提交错了分支怎么办场景是你本来想在feature/login上开发结果不小心在master上提交了好几个commit。这时候不用慌用git cherry-pick就能解决。# 在当前feature分支上 git cherry-pick master分支上的提交哈希把需要的提交“复制”到正确的分支后再回到master分支用git reset --hard origin/master把错误的提交从本地master分支上移除。前提是这些提交还没有推送到远程如果已经推送了要跟团队成员确认后再做处理。6.5 误操作后如何“后悔”reflog的救命用法git reflog是我眼里Git里最被低估的命令。它记录了你本地仓库的所有HEAD移动历史包括reset、commit、checkout、merge等操作。当你误操作了git reset --hard之后发现丢了一个提交可以用它找回。git reflog输出会显示类似a1b2c3d HEAD{0}: reset: moving to a1b2c3d b2c3d4e HEAD{1}: commit: 修复bug如果你想找回HEAD{1}那个提交只需要git reset --hard b2c3d4ereflog只能找回“你的HEAD曾经指向过”的提交git reset --hard丢掉的提交只要在reflog里有记录就还有救。这也是为什么我建议在误操作后不要马上关闭终端——reflog记录在本地终端关不关都不影响但越快回去找回越保险。6.6 仓库越来越大的处理思路仓库体积膨胀是长期项目几乎必遇的问题。常见原因有把大文件二进制、压缩包、模型文件直接提交进了Git历史里积累了多个版本.git目录积累了大量对象文件。处理思路使用.gitignore从源头阻止大文件和临时文件进入仓库。对已经提交的大文件用git rm --cached从版本库移除跟踪但这不会清历史。如果需要清历史里的大文件可以用git filter-repo等工具重写历史但这是高风险操作必须在团队确认且所有人都已clone最新代码的情况下进行。轻量方案是重新clone仓库用--depth 1浅克隆减小体积。.gitignore的正确使用也值得多说一句仓库根目录下创建.gitignore文件里面写要忽略的模式比如node_modules/ target/ *.log .DS_Store这样git add .时匹配这些模式的文件会被自动跳过不会进入暂存区从源头避免了“误提交依赖目录”的尴尬。注意.gitignore只对“未被跟踪”的文件生效如果文件已经被Git跟踪加入.gitignore并不会让它从仓库消失需要先git rm --cached file。7. 实操总结把常用命令串成一套日常流程聊了这么多细节最后把日常开发中的Git操作串成一套完整的流程供你直接参考。这套流程是我在多人和单人项目里都验证过的对新人尤其友好。场景一接手一个新项目git clone 远程地址 cd 项目目录 git status -sb git config user.name # 确认身份必要时在仓库级覆盖 git config user.email场景二开发新功能git switch -c feature/xxx # ...写代码... git status # 查看改动 git diff # 看具体改了啥 git add 涉及文件 # 按需添加别一股脑add . git commit -m feat: 描述 git pull --rebase # 推送前先同步远程 git push场景三发现上个提交写错了git add 漏掉的文件 git commit --amend # 如果还没有推送 # 如果已经推送用 amend 需要 force push不建议直接操作场景四改到一半要切分支git stash git switch 目标分支 # ...处理完... git switch 原分支 git stash pop场景五推上去的代码有问题git log --oneline # 找到有问题的提交哈希 git revert 哈希 git push这套流程覆盖了绝大多数日常工作场景。说句实在话很多人在Git上反复踩坑不是因为某个命令不会而是因为不理解命令背后的数据流转逻辑。理解了三区域模型理解了fetch和merge的区别理解了reset和revert的不同绝大多数问题都能自己分析出答案。以我个人的经验学会Git最好的方式不是背命令而是在真实的项目里反复操作、故意制造几次冲突、亲手解决掉。你可以找个测试仓库把reset、revert、cherry-pick、stash、rebase全部实操一遍体会每个命令对工作区、暂存区、版本库的影响。等这套“手感”建立起来以后Git对你来说就不再是“一堆需要背的命令”而是一套顺手的工具。到时候再看任何Git教程或者文档都会轻松很多。