★ FEATURED ARTICLE Git基本指令最常用、最该吃透的那几个命令做开发这么多年不管前端后端、移动端还是数据方向Git基本指令永远是开箱即用的基本功。哪怕现在各种图形客户端、IDE集成工具越做越顺手我仍然建议你把命令行下的那套核心操作练熟。原因很简单终端里的Git指令是通用的换任何一家公司、任何一台新电脑、任何一套CI流程都逃不过它们。而且真到了线上事故排查、代码救急的时候图形界面往往帮不上忙手敲几个指令反而最稳。这篇文章不打算把Git手册搬过来我只挑实际开发中最常用、最容易踩坑、也最值得掰开揉碎讲清楚的指令——覆盖日常提交、分支管理、远程同步、撤销回退这些核心场景。同时会结合我自己的使用经验把每个关键参数为什么这么用、什么时候用哪种写法讲明白。无论你是刚接触Git的新人还是用了一段时间但总在撤销和回退上犯迷糊这篇都能当一份“随查随用”的手册。1. 内容整体设计与思路拆解1.1 为什么我决定从“指令”而不是“工具”讲起很多入门的同学喜欢先装一个客户端然后点一点按钮就完成提交、推送。这种方式本身没错但很容易让人忽略Git真正的工作模型。一旦遇到冲突、误操作、分支混乱客户端能提供的信息往往有限你反而找不到“发生了什么”和“怎么改回去”。Git的指令设计其实非常讲究每个指令都对应一条清晰的逻辑链——我要做什么、作用于哪个区域、影响哪些对象。比如git add是把改动放进暂存区git commit是把暂存区的快照固化成本地版本git push是把本地版本同步到远端。这条链条搞懂了命令行就只是“把想法翻译给Git听”而已。1.2 我眼中的“基本指令”应该包含哪些根据多年经验我把“基本”定义为四个维度日常提交类status、add、commit、log分支操作类branch、checkout、switch、merge远程同步类remote、clone、push、pull、fetch撤销回退类restore、reset、revert这套组合覆盖了95%的日常场景。真正复杂的子命令、钩子、子模块可以以后碰到再学但上面这些如果掌握不好哪怕客户端用得再溜遇到问题依然会一脸懵。2. 核心细节解析这几个指令背后的“工作区”逻辑2.1 先搞懂Git的三个区域想要真正理解Git基本指令第一件事不是背命令而是理解文件的三个状态区域工作区Working Directory你当前能看到的、能编辑的目录。暂存区Staging Area / Index存放“已经告诉Git我要提交哪些改动”的区域可以理解成购物车。本地版本库Local Repository.git目录中保存的提交历史。git status能反映出这三个区域之间的差异。比如你在工作区修改文件之后git status会提示 “Changes not staged for commit”当你执行git add之后状态会变成 “Changes to be committed”。很多人刚开始搞不明白“为什么要先 add 再 commit”这就是暂存区的价值你可以把多次文件改动分门别类按逻辑分批次提交而不是一股脑全塞进一个提交里。2.2 最常用的状态检查指令git status是我输入频率最高的指令没有之一。它能告诉你当前在哪个分支、工作区是否干净、有哪些文件被修改、哪些文件还没被跟踪。我建议养成一个好习惯每次执行git add之前先看一眼git status确认自己的改动边界。因为人脑很容易漏掉文件名大小写、改动错文件这类小问题但Git不会。git status常见搭配参数git status -s短格式输出每个文件只显示一行非常清爽。git status -b同时显示当前分支及与远端的追踪情况适合快速了解本地是否领先或落后。我在日常工作里几乎总是用git status -sb因为它一行就把分支同步状态和文件改动全交代清楚了。2.3 文件提交链路解析文件从“编辑”到“入库”的标准链路是编辑文件 - git add - git commit - git push对应指令# 把指定文件的改动放入暂存区 git add file # 把当前目录所有改动放入暂存区 git add . # 把所有改动包括删除操作放入暂存区 git add -A # 把暂存区内容固化为一个本地提交 git commit -m 提交说明关于git add .和git add -A的区别早期Git版本中git add .不会处理文件删除事件比如你在工作区直接删了一个文件git add .不会把这个删除操作加入暂存区而git add -A会。新版Git对两者行为已经做了统一但为了保险我依然推荐使用git add -A它更明确、更完整。git commit还有一个高频参数-a表示“把所有已跟踪文件的改动直接提交跳过暂存区”。例如git commit -am 跳过暂存区直接提交注意-a只对已经被Git跟踪的文件有效新文件仍然必须先git add。这个参数适合快速提交那些“我确定这几个文件都要一起提交”的场景但使用前建议先看git status确认没有意外改动。2.4 提交信息的质量比指令本身更重要我见过很多团队提交信息写得跟密码似的“update”、“modify”、“test”。这种信息过一个月自己都看不懂更别提单人交接。很多人在学Git基本指令时会忽略一个事实git commit -m xxx的xxx会永远留在历史里。理想情况下提交信息应当能回答两个问题这次改动做了什么为什么做这个改动我常用的格式是type: summary [optional body]例如git commit -m fix: 修复订单列表在低版本浏览器下的渲染异常 -m 根因是CSS Grid兼容性问题改用Flex布局处理如果团队没特别要求至少保证第一行简洁不超过50个字符后续补充细节在空行之后。这样看git log --oneline时就能快速扫描每次提交的意图。3. 分支操作与合并实战3.1 分支是什么为什么多分支协作是常态Git的分支本质上只是一个指向某个提交对象的指针。它很轻量创建和删除分支几乎瞬时完成。这也让Git天然适合并行开发、多特性同时推进的工作流。核心指令# 查看本地分支 git branch # 查看所有分支含远端分支 git branch -a # 创建分支 git branch branch-name # 切换到某个分支 git checkout branch-name # 更安全的切换指令 git switch branch-name # 创建并切换分支 git checkout -b branch-name git switch -c branch-name # 删除分支 git branch -d branch-name3.2 我为什么推荐你用git switch而不是git checkoutgit checkout是一个多面手既能切换分支也能恢复文件还能切换到某个提交。多面手的问题是容易让新手混淆。Git新版提供了git switch专门负责“切换分支”以及git restore专门负责“恢复文件”。职责单一命令本身也更安全。虽然很多老项目文档还在用git checkout -b xxx但新环境建议优先使用# 创建并切换新分支 git switch -c feature/payment # 切换已有分支 git switch main # 回到上一个分支 git switch -git switch -这个用法有点小技巧它能在你当前分支和上一个切换的分支之间来回跳特别适合在两个分支之间快速对比代码或临时切换任务。3.3 合并分支的三类操作merge 与 rebase 的选择合并分支是分支操作的核心。最基础的指令是git merge# 把 feature/login 分支合并到当前分支 git merge feature/login在执行合并之前我先确认当前在哪一个分支比如在main然后执行git merge feature/loginGit会把feature/login的历史与当前分支的历史合并成一个新的提交点。合并过程中最常见的坑是冲突。冲突的本质是两个分支修改了同一个文件的同一行Git无法自动决定保留哪个版本。出现冲突时Git会标记冲突文件你需要手动打开文件找出类似这样的内容 HEAD 当前分支的代码 被合并分支的代码 feature/login手动保留正确内容、删除标记符号后再执行git add file git commit -m merge: 解决 xxx 冲突而git rebase则是把当前分支的提交“重放”到目标分支的顶端看起来是一条直线历史git rebase mainrebase的优点是历史更整洁缺点是它会重写当前分支的提交哈希。如果你已经把当前分支推送到了远端且和他人共享千万不要轻易rebase否则你推上去的提交和别人的历史会分叉拉扯起来非常痛苦。我的建议是公共分支之间合并用merge保留真实的历史交错。本地个人分支想“更新到最新主线代码”时可以用rebase让自己历史变成一条直线但如果这个分支已经推送过且多人共用还是用merge。3.4 分支协作时最实用的一个指令git branch -vgit branch -v可以列出每个分支的最新提交信息配合git branch -vv还能看到本地分支和远端分支的追踪关系leading、behind 情况。当分支很多时用git branch -vv扫一眼马上能发现哪个分支落后于远端哪个分支的远端已经不存在非常高效。4. 远程仓库同步clone、push、pull、fetch4.1 建立本地与远端的连接远程仓库同步是团队协作的基础。常用指令# 克隆一个远端仓库到当前目录 git clone url # 克隆到指定目录名 git clone url my-project # 查看已经配置的远端仓库 git remote -v # 添加远端仓库 git remote add origin url # 推送本地分支到远端 git push origin branch-name # 拉取远端代码并自动合并到当前分支 git pull # 只拉取远端更新不自动合并 git fetchgit clone之后默认会建立origin这个远端别名Remote Alias。origin只是约定俗成的名字不是硬编码。你完全可以用git remote add upstream url来指向源仓库这在开源协作里非常常见。4.2 push 与 pull 的底层机制很多人把git pull等同于“更新代码”但这其实不太准确。git pull实际上是git fetchgit merge的合体先从远端把新提交拉到本地仓库然后自动执行一次合并。如果你想更精细地控制“更新”过程建议分成两步走# 1. 先拉取远端更新 git fetch origin # 2. 查看本地落后情况 git statusgit fetch之后本地会多出类似origin/main的引用但它不会改动你的工作区也不会自动合并。这时候你有机会用git log对比main和origin/main的差异判断是否直接合并。如果确认要合并再执行git merge origin/main这种方式比直接git pull更可控尤其在远端有大量重写、历史变更的时候直接git pull可能会触发意外冲突。4.3 push 时最容易忽视的“上游分支”问题第一次把本地新分支推送到远端时需要告诉Git该分支要去远端创建同名分支并建立关联git push -u origin feature/login-u参数的全称是--set-upstream表示“设置本地上游分支”。一旦关联好之后在这个分支上直接输入git push、git pull就行不用每次写远程分支名。我还见过一个很奇怪但很常见的错误在本地不小心 push 了一个临时分支之后删掉本地分支后发现远端分支还一直存在。清理远端的正确指令是git push origin --delete branch-name注意这不是用git branch -d而是用git push --delete两者对象不同前者删本地分支后者删远端分支。4.4 撤销已经push到远端的错误提交如果错误提交已经被推到了远端情况就稍微复杂了点。首选方案是使用git revert它是一个“安全撤销”指令# 生成一个反方向的提交抵消指定提交的改动 git revert commit-hashgit revert不会删除历史而是新增一个提交来反转内容。这样远端历史仍然是线性向前推进的其他人拉取代码时不会遇到提交缺失或强制推送的问题。如果确实需要彻底改写远端历史比如把最近一个错误提交从历史中抹掉可以使用软回退强推但要格外谨慎git reset --hard HEAD~1 git push --force-with-lease这里我推荐使用--force-with-lease而不是--force。--force-with-lease会先检查远端是否被其他人更新过如果远端已经有了别人的新提交就不会强制覆盖避免把别人的工作冲掉。这是一个非常实用的安全参数。5. 撤销与历史回退别再把reset和revert混为一谈5.1git restore工作区改动的后悔药当你改动了一个文件但突然觉得改错了想回到上次提交的状态# 用暂存区的内容覆盖工作区 git restore file # 用本地版本库最新提交覆盖工作区和暂存区 git restore --staged file区别在于git restore file丢弃工作区未暂存的改动把文件恢复到暂存区或版本库对应的状态。git restore --staged file把“已暂存”的改动恢复到“未暂存”状态即取消git add但保留工作区的实际改动。这两个场景你一定会遇到。前者是“我改坏了需重来”后者是“我不小心 add 了不该 add 的文件”。5.2git reset移动提交指针影响三种层级git reset的核心逻辑是“把当前分支的指针移动到你指定的提交”。它的参数非常微妙git reset --soft commit git reset --mixed commit # 默认 git reset --hard commit--soft只移动HEAD指针暂存区和工作区都不动。适合“我想重新编辑提交信息”或者“我想把最后几个提交重新整理成一个新提交”。--mixed默认移动HEAD指针并重置暂存区但工作区里的实际内容不变。执行完你会发现之前暂存的改动变成了未暂存状态。--hard移动HEAD指针同时重置暂存区和工作区。这是最危险的操作会让工作区直接变成目标提交的状态未提交的本地改动会被彻底覆盖。举个例子假设你做了两次提交但想重新合成一次git reset --soft HEAD~2 git commit -m 合并成一个新提交执行完你会发现HEAD~2之后的所有改动都保留在暂存区可以直接再次提交。反之如果你想彻底丢弃工作区里的所有改动让本地完全等于远端某个状态git reset --hard origin/main这个操作会销毁你本地所有未提交内容如果没有提前备份找回来的成本极高。所以我一般会在执行前反复确认当前分支是否有未提交且重要的改动。最稳妥的办法是先git status再git stash把改动藏起来然后再git reset --hard。git stash可以理解为“临时抽屉”后续用git stash pop恢复。5.3git revert通过新增提交来撤销历史上面提到git revert适合已经推送远端的场景。它的另一个好处是支持撤销历史中的任意一个提交而不是只能从最新往回退。比如一个在三天前提交的改动引入了Bug你不想动之后的提交只想单独撤销那一次改动git revert 8f3d6aGit会计算该提交相对父提交的差异并生成一个反向提交。这非常安全但由于它会创建新的提交对象提交信息默认会标记为“Revert”方便审阅。5.4 查看历史log与reflog的使用差异想撤销首先要知道自己在哪、正对哪个提交。查看常规提交历史git log --oneline --graph --all--graph会以字符图形显示分支分叉情况--all会显示所有分支这对理解仓库全貌很有帮助。但git log不会显示“已经丢失”的提交。比如你用git reset --hard丢弃了某个提交想找回它怎么办答案是git refloggit reflogreflog记录的是Git仓库HEAD引用每一次移动的痕迹相当于“操作日志”。即使你把分支指针回退了几次只要没有执行git gc清理垃圾对象那几次提交仍然还在可以通过git reflog找到相关哈希再用git reset或git cherry-pick恢复。这是我最想强调的一个技巧git reset --hard之后不要慌先git reflog大概率能找回你“误删”的提交。5.5 临时存放改动stash在切换分支前如果你有未提交的改动且担心切换分支会引发冲突或干扰可以用git stash git stash list git stash popgit stash会把工作区和暂存区的改动打包保存到栈中让工作区变得干净。git stash pop则把最近一次保存的改动恢复出来。恢复时如果遇到冲突需要手动解决。我常用的进阶用法是给stash加备注git stash push -m 临时保存WIP: 支付回调调试点 git stash list日常流程通常是这样在功能分支上改了一半临时被叫去修线上Bug。这时不需要急着提交半成品代码git stash保存一下然后切分支修复完成后再切回来git stash pop接着改。6. 常见问题与排查技巧实录6.1 冲突标记污染了文件冲突之后文件里全是、。很多人一脸懵其实只需要两步打开冲突文件搜索。手动保留当前分支或传入分支的内容或者组合两者然后删除所有冲突标记。完成后执行git add和git commit。如果冲突文件太多用IDE的“Resolve Conflicts”可视化面板会更快但本质还是手动选择。6.2 错误提交到了main分支假设你直接提交到了main而这个分支本应保持干净。正确的处理流程先切一个功能分支保存当前状态git switch -c feature/temp回到main回退刚才的错误提交git switch main git reset --hard HEAD~1如果你已经push到了远端就用git revert生成反向提交再推送。不过更推荐的做法是在每次开发任务开始前主动创建分支而不是在main上直接改。分支的成本极低养成习惯之后误提交的概率会大大降低。6.3 提交遗漏了某个文件已经执行了git commit但忘了一个文件。不要慌有两种方式方法一推荐适用于末次提交git add 遗漏文件 git commit --amend --no-edit--amend会修改上一次提交--no-edit表示沿用原有提交信息。注意如果该提交已经推送远端使用--amend后会改变提交哈希需要强制推送在共享分支上慎用。方法二适用于追加一个新提交git commit -m 补充遗漏文件 xx这种方式保留了历史痕迹适合共享分支。6.4 push被拒绝远端领先本地当远端有其他人推送了新提交而你本地没有包含最新内容时直接git push会被拒绝。此时不要强行推送应该先git pull解决冲突后再推送git pull git push如果git pull不想每次都自动合并可以在.gitconfig里设置git config --global pull.rebase false也可以手动选择策略。我个人习惯用默认的merge模式以便保留合并提交方便追溯。6.5 常见问题速查表场景推荐指令注意事项查看当前状态git status -sb优先于git status将改动加入暂存区git add -A避免遗漏删除操作提交并写详细说明git commit -m type: 描述格式清晰方便回溯切换分支git switch branch优先于git checkout创建并切换分支git switch -c branch等效于checkout -b拉取远端并合并git pull等于fetchmerge只看远端变化git fetch不改变工作区可控性高推送新分支并建立关联git push -u origin branch首次推送必用-u丢弃工作区改动git restore file不可恢复先确认撤销暂存git restore --staged file保留文件实际修改回退本地提交git reset --soft HEAD~1保留改动在暂存区丢弃本地所有改动git reset --hard target极度危险建议先stash撤销远端提交git revert commit保留历史新增反向提交临时保存改动git stash push -m msg恢复用git stash pop查看丢失提交git reflog找回reset丢失时非常有用7. 补充一个我常用的技能组合分支开发流程落地7.1 新手最该模仿的一套完整流程理论讲了很多我直接给一套可以直接照抄的日常分支开发流程。假设你的项目主分支叫main你要开发一个登录模块。# 1. 更新主分支到最新 git switch main git pull # 2. 从最新main创建功能分支 git switch -c feature/login # 3. 开始编码、反复提交 git add -A git commit -m feat: 新增登录页面结构 git add -A git commit -m feat: 接入登录接口 # 4. 开发过程中想同步主分支的更新 git fetch origin git merge origin/main # 或者git rebase origin/main # 5. 推送分支到远端 git push -u origin feature/login # 6. 在远端创建MR/PR经评审后合并 # 7. 合并后清理本地分支 git switch main git pull git branch -d feature/login这套流程并不复杂但它天然规避了很多问题每步都先确认status每次提交都有明确信息分支单独存在不会污染主分支。7.2 我踩过的真实“坑”记录别以为基本指令简单就不会出错。我踩过最典型的坑是在公共分支上用git reset --hard回退了错误提交然后强制推送。本意是想“把刚才的误提交删掉”结果远端同名分支上有同事刚推的新代码直接被我覆盖了。后来那位同事只能靠本地reflog找回提交浪费了不少时间。从那以后只要涉及远端共享分支我默认只用git revert。只有完全确信“这个分支只有我在用”才考虑reset push --force-with-lease。还有一个坑是在多个终端比如公司电脑和家里电脑同时操作一个仓库时忘了先git fetch就git status看到“nothing to commit”以为一切正常结果一git push才发现远端已经领先很多。所以我现在每天开工第一件事就是git fetch再git status让“本地视角”尽量贴近远端真实状态。7.3 什么时候该用git pull --rebasegit pull --rebase会拉取远端提交然后把你本地的提交“重放”到最新位置。它能让历史呈现为直线看起来很漂亮。但有两个前提需要满足本地的改动没有与他人共享。你熟悉解决rebase冲突的流程。如果你只是想给一个很“脏”的分支保持整洁可以用它。但如果你在一条已经多人协作的分支上反复rebase每次重放都会让别人被迫处理你的哈希变更反而更乱。所以我日常策略是个人功能分支上随意公共分支一律merge。8. 再聊几个“反直觉”但有用的指令细节8.1--分隔符的作用有些指令中会看到--后面跟文件路径例如git log --oneline -- path/to/file git checkout -- file这个--表示“接下来的参数是文件路径不是分支名”。当你想查看某个文件的历史git log --oneline -- src/main.c如果没有--Git可能会把src/main.c误认为路径或分支名这在不同上下文中行为不一致。虽然现代Git做了很多智能判断我还是建议学习阶段不省略--以避免歧义。8.2HEAD、HEAD~、HEAD^的含义回退指令中大量出现HEAD相关的记号HEAD当前提交。HEAD~1或HEAD~当前提交的父提交也就是上一个提交。HEAD~2上上一个提交。HEAD^第一个父提交在多人开发的merge提交中父提交可能不止一个^1是第一个父提交^2是第二个父提交。日常用HEAD~N就够了但遇到merge提交回退时要理解HEAD^1和HEAD^2分别指代两个分支的最后提交。我通过的场景是想回退到merge之前某个分支的状态这时用HEAD^1还是HEAD^2会直接决定你回到的是哪条分支的末端。8.3 如何给Git配置中文与差异工具顺带提一下环境配置。我在入职新公司第一件事是配置全局用户信息git config --global user.name Your Name git config --global user.email youexample.com没有正确用户信息时提交会提示失败或使用错误的身份。还可以设置默认分支名为maingit config --global init.defaultBranch main以及设置更友好的差异输出颜色git config --global color.ui auto这些配置虽然不属于“指令”本身但它们决定了你每次敲指令时的体验是否顺畅。基础指令掌握后这些细节会让你操作更顺手。结尾一点个人体会用过几年Git之后我对“基本指令”这四个字的理解其实已经不太一样了。刚开始觉得只要能把代码提交上去就完事后来发现最难的不是指令怎么敲而是“什么时候用哪个指令”以及“指令执行后会造成什么影响”。Git 基本指令数量不多但每个指令背后都有清晰的行为模型工作区、暂存区、版本库、本地、远端、HEAD指针。把这些模型吃透命令行带给你的掌控感是图形界面完全无法替代的。最后分享一个小习惯我每次在终端敲出带有reset、revert、push --force这类高危操作之前都会习惯性先敲一遍git status和git log --oneline -3确认自己的当前位置和待处理对象。这个慢动作看起来浪费时间但在状态混乱时它救过我太多次。希望这篇关于Git基本指令的梳理也能让你少走一些弯路。
阅读完成 · 觉得有帮助？
