1. 创建第一个仓库先搞懂仓库到底存了什么很多人第一次接触 Git 仓库时脑子里总会冒出一堆问题这个叫.git的隐藏文件夹是什么我的代码明明就在文件夹里为什么不直接复制一份就当备份为什么我写了代码git status 却提示我什么都没有发生这些问题本质上都指向同一个核心你还没有理解 Git 仓库和你平时看到的项目文件夹之间的关系。1.1 一个仓库拆成三块工作区、暂存区、版本库我用一个最容易理解的类比来说明。你平时写的代码文件躺在你的项目目录里这部分叫工作区。你在命令行执行git init之后项目目录下会多出一个.git隐藏文件夹这里面装着 Git 真正管理的东西也就是版本库。版本库内部又分成了两块一块叫暂存区英文叫 index 或 stage另一块是真正存储每次提交记录的提交历史也就是一个个 commit 节点。三者的关系可以这样理解工作区是你桌面上正在写的草稿暂存区就像一个中转筐你把草稿里想交给 Git 保管的文件放进去最后按一下归档按键也就是git commit这些文件才会正式进入提交历史变成一条永久记录。之后你想回退到任何一个历史版本都有据可依。这个设计最巧妙的地方在于提交动作被拆成了两步。如果你只需要提交部分文件完全可以在 add 阶段精准挑选而不是把整个目录一股脑塞进历史。日常开发里这种挑文件提交的频率非常高比如你改了三个文件但只想先提交其中两个另一个还没写完那就不碰它只 add 需要的。1.2 git init 之后发生了什么执行git init之后Git 会在当前目录下创建.git文件夹并把默认分支名初始化为 master 或 main具体取决于你的 Git 版本和配置。从 Git 2.28 开始默认分支名可以通过git init -b main显式指定也可以用git config --global init.defaultBranch main来做全局设置。.git文件夹里有一些核心文件比如config存放仓库级别的配置HEAD记录当前分支指向哪个引用objects目录用于存储所有提交和文件快照。你不必逐个记住但至少要明白只要这个文件夹存在你的项目就算进入了 Git 的管辖范围。注意.git文件夹里存放的是 Git 的元数据和版本历史正常情况下不要手动修改里面的文件。我见过有人直接编辑.git/config改坏了仓库最后只能靠备份恢复。如果你需要改仓库配置请用git config命令去操作它更安全也更符合规范。还有一个细节很容易被忽略git init是安全的重复执行也不会报错它只会补全缺失的目录结构不会覆盖已有的历史记录。所以就算你不小心初始化了两次也不用慌。2. 从 0 到 1创建仓库的完整实操流程现在真正动手。你不需要把概念背得滚瓜烂熟先跑通一遍流程跑完再回头看概念感受完全不一样。2.1 三种初始化仓库的方式怎么选第一种在本地已存在的项目目录里初始化。这是最常见的情况。假设你有个项目叫my-blog里面已经有一些源码文件你只需要进入目录执行cd my-blog git init执行完Git 只会输出Initialized empty Git repository in ...这样一行提示然后你的项目目录就多出了一个.git。此时所有文件还没有被 Git 追踪你需要手动 add 和 commit。第二种从零开始建新项目。你先创建一个空目录初始化仓库然后再往里面放文件。流程大概是mkdir new-project cd new-project git init这样做的意义在于你可以先创建好分支策略、.gitignore文件再去推代码从一开始就保持仓库整洁。第三种直接克隆远端仓库。如果你要参与一个已有项目用git clone一步到位远端的所有提交历史和分支都会拉到你本地不需要额外执行 init。我自己的习惯是新项目一律先 git init再写.gitignore然后创建主分支最后才写第一行代码。这样整个过程中 Git 始终在背后盯着每一步改动都能被追踪到避免后期才想起要建仓库导致一堆文件堆在 untracked 状态里不好整理。2.2 第一次提交的正确姿势初始化完成后第一件该做的事是设置用户信息。如果你从没配置过commit 时会报错或者失败。设置方式git config --global user.name 你的名字 git config --global user.email 你的邮箱这里用--global表示对所有仓库生效。如果你只是想对当前仓库单独设置去掉 --global 即可。设置完你就可以把所有文件加入暂存区并提交了git add . git commit -m Initial commit: 项目初始化git add .会把当前目录下所有未忽略的文件加入暂存区。首次提交时这个操作没太大风险但后续日常使用就要小心了如果你写好了.gitignoregit add .基本安全如果没写它会把你项目里的临时文件、日志文件、依赖包全都拉进去历史记录瞬间变成垃圾堆。提交完成后用git log --oneline能看到一条记录这就代表你的第一个仓库正式可用了。实操心得第一次提交的 commit message 建议写清楚项目初始状态。我见过有人直接写 first以后翻历史压根看不出来哪个版本是起点。建议格式是chore: init project或者Initial commit配上简单的概要说明干净又明确。3. 日常高频操作add、commit、status、diff 的深度理解仓库建好了接下来每天的流程就是改代码、查看状态、暂存、提交。这几个命令看起来简单但如果理解得不够扎实后面各种莫名其妙的问题都会从这里冒出来。3.1 git status 输出信息怎么读git status是每天使用频率最高的命令之一它的输出其实就是在告诉你工作区、暂存区和版本库三者之间的差异。当你改了一个文件但还没 add 时status 会显示在 Changes not staged for commit 部分当你 add 了但还没 commit 时会显示在 Changes to be committed 部分如果你的目录里有全新的文件会显示在 Untracked files 部分。新手最容易犯的错是看到输出里有东西就慌以为代码丢了。其实 status 永远只是描述状态不会动你的文件。你要做的只是根据它的提示决定下一步是 add、commit 还是 reset。我见过一个高频场景有人改了配置文件然后 git add 了接着又改了一次再 commit。结果提交进去的是第一次的版本第二次的改动还在工作区里没被追踪。原因正是git add只记录当时的内容后面再改不会自动更新到暂存区。解决方法是改完代码后习惯性地用git status看一眼或者直接git add后再 commit。3.2 撤销操作reset 和 restore 到底该用哪个Git 在 2.23 版本之后把撤销操作的命令做了拆分git restore和git reset职责更清晰了但很多人到现在还是搞混。如果你只是想撤销工作区的改动也就是把某个文件恢复到最近一次提交或暂存时的样子用git restore 文件名这个命令会直接覆盖工作区的文件而且没有弹窗确认。如果你对文件里改了什么内容记得不清别轻易用否则想找回被覆盖的内容就只能靠编辑器缓存或者 IDE 的本地历史了。如果你想撤销暂存区的状态也就是把已经 add 的文件退回成未 add 的状态用git restore --staged 文件名或者用更传统的git reset HEAD 文件名。这两个效果一样只是一个出自新版拆分后的命令体系一个出自老版命令。如果算上彻底的版本回退比如你提交错了想回到上一个提交可以用git reset --hard HEAD~1这个命令的含义是把当前分支指向上一个提交同时把工作区和暂存区都重置成那个提交的状态。注意这是一个不可逆操作任何未提交的改动都会被丢弃。我建议新手在还没完全理解工作流之前慎用--hard特别是在代码还没有任何备份的情况下。3.3 diff 和 log怎么查看谁改了什么git diff用于查看没有暂存的内容差异git diff --staged用来查看已经暂存但还没提交的差异git log用来查看提交历史。实际的调试场景往往是这样的你改了一堆代码想确认自己改了哪些地方先运行git diff看到的是一片绿色和红色的行绿的是新增的红的是删除的。确认没问题add 一下再运行git diff --staged看看到底提交给版本库的内容是不是自己想要的。最后 commit再用git log --oneline -5看最近五条提交记录。这里有个实用小技巧git log -p可以同时显示每次提交的具体改动内容比单纯看 commit message 更能理解每次提交做了什么。如果你在排查一个 bug想确认某个文件是哪次提交改坏的用git log -p 文件名就能精确定位。4. 分支和远程仓库你以为的进阶其实是基础很多新手把分支当成高级玩法认为先学会提交就够了。实际上分支就是 Git 日常工作的常态。哪怕你一个人写项目分支也能帮你隔离不同功能更别提协作场景了。4.1 分支的创建、切换和删除创建一个新分支并切换过去git branch feature-login git checkout feature-login或者更简洁的写法git checkout -b feature-login在新分支上做的提交不会影响 main 分支除非你执行了合并。这种机制让把未完成的功能留在分支上随时切回干净的主线成为可能。合并分支git checkout main git merge feature-login删除分支git branch -d feature-login注意-d只允许删除已经合并过的分支如果分支上有未合并的提交Git 会拒绝删除并提示你。如果确实想强制删除用-D参数。这个设计是为了防止你误删还有价值的提交历史。我见过不少新手在两个分支之间来回切换结果忘了当前分支是谁把代码提交错了地方。应对办法是养成在终端提示符里显示当前分支名的习惯或者每次切换前用git branch确认当前分支。这个习惯花不了几秒钟但能省下大把后悔的时间。4.2 连接远程仓库并推送讲远程仓库之前先明确一个概念本地仓库和远程仓库是两个独立的 Git 仓库。你需要主动推送或拉取它们才会同步。远程仓库不自动跟着你的 commit 走。假设你已经在 GitHub 或 Gitee 上创建了一个空白仓库页面上通常会给出仓库地址类似这样git remote add origin gitgithub.com:username/my-project.git git branch -M main git push -u origin main第一行把远端仓库地址绑定到本地并给它起了个名字叫origin这个名字只是个惯例叫其他名字也行。第二行把本地当前分支重命名为 main如果之前你已经确认默认分支就是 main这步可以跳过。第三行把当前分支推送到远端-u参数的作用是建立追踪关系之后你在这个分支上直接敲git push就能推到对应远端分支不用再写长串地址。之后每次想发布代码只需要git add . git commit -m 功能描述 git push这里有个容易踩的坑如果你在仓库创建页面里勾选了添加 README或添加 .gitignore那么远端已经有一个提交了。你第一次 push 时就会遇到冲突报错提示像这样failed to push some refs。解决方法是先 pull 一次或者强制 push但强制 push 有风险会覆盖远端记录。实操心得我的习惯是不要在 GitHub 网页端初始化任何文件仓库页面上能勾选的选项全部留空创建一个纯空仓库。这样本地 init 之后再绑定第一次 push 永远干干净净不会出现合并冲突的问题。5. 从零起步正确移除仓库怎么删 Git 仓库才不留坑既然聊到删除git仓库这里必须先说清楚删除 Git 仓库这个操作常见的有三种理解对应三种完全不同的处理方式千万别搞混。5.1 完整删除本地仓库rm -rf .git如果你想彻底放弃当前项目的 Git 管理让项目恢复成一个普通文件夹直接删除.git目录即可rm -rf .git执行完后git status会提示这不是一个 Git 仓库。从此这个目录下的历史记录、分支信息、所有提交全部消失无法找回。所以执行之前请先确定这些历史确实不需要保留了。这个操作在什么场景下会用到呢比如你把项目推错了远端仓库想重新初始化绑定到正确的仓库或者你接手了一个巨大的历史记录想要一个全新的干净的起点。也有人用它来清理仓库把体积膨胀的.git完全重建让仓库恢复轻量。5.2 只删远端不删本地移除远程仓库关联如果你只是想把当前项目和某个远端仓库解绑不想删除本地任何代码和提交记录执行git remote remove origin之后本地仓库依然保留全部提交历史只是不再有 origin 这个远端别名。你的代码不会丢你的历史不会丢只是和远端断开了连接。另一种情况是你想把远端仓库清空但保留本地历史可以用git push origin --delete 分支名或者直接把远端仓库在网页端删掉再新建一个空的。这样本地仓库 push 时只需要重新绑定新地址即可。5.3 删除文件但保留历史这才是最常见的需求大部分人说删除 git 仓库时其实只是想把某个文件从 Git 的追踪里移除但保留本地文件。比如你把config.local.js误提交进了仓库现在想让他不再被追踪但又不想删除本地文件git rm --cached config.local.js echo config.local.js .gitignore git commit -m 停止追踪 config.local.jsgit rm --cached的作用是把文件从暂存区移除但保留工作区的文件。加上--cached是为了只解除追踪不删除磁盘文件。这一步做完后续改动就不会再被 Git 追踪但它之前的历史提交依然保留在版本库里。如果你连历史也想彻底抹掉操作会复杂很多那是另外一篇文章的内容了。注意git clean -fd这个命令会删除所有未追踪的文件其中就包括那些你辛辛苦苦生成的配置、临时文件甚至本地数据库。执行之前务必先运行git status看清楚有哪些 untracked 文件确认它们都不需要保留再运行删除命令。我见过一个同事在这个命令上踩了坑项目里的本地配置文件全部被清空花了一个下午才从别人电脑上拷回来。6. 新手的独立避坑指南常见问题记录与排查思路跑完以上流程你基本掌握了 Git 的日常操作。但这只是开始。实际上手时你还会遇到一批很典型的报错和异常状态这里集中排查一遍。6.1 身份未设置导致的提交失败第一次执行的 submit 时Git 可能会直接拒绝并提示Please tell me who you are.原因很简单你没设置 user.name 和 user.email。Git 的每次提交都必须携带作者信息这是它追溯责任和历史的根基。解决方法是按前面提到的方式配置 user.name 和 user.email然后重新提交。这个报错不意味着你的改动丢了提交失败只是中断了重新配置后继续即可。这里有个容易被忽略的知识点如果你同时设置了全局和仓库级别的用户名仓库级别的优先级更高。不同项目想用不同身份提交时在仓库内单独设置即可不必频繁改动全局配置。6.2 误删了文件怎么办如果你用git rm删除了文件或者手动删除后又提交了但突然发现这个文件其实还需要怎么恢复如果删除还没提交直接用git restore 文件名如果删除已经提交了恢复到上一个提交git checkout HEAD~1 -- 文件名这条命令会从上一个提交里取出该文件覆盖到当前工作区。之后你再 add 和 commit文件就回来了它原来的提交记录也不会丢失。这个场景提醒我一个建议不要在没确认的情况下随手执行git checkout .或者git restore .它们会把你当前工作区所有未提交的改动全部还原。如果这些改动里有一部分是你辛苦调了半天的结果后悔都来不及。稳妥的做法是先查看git diff确认改动内容再做操作。6.3 分支冲突怎么处理合并分支时发生冲突是最常见也最让人紧张的场景。报错会提示某个文件存在冲突然后你打开文件会看到类似下面这样的标记 HEAD 这是当前分支的代码 这是被合并分支的代码 feature这其实是在告诉你两个分支的代码在同一个位置各说各话Git 无法自动决定该保留哪个。你需要手动编辑文件删掉这些、、标记把内容整理成最终想要的样子保存后执行git add 文件名 git commit -m 解决冲突冲突并不可怕它只是 Git 在保护你的代码防止自动合并时悄悄丢掉某一边的修改。处理冲突要冷静先看清两边代码分别是什么想清楚哪一边才是当前需求的或者两边需要融合然后再动手编辑。6.4 提交错了分支怎么办很多人都有过这种经历明明想提交到 feature 分支结果切到 main 分支提交了。不用慌也千万不要手动复制文件到处乱放正确的搬移方法是先把文件从错误分支的暂存区里取回来git reset HEAD~1 --soft这个--soft参数很温和不会动工作区的文件只会把提交记录撤销一步所有改动回到暂存区。然后切换分支git checkout feature-login重新提交git commit -m 提交到正确分支如果你的改动还没有被提交只是 add 在了错误的分支上那就更简单了切到正确分支后直接 commit因为暂存区的内容跟着分支走改动不会丢。7. 对这些操作后的个人体会创建第一个仓库的流程并不复杂真正花时间的是建立起对 Git 工作原理的感知。刚开始用的时候我总把 Git 当成一个网盘以为 commit 一次就是上传一次其实完全不是。Git 是一个内容的快照系统每一次 commit 都保存了当时所有追踪文件的完整状态它能让你在任何时间点恢复出那个时刻的整个项目。理解这一点之后你对删除 git 仓库重置分支回退版本这些操作的理解都会上一个台阶。根据我做过的项目经验我现在建仓库的固定流程是先 git init再写 .gitignore然后配置好分支名把初始文件提交进去再绑定远端推送。整个过程不超过五分钟但之后每一条提交都清清楚楚项目的历史脉络一目了然。如果你刚开始使用 Git不用急着背命令先从创建一个本地仓库、提交一次代码开始跑通这个最小的闭环剩下的所有命令你都会慢慢用得上的。