Git 到底是干啥的？零基础小白听完都懂了并且轻松驾驭它

git，通俗的来说就是一种用来多人文件版本合作的工具，但是对一些非程序员的项目小白或者没有程序基础的但是想要入行做程序员的人来说，完完全全理解起来稍微有点困难。这篇文章不像很多文章一样是枯涩的码字教学。现在，我们就用最通俗易懂的方式，让你从零基础理解他，并且使用他。这种教学方法不是把你当白痴的教学方法，反而是让你快速入门深刻理解它，并记住它的教学方法。因为可能说得比较详细，篇幅较长，还得请你耐心的把他看完。

一、git的作用

1、git的版本控制

文件永远不会只有一个版本，这句话我们似乎用亲身经历证明过。你是否有过以下经历👇

📘论文会有"终稿v1、终稿v2、终稿最终版"、

✍设计稿会有"改版A、改版B、改版C"、

🧺甚至自己写的文章也会来回改十几遍。

🥚更不用说单独只通过一个本地夹操刀一个大型项目了

突然有一天你觉得你的论文、设计稿、文章、项目某一个节点开始脱离了原本的方向或者发生了一些错误，但是你已经对其进行多处修改了，单独再修改不仅费事废经历，还容易发生遗漏。

你或许信誓旦旦的告诉我，你可以这样做。。。👇

论文_最终v1.docx

论文_最终_改过的v2.docx

论文_最终2_真的最终.docx

论文_最终最终版_别改了.docx

论文_最终最终版_真的别改了_last.docx

不仅每次要单独保存文件（还容易忘），甚至最后你已经分不清哪个是最新版，哪个删了重点改了什么东西。而且这种方法对于大型的项目来说。。。

🕰或许聪明的你想到了：

如果能像游戏里的存档点 。

保存一下是一个点，明天再改它又是一个点。

你死了（改错了），读档 就行。

这样就好了

🎯 是的，Git做的事情非常简单：

帮你保存每一次修改，并能随时回到任何一次修改。

没有玄学，就是这么接地气

因此我们可以将Git = 文件的时间机器

你可以把Git理解成一个"文件历史的照相机"：

你每改一次资料	Git就悄悄拍一张照片	你还可以在照片背面写上备注
第一天写了初稿	📷 咔！留了一版	这是我的初稿哦
第二天删了两段	📷 又拍一张	第三四段不太通顺，我删掉啦
第三天修改标题	📷 再拍一张	修改了标题
第四天添加了新内容	📷再拍一张	增加了"女主爆甩男主的情节"
第五天写完稿子	📷最后拍一张	完稿！

如果第四天你突然后悔：

"我觉得还是第一天写得好！"

没关系------

Git把每一张"版本照片"都替你保存着，你可以直接穿越回第一天。

是不是很像时间机器？

坐上去 → 调整日期 → 回到过去。

你只要知道：

改文件 → Git记一次
改错了 → Git带你回去
文件乱了 → Git给你旧版本
一切可撤回、可穿越、可找回

在这里总结一下，Git就是文件的照相机和备忘录，它记录着你文件的每一个版本，学了Git，你的文件不会再变成一团乱麻。

2、git的团队合作

如果你一个人写文档，Git能当备份器、时光机、后悔药。
但真正好玩的地方是------多人一起正确使用它，像开了外挂。

你想象一个场景：

三个人一起写同一个方案文档或者项目，如果不用Git会怎样？假设三个人一起在V2文档上作业：
情况一：

情况	很真实也很可怕
小王写着写着发你一个V3	"你改改，我再看"
你改完发给小李V4	小李又改回V2说V3不行
三份文件互相不一样	谁是最新版？谁改错了？没人知道
最后大家互相讨论，将v4作为最新版	大家同时将你文件里的v4更新为自己的最新版本

这种情况下，如果项目很多人，大家都要下载更新文件，并且如果有些人如果通知不到位，没有读到新信息，没有及时更新文件，并且进行了新作业，后续整理文件会不会很麻烦？

情况二：

情况	很真实也很可怕
小王写着写着发你一个V3	"你改改，我再看"
你改完发给小李V4	小李说这个V3不行，他自己已经写好了一个v3
小王和小李各一个V3，你有一个在小王基础上的v4	大家讨论得到，小李的V3确实很好，但是你的V4怎么办
改来改去对不上	最后三个人互相背锅 😩

这种情况下是大家没有沟通好的情况，但是发生了错误很难补救

情况三：
就算大家通过好，如果因为时间关系同时合作文件将非常地狱

| 情况 | 很真实也很可怕 |
| 时间关系，小王，小李，你同时在v2上作业 | 大家需要将自己各自的作业合并为一个v3的作业 |
| 大家艰难的合并且细对每一个文件 | 大家发现你和小王修改了同一个文件 |

你和小王要各保存自己的一部分	冲突文件要合并修改

这，就是现实世界的多人文件地狱。

而 Git 的出现，就是为了结束混乱。

🧩用Git，每个人都能同时做事

你可以把Git想象成一本大型练习册，
每个人都可以同时写自己的那一页，不会互相抢笔。

• 小王写第一章

• 你改目录

• 小李润色结尾

• 经理审稿只看版本差异

• Git 自动把大家写的部分合起来

就像几个人一起拼拼图，不用挤一个位置。

没有喊话、没有抢文件、没有版本混乱。

💡 你写你的，我写我的，最后Git帮大家拼好。

---

🔥 就算冲突了，Git也能帮你处理

有时候不可能完全不重叠------

你改了第三段，小李也改了第三段，那怎么办？

Git不会让你们打架，它会说：

"你们俩第3段写法不一样，我标出来，你们商量选哪个。"

它不会吞历史、不会乱合，也不会神秘地覆盖别人。

一切公开透明、可对比、可选择。

⚙ 它不是替你做裁判，而是把分歧摆在你面前让你决定。

非常文明，非常克制。

🏆团队用Git的三个大优点

优点	小白理解版解释
① 不会互相覆盖	因为git可以帮你自己找出冲突，不会出现"我改了你又给我删了"的问题
② 每个人可以同时独立工作	不抢文件，不等别人改完才轮到你
③ 所有修改有迹可循	谁写了啥一清二楚，避免甩锅

一句话总结：

你做你的，我做我的；最后Git把结果合成一个版本，历史都存着。

合作从"混乱"变成"有序"

3、git的项目团队协作的案例示例

三个人一起做《坦克大战》游戏项目

团队组成如下：

假设我们有一个三人小组🔥

角色	负责内容
小策（策划）	关卡设计、玩法文档
小美（美术）	坦克素材、地图贴图
小程（程序）	代码、功能实现

他们三个人像这样分工并协作：

① 小程创建项目仓库（Git仓库 = 游戏资料大箱子）

里面有资料夹，例如：

/code         代码
/assets       美术资源
/docs         策划文档

② 每个人在自己分支（即各自的文件夹）开发，不会互相干扰

他们不再围着一个文件夹抢，而是：

人	工作方式
小策写玩法文档 → 在 docs 分支
小美画坦克素材 → 在 art 分支
小程写炮弹发射代码 → 在 feature-fire 分支

💡 就好比三个人做菜：

• 小策写菜谱

• 小美切菜

• 小程烧锅做菜

各干各的，不争案板！

③三个人的大致开发流程是这样的

这个过程好像很简单，

当他们开发好一部分功能或内容时：

小策：文档完成 → 提交

小美：坦克素材打磨完 → 提交

小程：移动逻辑做完 → 提交

这种情况下似乎他们不会冲突、不会覆盖别人成果、每个人的贡献清清楚楚

接下来是更复杂的情况：

团队组成如下：

角色	人数	工作内容
美术	2人（小红 & 小蓝）	坦克、地图、爆炸特效
策划	1人（小白）	玩法规则、关卡文档
程序	3人（小程、小明、小涛）	坦克移动、AI、子弹系

为了避免抢文件，他们这样分工 👇

内容分工（各自独立）	Git 分支分法（各干一条线）
小红 → 画坦克皮肤	branch：brach-art
小蓝 → 做爆炸/地图素材	branch：brach-art
小白 → 调规则＋关卡文档	branch：brach-doc
小程 → 坦克系统、子弹系统等功能	branch：brach-code
小明 → AI系统等功能	branch：brach-code
小涛 → UI客户端功能	branch：brach-code

这种情况下可能会发生：

❌ 美术素材互相覆盖(两位美术同时修改了某一张图片）

❌ 程序写的功能撞车、不兼容（程序同时编写了同一模块的的代码）

就程序组来举例，比如小程、小明、小涛共同在brach-code开发游戏的代码项目，可以通过更新代码分支，拉取代码分支，添加代码分支，合并代码分支，切换代码分支等远程和本地的操作来完成自己的操作，在后面的章节中会详细降到

二、git仓库

1、本地仓库

🟦 什么是本地仓库？

当你从远程仓库克隆项目到电脑，或自己在本地 git init 创建一个项目时，就会生成一个 本地仓库

它就像一个：

📌 记录你所有修改历史的私人工作区

📌 不联网也能使用的开发空间

📌 试验、备份、版本管理的多功能实验室

用更贴近日常的小比喻👇

本地仓库 = 你自己桌面上的草稿本 ，

你可以改、可以写乱、可以翻以前的内容，谁也不会受影响。

等你满意后再把结果拿去"班级共享"------那就是 push 到远程。

---

🟦 本地仓库实际上包含三个区域

Git区域	理解	意义
工作区 Working Directory	你的草稿纸	文件实际编辑的地方
暂存区 Staging Area	草稿准备区、待提交篮子	想提交哪些改动先放进去
本地仓库 Local Repository	历史记录册	commit 后的永久版本存档

（这会这里小白可能难理解，后面实操了就知道了）

🟦本地仓库能做的事

① 随时 commit，保存每一次改动历史

前面我们说了git帮你保存每一次修改，并能随时回到任何一次修改

这个保存的操作就是commit操作，保存每一次改动历史

你不需要等到完美再提交，只要改动完成一小步就能保存：

✔ 新增功能 → commit

✔ 调整UI → commit

✔ 修bug → commit

每一次都是一张"时光快照"，想回滚随时回：

🌱 commit 就像给你的项目拍照片

💥 崩了？直接回到上一张照片，稳如老狗

② 可以无限分支，做实验安全无风险

分支是本地仓库最大自由度，这里多出来的分支，你可以看作从copy一份项目文件出来用于你的项目实验

示例：

main（稳定版） 
├─ try-ai-test ← 测AI敌人看是否好玩 
├─ ui-redesign ← 改坦克UI但怕翻车？ 
└─ crazy-physics ← 胡搞弹道轨迹也不怕

无论试验多疯：

🟡 不会影响主项目

🟡 不会影响队友

🟡 随时可合并 or 放弃

Git本地仓库让探索变得无负担。
你甚至可以尽情写错，因为随时回滚。

---

③ 本地仓库可以脱离网络使用（离线依然强大）

想象你坐高铁、去咖啡馆断网、飞机上开发：

你依然可以：

✔ 查看版本历史

✔ 建分支、写代码、写策划文档

✔ commit 多次保存快照

---

④ 推送前可以自查，不会破坏主项目

直接在云端写代码 = 风险很大

但 Git 不允许直接改远程，而是要求先在本地完成修改

你在本地打磨 → 测试通过 → push

这样保证提交到远程的永远是靠谱版本

队友看到的是你思考后的结果，不是半成品或错误文件

2、远程仓库

🧊 什么是远程仓库？

有什么方法能给存储每个版本的文件，并且让队友也能即时看见储每个版本的文件。是的，使用网络，并且创建一个远程仓库。
远程仓库 = 把你的代码/文件存在网上，而不是只放在你电脑里。

远程仓库 可以存储你每次提交的信息，并且队友也能通过远程仓库即时的看见你提交的信息
一般靠谱的队友会把自己本地仓库深思熟虑的工作成果上传到远程仓库！

这样做最重要的作用是：

📌 换电脑也能随时拿到项目文件

📌 队友能随时一起修改项目文件

📌 本地电脑坏了文件也不会受到任何损失

🧊远程仓库能做的事

① 本地代码推送到远程仓库（push）

你在本地写代码 → commit 保存 → 想共享给队友

这时你会执行 push：

push = 把你电脑里的成果上传到远程仓库，让别人也能看到。

适用场景：

✔ 完成一个功能

✔ 修完 bug

✔ 调整文档或素材

✔ 想与团队同步你的进度

---

② 从远程拉取最新代码到本地（pull）

当别人推送了更新，而你本地还是旧版本，你需要 pull：

pull = 把他人更新下载并合并到本地，让你保持最新进度。

适用场景：

✔ 队友开发完新模块

✔ 远程仓库有人修了冲突

✔ 有关键功能更新你要接着做

一句话总结 ①②：

我写完 → push 上传

别人更新 → pull 下载

③支持权限管理，决定谁能访问/修改

你可以设置：

• 公开还是私有？

• 谁能看？

• 谁能 push？

• 谁只能 read-only？

🧊为什么要有远程仓库？（它解决了哪些痛点）

这里对小白略抽象，可以快速看一遍尽量理解，实在看不懂没关系，你就当我水字数

① 做多人协作的「中心版本库」

没有远程仓库时，每个人都拿着一份项目副本，互相发压缩包、发U盘：

• 谁是最新版？

• 谁改的东西是对的？

• 同时改冲突怎么解决？

一团乱。

有了远程仓库之后：

• 约定：以远程仓库为"唯一权威版本"

• 大家从远程拉最新 → 在本地改 → 改完再推回远程

• 团队协作就变成这样一条闭环：

远程拿 → 本地改 → 传回远程 → 别人再拿最新

所以你可以这么形容：

远程仓库是这个项目的"大家都认的源头版本"。

---

② 做项目的「安全备份」

只放在本地会怎样？

• 电脑坏了、硬盘挂了、被偷了 → 项目没了

• 不小心删库 → 直接社会性死亡

而远程仓库在云端服务器上，通常会：

• 异地备份

• RAID 磁盘阵列

• 运维团队守着

你本地炸了，只要远程在，一切还在。

最多再 clone 一份下来继续干活。

---

③做多设备之间的「同步枢纽」

你可能不止一台设备：

• 公司电脑

• 家里电脑

• 笔记本 / iPad

有了远程仓库，流程变成：

• 在公司写到一半 → push

• 回家 pull 一下 → 立刻接着写

远程仓库就是你的"云端中转站"，
你在哪台电脑，就从云里把项目捞下来继续写。

---

④ 做「权限控制」和「审计记录」

远程仓库一般都在平台上托管，比如：

• GitHub、Gitee、GitLab.com、Bitbucket（公共云）

• 公司内网 GitLab / Gitea（自建，只有员工能访问）

这些平台会提供：

• 谁能访问这个仓库（公开 / 私有，成员列表）

• 谁能写（push）？谁只能看（pull）？

• 谁在什么时候提交了什么东西（提交记录 + 日志）

你可以把它理解成：

远程仓库 = 上锁的共享文件柜 + 自动记账本。

锁决定谁能动，记账本记录谁动过。

---

⑤ 驱动自动化：测试 / 部署 / 检查（进阶但很重要）

很多团队会约定：

"只要有人 push 到远程仓库，就自动触发一件事。"

比如：

• 自动跑一遍测试，看有没有写挂

• 自动构建、自动部署到测试环境 / 线上

• 自动做代码检查（lint、格式化）

也就是说：远程仓库经常是整个自动化流水线的触发点 ，

是"CI/CD 的起点"，这一点后续进阶章节里会详细提到。

🧊 常见的 Git 远程仓库平台有哪些？

平台	类别	小白理解
GitHub	全球最大开源平台	有点像"代码界的淘宝城"，啥都有
Gitee（码云）	国内平台，速度快	类似国产 GitHub，访问更顺畅
GitLab	企业常用，可私有部署	就像公司自建仓库，只员工能进
Bitbucket	程序团队多人协作多	小团队免费私库多，适合开发协作

三、git操作详解

现在大家理解了git的主要作用，本地仓库，远程仓库，下面我通过一个简单的项目实例来讲解一下git的详细操作步骤，还是坦克大战六人组

团队组成如下：

角色	人数	工作内容
美术	2人（小红 & 小蓝）	坦克、地图、爆炸特效
策划	1人（小白）	玩法规则、关卡文档
程序	3人（小程、小明、小涛）	坦克移动、AI、子弹系

为了避免抢文件，他们这样分工 👇

内容分工（各自独立）	Git 分支分法（各干一条线）
小红 → 画坦克皮肤	branch：brach-art
小蓝 → 做爆炸/地图素材	branch：brach-art
小白 → 调规则＋关卡文档	branch：brach-doc
小程 → 坦克系统、子弹系统等功能	branch：brach-code
小明 → AI系统等功能	branch：brach-code
小涛 → UI客户端功能	branch：brach-code

1、git基础操作

①git init操作

程序员小程在自己的文件夹里创建了一个项目文件，并且项目文件是这样的：

/code         代码
/assets       美术资源
/docs         策划文档

这里仅仅是一个文件，还不是本地仓库，但是他打开终端 / Git Bash，选一个这个项目的文件夹,并输入：

git init（让文件夹变成Git仓库）

这时候小程就有属于自己的本地仓库了

②git add操作和git commit

创好本地仓库后，再来回顾一下本地仓库的三层区域：

区域	Git 名字	小白理解
工作区	Working Directory	你实际在改的文件夹
暂存区	Staging Area	"待提交篮子"，先挑准备好的改动放进去
本地仓库	Local Repository	历史相册，真正永久记录改动的地方

git add //把改动从"工作区"放进"暂存区"，为下一次 commit 做准备
git commit //把暂存区的内容打包，存进"本地仓库"变成一个历史版本

一张简化流程就是：

你改文件 → git add → git commit 工作区 暂存区 本地仓库

git add 命令示例：

git add main.py          # 把 main.py 的修改放入暂存区
git add assets/          # 把 assets 目录下所有变化加入暂存区
git add .                # 把当前目录所有变更都加入暂存区

git commit命令示例：

git commit -m "实现坦克移动和开火功能"
git commit -m "更新美术资源：红色坦克皮肤"
git commit -m "补充文档：第一关敌人刷怪规则"

一个 commit 会包含：

• 当前暂存区所有文件的版本
• 提交人信息（谁）
• 提交时间（什么时候）
• 提交说明（做了什么）

以后你可以回到这个 commit：

• 看那时候项目长什么样
• 对比当时和现在的差别出了问题
• 可以回滚/对比排查

暂存区的作用：可以先把"确定的部分"放进暂存区，不确定的先留着

比如你还在试验一半：

• /code/move.py 已经改完了，确定没问题 ✅

• /code/ai.py 还在乱试，根本写不完 ❌

你可以：

git add code/move.py # 这部分先纳入提交计划 
# ai.py 先别管 
git commit -m "完成坦克移动重构" |
# ai.py 继续改，改爽再说

add = 我对这些改动"有信心了，准备提交"

工作区未 add 的内容 = "还在玩，还没想好，先别进历史"。

回到小程那里：

git add . #把art，code，doc文件放入缓存区
git commit  -m "完成art，code，doc初始文件构造" #这样小程就把自己的初始缓存项目放入缓冲区了

小程通过上述两部操作，完成了一次自己项目对本地仓库的提交，我们就可以通过历史记录来查看这次操作了

③git log操作

git log 是什么？

一句话：

git log 用来查看提交历史（commit 记录）

它就像时间轴，你能看到项目从过去到现在经历了什么改动。

执行：

git log

你就可以看见一下记录

commit 45bb3c4f4d...
Author: 小程 <cheng@tank.com>
Date:   2024-01-22 16:41

    "完成art，code，doc初始文件构造"

④git remote add origin 操作（小白可跳过）

小程本地创建了一个 Git 仓库，并且完成了第一次提交后，他想要把这个本地仓库与远程仓库（比如 GitHub、GitLab 或 Gitee）关联起来。其通过执行 git remote add origin 命令，就可以将本地仓库与远程仓库绑定，使得后续能够方便地推送（push）和拉取（pull）代码。

命令格式：

git remote add origin <远程仓库地址>

解释：

• git remote 是 Git 用来管理远程仓库的命令。

• add 是用来添加一个新的远程仓库。

• origin 是远程仓库的名称，通常使用 origin 作为默认名称，你也可以使用其他名字，但 origin 是惯例。

• <远程仓库地址> 是你在 GitHub、GitLab 或 Gitee 等平台创建的仓库地址，通常是一个 URL。例如：https://github.com/your-user/your-repo.git

示例：

git remote add origin https://github.com/your-team/tank-battle-game.git

通过这个命令，本地仓库与远程仓库就建立了关联。此后，所有的 git push 和 git pull 操作都会默认对这个远程仓库进行。

⑤git push 操作

连接远程仓库后, 小程想将本地仓库的内容（提交）上传到远程仓库，这时候就要用到git push

git push 是将本地仓库的更改（提交）上传到远程仓库的命令。通常在完成本地开发后，想要与团队共享代码，或者备份代码到远程仓库时，会使用 git push。

命令格式：

git push <远程仓库名> <本地分支名>:<远程分支名>

<远程仓库名>：通常是 origin，表示你之前通过 git remote add origin 命令关联的远程仓库。

<本地分支名>：是你当前工作的本地分支名，例如 main 或 master。

<远程分支名>：远程仓库中你希望将本地分支推送到的分支名，通常和本地分支同名。

如果是第一次推送，并且本地和远程仓库的分支还没有关联，可以用：

git push -u origin main

其中：

• -u 表示设置 upstream 关联，也就是说以后就可以直接用 git push 不需要再指定远程仓库和分支。

⑥git clone操作

📍仓库项目初始文件已建在 GitHub / GitLab / Gitee

每个人打开终端 / Git Bash，选一个放项目的文件夹，：

git clone <远程仓库地址>
 # 比如： # git clone https://github.com/your-team/tank-battle-game.git

执行完后，他们的电脑里就多了一个文件夹：

tank-battle-game/ 
├── README.md 
├── （之后会有）code/ 
├── （之后会有）assets/ 
└── （之后会有）docs/

这个文件夹，就是各自的本地仓库，接下来所有改动都在这里发生。

这一步叫：clone（克隆）

clone可以看作：
把远程仓库完整"拷贝一份"到自己电脑上，变成本地仓库。

但这和"下载 ZIP 压缩包"相比，有两个本质区别：

• zip 只是一堆文件，没 Git 历史、不能 commit、不能 push
• clone 下来的，是一个带完整 Git 历史、可以继续版本管理的仓库

2、git分支操作

后续会继续更新，30号之前完成，请大家点赞收藏。。。。