Git入门不求人:用大白话讲清每一个核心命令 目录一. 初识Git1.1 Git是什么程序员的“时光机”和后悔药1.2 Git是怎么诞生的一个“被逼出来”的工具1.3 两种“管代码”的思路二. Git的安装别紧张这一步比你想象中简单三. 关于Git的动手操作让文件夹拥有“后悔能力”的全过程3.1 深入了解什么是版本库Repository3.2 跟着我开启你的第一次git实践3.3 工作区和暂存区你以后“改错能不能救回来”的关键3.4 我改错了怎么办3.5 删除文件Git里其实就一件事四. 远程仓库 GitHub SSH让你的代码开始“上网”4.1 SSH Key解决“你是谁”的问题重点五. 分支Branch在同一个项目里开“平行宇宙”5.1 分支是怎么回事5.2 git merge把两条开发路线“合并成一条”六. Git标签Tag给某一刻的代码“贴个纪念贴纸”七. 别把Git当成“背命令”把它当成“可回退的时间线”一. 初识Git1.1 Git是什么程序员的“时光机”和后悔药如果你刚开始学编程很可能会遇到一种很崩溃的情况明明只是改了一行代码结果整个项目突然就跑不起来了或者昨天还能正常运行的程序今天一打开就开始疯狂报错。这时候你盯着屏幕发呆脑子里只剩一句话“我到底改了什么”而Git就是专门用来解决这种“人类失忆现场”的工具。简单来说Git是一个用来记录你代码变化历史的工具你可以把它理解成一个超级详细的“自动存档系统”或者说是程序员专属的“时光机”。你每一次修改代码它都会帮你悄悄记录下来就像游戏里的存档点一样你随时可以回到某个正常工作的版本也可以对比不同版本之间到底改了什么。如果不用Git你的代码管理大概率会变成这样文件夹里全是各种版本比如final.py、final_final.py、final_final_v2.py、最终版真的不能再改了.py看起来像在玩一种“命名猜谜游戏”但有了Git之后你就不需要靠文件名来“记忆历史”也不用担心删错文件因为Git会自动帮你记录每一次修改的内容、时间甚至是谁改的。为什么说它是“时光机”因为当你把代码改崩了的时候不需要重写也不用熬夜找bug你只要告诉Git“回到之前那个正常的状态”它就能把整个项目恢复到过去的某个版本就像按下了时间倒退键一样。那为什么又叫“后悔药”因为你在开发过程中做的每一个“手滑操作”比如删错代码、重构翻车、改完更乱都可以随时撤销就像你可以随时说一句“算了当我没做过”。所以Git本质上做的事情其实很简单它帮你把代码的每一次变化都存下来让你可以随时回到过去、对比现在、甚至撤销错误操作。等你真正开始用它之后你会发现它解决的不是“怎么写代码”而是“写崩了怎么办”这个更现实的问题。1.2 Git是怎么诞生的一个“被逼出来”的工具Git的出现并不是那种“优雅设计、缓慢演进”的故事而更像是工具被人突然收走之后只能自己动手重写一个的极限操作。在很长一段时间里Linux 内核开发团队使用的是一个叫 BitKeeper 的版本控制工具它在当时算是比较先进的方案但问题在于它不是完全开源免费的工具对 Linux 社区这种“人人都要自由”的生态来说本身就埋着隐患。后来双方关系变化BitKeeper 不再允许免费使用这一下等于直接把 Linux 内核开发团队的“代码管理系统”给掐断了——要知道这可是全球最复杂、参与人数极多的开源项目之一相当于一个超级工程突然没有施工管理系统了。于是Linus Torvalds不得不亲自下场解决问题他的想法很直接既然现有工具不可靠那就自己写一个更快、更稳定、更适合大规模协作的版本控制系统。这个新工具必须满足几个很“狠”的要求速度要快到能处理整个内核项目的历史数据结构要简单到不会轻易出错最重要的是不能依赖任何可能被卡脖子的商业工具。于是 Git 在 2005 年诞生了它一开始并不是为“普通开发者友好”设计的而是为了“解决全球级别开源协作危机”而生。它采用了一个非常关键的思路不再依赖中心服务器每个开发者本地都保存完整的代码历史这样即使网络断开或者服务器出问题开发也不会中断。所以 Git 的诞生逻辑其实很简单粗暴不是因为“想做一个更好的工具”而是因为“必须马上有一个能替代旧工具的方案”。但有意思的是这个被紧急造出来的工具后来却变成了全世界几乎所有程序员都在用的标准工具。1.3 两种“管代码”的思路在理解 Git 之前你必须先搞清楚一件事版本控制系统到底是怎么“管代码历史”的而这里主要有两种思路——集中式和分布式本质上就是“资料放一份还是人人都有一份”的区别。先说集中式版本控制比如早期常见的 SVN它的思路很简单所有代码和历史记录都放在一台中央服务器上大家都通过这台服务器来获取代码、提交修改。你可以把它理解成一个“共享网盘”所有人都在往同一个地方读写文件。这样做的好处是结构简单、容易管理管理员想控制权限也很方便但问题也很明显如果服务器挂了大家就都没法工作了如果网络不稳定你连提交代码都可能卡住相当于“没网就没法写作业”。再来看分布式版本控制以 Git 为代表它的思路就完全不一样了每个人电脑里都有一份完整的代码仓库包括所有历史记录。也就是说不存在“唯一的中心服务器依赖”每个人都是一个完整的备份点。你可以把它想象成不是大家共用一个网盘而是每个人电脑里都有一整份“全量副本”需要同步的时候再互相传递更新。这种结构的好处非常明显哪怕服务器坏了你本地照样可以提交、查看历史、甚至恢复版本哪怕在没有网络的情况下你也可以正常开发。它更像是“去中心化的存档系统”每个人都是独立但又可以协作的节点。但分布式也不是没有代价它的复杂度比集中式更高比如你需要理解“本地仓库”和“远程仓库”的概念还要处理同步和冲突的问题。不过换来的好处就是更稳定、更灵活也更适合大规模协作开发。简单总结一下就是集中式像“一个共享服务器管所有人”分布式像“每个人都有一份完整备份再通过网络互相同步”。而 Git 选择的是后者因为它更抗风险也更适合现实世界那种“网络不可靠、人多且混乱”的开发环境。二. Git的安装别紧张这一步比你想象中简单Git安装没什么复杂的本质就是去官网把软件下下来然后一路点“下一步”最后检查一下有没有装成功就这么简单。 先去官方下载别乱搜容易踩坑https://git-scm.com/install/进去之后它会自动识别你的系统Windows用户直接点下载macOS和Linux也都有对应版本。下载完成后Windows直接双击安装包然后一路“Next下一步”就行中间的选项不懂就别改保持默认基本不会出问题。安装完你会看到一个叫Git Bash的东西它就是以后敲Git命令的地方。装完之后打开命令行输入这一句检查如果能看到版本号比如git version x.xx.x说明安装成功。最后别忘了做一个简单设置不然以后提交代码会不知道是谁干的总结一句大白话就是下载Git → 安装 → 输入一行命令确认 → 顺手告诉它你是谁就完事了。(这里的重点其实在--global它的意思是——这台电脑上所有Git项目都会默认用这一套身份信息。也就是说你只需要设置一次之后不管你新建多少仓库它都会自动带上这个名字和邮箱。但也别误会它不是“锁死”的。如果你在某个项目里想换身份比如公司项目和个人项目分开管理是可以在那个项目里重新单独设置的这时候就只对当前仓库生效会覆盖全局配置。)三. 关于Git的动手操作让文件夹拥有“后悔能力”的全过程前面说的Git可以理解成一个“帮你记录代码变化的工具”但真正开始用起来的时候你会发现一件事它不是一上来就帮你存档的而是要你一步一步“授权它记录”。而这个被Git管理、可以保存历史的地方就叫版本库Repository。3.1 深入了解什么是版本库Repository版本库本质还是一个文件夹但它和普通文件夹最大的区别是它会记录每一次文件的变化历史而不是只保留当前状态。普通文件夹只知道“现在是什么样”版本库则知道“你是怎么一步步改成现在这样的”。你可以把它理解成普通文件夹只看“当前这一版”版本库不仅看当前还能翻“历史版本”一旦这个文件夹被Git接管它就不再只是存文件的地方而是一个可以回溯历史的“记录系统”。3.2 跟着我开启你的第一次git实践你现在可以把Git理解成一个很实在的过程它不是一上来就帮你记录而是你一步一步告诉它“开始管我这个项目”。比如你新建了个文件夹GitDemo/文件夹里新建个文件名为index.html其中内容为:h1Hello Git/h1此时它只是普通文件夹Git还没参与。 先进入这个文件夹然后执行这一步的意思很直接把这个文件夹升级成版本库让Git开始接管它的历史记录。执行完以后在GitDemo/里会多出一个隐藏目录.git/这个东西就是版本库的核心所有历史都存在里面。接着我们看看Git现在的状态你会看到类似提示说明文件还没被管理Untracked files: index.html意思是Git看见了但还没开始管。 然后我们告诉Git这个文件我要纳入管理或者你可以把当前文件夹下的所有文件一次性加进去再看状态这时候文件已经进入“待记录状态”但还没真正保存历史。真正关键的一步是提交这一刻Git才真正做了一件事把当前代码状态存成一个版本快照存档点。然后你可以继续修改文件比如将index.html中的内容增加一行h1Hello Git!!!/h1p我被修改了/p再执行你会看到它说文件被修改了但它不会告诉你具体改了哪里。这时候就轮到一个非常重要的命令登场git diff 是干什么的一句话git diff 用来显示“你到底改了什么”它会直接把变化“摊开给你看”比如哪一行被删了哪一行被新增了改动的具体内容是什么你可以把它理解成 Git的“改动对账单”它会显示-h1Hello Git/h1h1Hello Git!!!/h1p我被修改了/p解释一下-表示删除的内容表示新增的内容这样你就能非常清楚地看到“这一版到底动了哪里”。然后重复现在你就有两个版本记录了。最后你可以查看历史它会列出所有提交记录相当于你的“代码时间线”。一句话总结版本库就是“被Git管理的文件夹”git init让它开始有记忆git add告诉它哪些改动要记录git commit才是真正生成一个历史版本点从此你的代码可以随时回退、对比和追溯。3.3 工作区和暂存区你以后“改错能不能救回来”的关键在 Git 里很多人第一次懵的不是命令而是一个问题“我刚刚改的东西到底算不算已经被Git记住了”而答案就藏在两个地方工作区和暂存区。你先不用记概念先记一句话Git不是一个“改了就存档”的系统它是一个“分阶段确认”的系统。也正因为这样才有后面“改错了还能救”的空间。 工作区你正在“动手改代码”的现场工作区就是你真实写代码的地方比如你打开文件h1Hello Git/h1你把它改成h1Hello Git!!!/h1这一刻发生的事情只有一件你改了文件但Git还没参与所以如果你现在关掉电脑Git是完全不知道你改过什么的。 暂存区Git帮你“记一半但还没存档”当你执行Git做的事情不是“保存版本”而是把你刚刚的修改先放进一个“待确认列表”也就是说这一步只是告诉Git“这一版我准备提交了但还没最终决定”为什么这个结构很重要重点来了现在你可以把“改错问题”提前理解进去因为 Git 的核心设计就是❗ 不是所有改动都会立刻变成历史所以它才允许你还在工作区 → 随便撤回还没进Git视野进了暂存区 → 可以取消还没存档提交之后 → 才算正式历史你可以把 Git 想成一个分步骤存档的游戏工作区 你正在操作角色还没存档暂存区 你按了“准备存档”但还没确认commit 真正存档成功等你学到“改错恢复”时其实就是在利用这套结构工作区错了 → 直接丢掉暂存区错了 → 取消 addcommit 错了 → 回退版本也就是说你之所以能“后悔”就是因为 Git 把流程拆成了三层3.4 我改错了怎么办写代码最真实的瞬间不是“我写完了”而是“我刚刚到底改了什么”更真实一点是**“我一不小心把好代码改没了。”**而Git之所以被称为“后悔药”核心就是它真的能帮你把这些离谱操作拉回来。先说一个最基础的情况你改了一堆代码但还没提交也就是还没git commit这时候你突然发现写崩了想回到刚刚的状态。如果你只是修改了文件还没有执行git add那很简单一句命令直接撤回比如你改错了index.html中的内容想对这个文件进行回退这句话的意思是把这个文件恢复成“上一次提交之后”的样子你刚才乱改的内容直接消失就像没发生过一样。不过注意这一步有点“无情”它不会问你“要不要保存”它是直接覆盖回去的所以用的时候要清楚自己在干什么。如果你已经执行了git add但还没git commit情况就稍微不一样了。这时候你的改动已经被放进“待提交区”如果你后悔了可以先把它从暂存区撤出来这一步的意思是告诉Git“这次改动我先不提交了”但文件内容还在。也就是说它只是把“准备提交”这个动作取消掉而不是删除你的修改。如果你已经git commit了也别慌这时候Git真正的“时光机能力”才开始发挥作用。你可以先看看历史记录它会列出所有提交版本就像一条时间线每个提交都有一个编号commit id。如果你想回到某个版本比如回到“没改崩之前”可以用这一步的效果是整个项目直接回到那个版本的状态后面所有修改都会被“时间倒流”覆盖掉。但这里有一个更现实的情况有时候你只是想“撤销某次提交”但又不想彻底丢掉历史这时候可以用它不会删除历史而是生成一个“反向操作”的新提交相当于“我承认我做错了但我要用一条新的记录把它改回来。”一个简单的理解框架Git的“后悔方式”其实分三层还没 add直接撤回修改最轻松已经 add取消暂存改动还在已经 commit回退版本或反做一个新版本3.5删除文件Git里其实就一件事在Git里删除文件本质很简单但很多人会卡在一个细节到底要不要git add其实答案分情况看你怎么删。情况一用 Git 删除推荐如果你用的是 Git 提供的命令那它已经帮你做完两件事了删除文件自动加入暂存区所以你不需要再执行git add直接提交就行情况二手动删除文件容易忽略如果你是在文件夹里直接删的右键删除 / 手动拖进回收站Git只会“发现变化”但不会帮你处理。这时候你需要手动告诉Git四. 远程仓库 GitHub SSH让你的代码开始“上网”在继续之前先搞清楚一件事你现在写的代码其实一直都在“本地电脑”里也就是只属于你自己。但真实开发中代码通常需要放到网上让别人能看到、下载、一起改这个“放在网上的Git仓库”就叫远程仓库。而最常用的远程仓库平台就是GitHub。https://github.com/你可以把 GitHub 理解成一个“程序员版的网盘 协作平台”你可以把代码上传上去备份别人可以下载你的代码开源 / 协作多个人可以一起改同一个项目团队开发所有修改都有历史记录不会乱4.1 SSH Key解决“你是谁”的问题重点当你开始用 GitHub 之后很快会遇到一个现实问题GitHub 怎么知道“这个上传代码的人是你”这里就引入 SSH Key。你可以把它理解成一句话SSH Key 就是你电脑的“长期身份钥匙”用来证明“这个操作是你本人”有了它之后你以后 push / clone 都不需要每次输入账号密码。第一步生成 SSH Key只需要做一次打开终端执行ssh-keygen -t ed25519 -C your_emailexample.com一路回车即可新手不用改任何选项。生成后会得到两个文件~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub其中.pub是公钥要交给 GitHub。第二步把钥匙交给 GitHub先查看公钥内容cat ~/.ssh/id_ed25519.pub复制整段内容然后进入 GitHubSettings → SSH and GPG keys → New SSH key填Title随便写比如 my laptopKey粘贴刚刚复制的内容保存即可。第三步用 SSH 克隆 GitHub 项目关键步骤现在才是你真正“用 GitHub 下载代码”的时候。我们用 GitHub 官方示例项目GitHub 示例项目 Hello-World它的 SSH 地址是gitgithub.com:octocat/Hello-World.git执行克隆git clone gitgithub.com:octocat/Hello-World.git这一刻发生的事情是GitHub 看到你的 SSH Key → 确认你是授权用户 → 直接允许下载完整项目你本地会得到一个完整项目文件夹可以直接进入开发。顺便理解以后 push 也一样用 SSH如果你自己创建了仓库比如gitgithub.com:yourname/GitDemo.git绑定远程仓库git remote add origin gitgithub.com:yourname/GitDemo.git第一次推送git push -u origin main以后就可以直接git push不会再让你输入账号密码。GitHub SSH 其实就是一件事GitHub 是代码平台SSH Key 是你电脑的“身份证”Git 只是帮你把代码传上去或拉下来五. 分支Branch在同一个项目里开“平行宇宙”如果你之前一直在本地玩 Git那分支的作用可以一句话说清楚分支Branch就是在同一个 Git 项目里从某个时间点“分出一条独立开发路线”让你可以并行修改代码而互不影响。简单说就是同一个项目可以同时有多个“版本发展方向”。但现实开发里不止你一个人在写代码还会有 GitHub 上的远程分支所以这件事会变成你不仅有自己的分支还能看到别人正在怎么改。5.1 分支是怎么回事比如你现在在做一个网站有主分支mainA → B → C稳定版本你要做登录功能就开一个分支git branch login git checkout login或者直接一步git switch -c login然后你就在 login 分支里开发不影响主线。这里要再补一句核心理解分支其实就是“指向某一条提交历史的指针”Git只是帮你切换不同指针对应的开发路线。但真实情况代码通常在 GitHub 上比如你用 GitHub 上的项目GitHub 示例项目 Hello-World你 clone 下来之后其实已经和远程仓库绑定了而远程仓库上往往不止一个分支比如 main、develop、feature-x 等。关键补充理解本地分支 ≠ 远程分支的完整复制本地只是“同步后的镜像视图”。怎么看“远程分支”查看所有分支包括远程git branch -a你会看到main * login remotes/origin/main remotes/origin/feature-x解释一下main/login本地分支你电脑里的开发路线remotes/origin/mainGitHub 上主分支的“影子”remotes/origin/feature-x远程仓库中的其他开发路线再强调一句remote/origin 开头的分支才是 GitHub 上真实存在的分支映射。怎么把远程分支拉下来比如你看到远程有origin/feature-x你可以直接切换git checkout feature-x如果本地没有它会自动创建并绑定远程分支。或者更明确一点git switch -c feature-x origin/feature-x意思是把 GitHub 上的 feature-x 分支复制到本地并建立追踪关系本地分支和远程分支的关系你可以这样理解本地分支 你电脑里的开发路线远程分支 GitHub 上共享的开发路线git branch -a 查看所有路线本地 远程推送分支到 GitHub你在本地创建新分支git switch -c login开发完成后推送git push -u origin login作用是把本地分支上传到 GitHub在远程创建同名分支让别人也能看到和协作Git分支本质上就是一条独立的提交历史线而“本地/远程”只是这条线存放的位置不同简而言之分支 从某个时间点分出去的一条独立开发路线本地分支 你电脑上的开发路线远程分支 GitHub 上共享的开发路线git branch -a 查看所有分支本地 远程git checkout -b xxx origin/xxx 把远程分支搬到本地git push 把本地分支同步到 GitHub5.2 git merge把两条开发路线“合并成一条”如果你已经学了分支Branch那你一定会遇到一个必然问题分支开了之后怎么把新功能“带回主线”答案就是这条命令git merge一句话理解 mergegit merge 就是把“另一条分支的修改内容”合并到当前分支里。注意这句话有个非常重要的点合并的是“分支的变化”不是复制文件一个最典型的场景假设你现在有两个分支main A → B → C稳定版本 feature C → D → E新功能你在 feature 分支开发完新功能了现在要把它合并回 main。第一步先切到目标分支很关键你想把 feature 合并到 main那你必须先站在 main 上git checkout main或者git switch main记住一句话谁被合并谁就“站在当前分支”第二步执行 mergegit merge feature这一刻 Git 做的事情是把 feature 分支上的提交“接到” main 后面结果变成mainA → B → C → D → Emerge 到底发生了什么Git不会“复制代码”而是做了一件更聪明的事找到两个分支的共同祖先对比差异把差异整合进当前分支所以 merge 本质是“历史记录的合并”不是文件复制可能会遇到的情况冲突conflict如果两个分支改了同一段代码比如main h1Hello/h1 feature h1Hello Git/h1Git就会懵❗ 这段到底听谁的这就叫冲突conflict需要你手动选择保留哪一部分。合并完成后要不要提交一般情况下merge 成功后会自动生成一次 commit合并提交如果有冲突需要你解决后再 commit和 GitHub 的关系在 GitHub 上merge 最常见的形式是Pull RequestPR本质就是feature 分支 → 提交 PR → review → merge 到 main六. Git标签Tag给某一刻的代码“贴个纪念贴纸”如果说分支Branch是“继续往前走的不同路线”那标签Tag就是另一种完全不同的东西Tag标签就是给某一次提交打一个“永久标记”表示这一刻很重要。它不会再变化也不会往前走更不会像分支那样继续分叉。你可以把它理解成分支是“开发路线”标签是“里程碑截图”。为什么需要标签在真实开发里你经常会遇到这种情况做完一个大版本比如 v1.0上线一个重要功能发布一个稳定版本这时候你不想用一串 commit id 去记a3f2c9d...? b91ddaa...?太难记了。所以 Git 提供了 Tag用一个“人类能看懂的名字”标记某个提交比如v1.0v2.0release-2026stable创建一个标签非常简单假设你当前代码已经稳定可以发布 v1.0git tag v1.0这一步的意思是给“当前这个 commit”贴一个名字叫 v1.0 的标签查看所有标签git tag可能会看到v1.0 v1.1 v2.0标签和 commit 的关系标签本质上是“指向某个 commit 的固定指针”。也就是说分支会动一直往前标签不会动永远固定在某一刻给历史提交打标签进阶但很常用如果你想给某个旧版本打标签可以这样git tag v0.9 a1b2c3d意思是给指定 commit id 标记为 v0.9把标签推送到 GitHub默认情况下tag 不会自动上传需要手动推git push origin v1.0如果有很多标签可以一次性推git push origin --tags在 GitHub 上Tag 通常用来表示发布版本Releases软件正式上线版本稳定可用版本你可以在 GitHub 的 “Releases” 页面看到它们。一个非常重要的理解Tag 和 Branch 最大区别是Branch会继续变化开发线Tag固定不动历史标记Git标签就是给某个重要提交“贴个名字”用来标记版本节点它不会像分支一样变化而是固定保存某个关键时刻的代码状态。七. 别把Git当成“背命令”把它当成“可回退的时间线”Git 到这里其实已经算是带你从“完全不懂”走到了“能真正开始用”的阶段了。你现在看到的这些命令本质上不是为了记住而是为了理解它们在做什么记录版本、管理分支、同步远程、以及在出问题时还能有办法回到过去。如果你在实际使用 Git 的过程中遇到了报错、看不懂的提示或者某一步操作结果和预期不一样不用硬扛着去猜直接把问题发出来会更高效一些。可以把你遇到的 Git 问题或者卡住的地方留在评论区我会尽量帮你拆开讲清楚。