5分钟搞懂git/github是什么，怎么用，0基础教程

TUTORIAL · 零基础

2026.07

看着 GitHub 发怵？

从零开始 学会 Git

把代码搬上 GitHub

Git & GitHub · 新手零基础教程

开源先驱 · 零基础教程

GitGitHub

今天不聊项目，换个角度

专门为新朋友，写一篇真正的「零基础」Git 教程

我们一直在分享 GitHub 上的优秀项目，希望能帮大家打开一扇通往优秀代码世界的大门。但我也注意到，其实还有很多新接触的朋友，看着 GitHub 上密密麻麻的英文和术语，心里既好奇又发怵，连第一步都还没迈出去。

所以，今天我们决定换个角度，不聊项目了，专门为新朋友准备一篇真正的「零基础」教程。这篇不会一上来就扔给你一堆看不懂的命令，而是从一个完全初学者的视角，把 Git 和 GitHub 的来龙去脉、核心概念讲得透透的。

希望能帮到每一个想把自己的代码放到 GitHub 上的朋友。

01

PART

为什么我们需要 Git？

WHY GIT

先别急着敲命令。我们先搞清楚 Git 到底解决了什么问题。一旦你理解了它存在的意义，后面的东西就好懂了。

手动给文件命名的噩梦

想象一下你在写一篇代码。写完初稿，保存为 essay_v1.docx。然后改了一些内容，另存为 essay_v2.docx。接着大胆改了一通，保存为 essay_final.docx。

然后又发现一个小错误，改完保存为 essay_final_REAL.docx。这时你朋友"二狗"又改了几处，发回来一个 essay_final_REAL_edited_by_ergou.docx。

到了这一步，你的文件夹里全是文件，脑子里全是问号：哪个才是最新版本？v2 和最终版之间到底改了啥？二狗到底编辑了什么？如果改坏了，能回到之前的版本吗？脑子是不是已经开始乱了。

现在再想象一下，如果现在不是一个文件，而是一个有几千个文件的代码库，而且有 10 个人同时在改，那岂不是乱成一团麻？这就是 Git 要解决的问题。

Git 出现之前人们怎么干活？

在版本控制工具出现之前，程序员们做的事情跟咱们差不多：把文件存成 project_v1、project_v2、project_final、project_final_final……

有时候他们通过邮件互相发送代码文件；有时候团队用共享文件夹，几个人同时编辑同一个文件。问题在哪？一个人可能不小心覆盖掉另一个人的工作，等发现的时候已经晚了。项目越来越大、人越来越多之后，局面很快就失控了，管理起来简直是噩梦。

打个生活化的比方

把 Git 想象成你游戏的存档系统。每次你创建一个检查点，Git 就会记下那一刻你的项目长什么样。之后如果出了什么问题，你可以随时回到任何一个检查点。

它还会记录谁在什么时候改了什么，这在多人协作时特别有用。想尝试一个新功能但又不想动主代码？Git 可以让你创建一个独立副本，随便折腾。说到底，Git 就是个追踪变更、给代码做检查点的工具。

02

PART

Git 到底是什么

WHAT IS GIT

Git 是一个版本控制系统 —— 帮你在本地随时间的变化追踪文件

Git 是一个版本控制系统。听着挺高大上，说白了就是：Git 是一个能帮你追踪文件随时间变化的工具。

很多初学者不知道的一点是：Git 完全在你自己的电脑上运行。不需要联网，也不需要 GitHub。只要你安装了 Git，就能直接开始用。

当你在一个项目里使用 Git 时，它会盯着你的项目文件夹。每次你让它创建检查点，它就会记录那一刻所有文件的状态。这些信息都存储在你项目里的一个隐藏文件夹 .git 中。

为什么开发者不管什么都用 Git？

犯错了？可以回到旧版本

想尝试风险操作？搞砸了可以回滚

跟别人合作？不会互相覆盖

想知道改了啥？完整记录每次变更和修改人

Git 的职责其实很简单：追踪变更、保存检查点、出问题时方便恢复。

03

PART

GitHub 是什么（以及它为什么≠Git）

GITHUB ≠ GIT

这大概是初学者最困惑的地方，我们一次说清楚：Git 和 GitHub 不是一回事。

Git 是你电脑上跑的工具，负责追踪项目的变更。

GitHub 是一个网站，把你的 Git 项目存到线上，方便备份、分享和协作。

打个比方：你用 Word 写文档、做编辑，Google Drive 只是你在线存储和分享文档的地方。Git 和 GitHub 的关系也一样——你用 Git 追踪变更，用 GitHub 把这些变更存到网上。

实际上，你可以用 Git 很多年而从不碰 GitHub，本地一切照常工作，只是没有在线备份和协作功能而已。除了 GitHub，还有 GitLab、Bitbucket 等同类网站。GitHub 只是知名度最高的一个。

04

PART

核心概念详解

CORE CONCEPTS

大部分 Git 教程直接扔一堆术语，但对新手来说，看起来就像是读天书一样。我们来破一下——下面 17 个核心概念，每个都用「是什么 / 打个比方 / 举个例子」讲清楚。

仓库（Repository / Repo）

是什么：一个被 Git 追踪的文件夹。

打个比方：项目文件夹里藏了一本日记（叫 .git 文件夹），记录每一次改动。

举例：python-calculator 文件夹运行 git init 后就变成仓库。

提交（Commit）

是什么：项目的一个已保存检查点。

打个比方：游戏里保存进度，以后可以读档回来。

举例：写完一个计算器函数，创建一个提交，版本就安全存进历史记录。

提交信息（Commit Message）

是什么：描述这次提交改了什么的一段简短说明。

打个比方：给存档起个名字，而不是全叫「存档 1」。

举例：Add multiply function to calculator（给计算器添加乘法函数）。

工作目录（Working Directory）

是什么：项目文件夹当前的状态。

打个比方：你正在工作的桌面，文件被编辑、移动、修改，但还没正式存到 Git 里。

暂存区（Staging Area）

是什么：临时区域，让你挑选哪些改动进入下一次提交。

打个比方：桌面＝工作目录，纸箱＝暂存区，提交＝创建提交。

为啥要它：改了 5 个文件只想先保存 3 个？暂存区让你精挑细选。

分支（Branch）

是什么：项目的一个独立版本，可以在里面独立工作。

打个比方：复印一本书，在复印件里写实验章节，不碰原书。

举例：加历史记录功能，与其冒险改主代码，不如开个新分支。

主分支（Main Branch）

是什么：项目的主干分支，相当于官方版本。

注意：老教程可能叫 master；现代 Git 项目通常用 main。

合并（Merge）

是什么：把一个分支的改动合并到另一个分支。

打个比方：把复印件里的实验章节加回到原书里。

远程仓库（Remote Repository）

是什么：项目在线上的一份副本。

打个比方：笔记本上有一份，云端（GitHub）还有一份，可保持同步。

Origin

是什么：Git 给远程仓库取的默认别名。

打个比方：手机联系人，不用每次输入一长串 GitHub 地址，Git 直接用 origin。

克隆（Clone）

是什么：从 GitHub 下载一个仓库到你的电脑。

打个比方：下载整个游戏，而不只是存档文件。

你会得到：所有项目文件、每一次提交、完整历史记录。

拉取（Pull）

是什么：从 GitHub 下载最新改动到你的电脑。

打个比方：点同步按钮。队友上传了新代码，git pull 把更新拉到本地。

推送（Push）

是什么：把你本地的提交上传到 GitHub。

打个比方：和 pull 相反，本地完成工作后发送到线上仓库。

复刻（Fork）

是什么：在 GitHub 上创建一份别人仓库的副本。

打个比方：复制一份别人项目到自己名下随便折腾，不影响原项目，开源社区常见。

拉取请求（Pull Request / PR）

是什么：请求别人审阅并合并你的改动。

打个比方：「我做了些改进，你们看看，觉得好就合并到主项目里。」

冲突（Conflict）

是什么：Git 发现同一段代码有两个不同版本，不知该留哪个。

打个比方：你和朋友同时改了同一句话但改成不同样子，Git 让你来定。

HEAD

是什么：一个指针，告诉 Git 你当前在哪个位置。

打个比方：Git 时间线上一个巨大的「你在这里」标记，切换分支时跟着动。

05

PART

完整的新手上手流程

STEP BY STEP

咱们从零开始。准备工作：安装 Git（https://git-scm.com/downloads）、注册 GitHub 账号（https://github.com），打开终端。

STEP 01

创建项目文件夹

...bash

mkdir python-calculator

cd python-calculator

STEP 02

初始化 Git

...bash

git init

这相当于告诉 Git「开始追踪这个文件夹」。Git 在里面创建了一个隐藏的 .git 文件夹，现在你的文件夹变成了一个仓库。

STEP 03

创建 Python 文件

创建 calculator.py，写点代码——

...python

def add(a, b):

　　return a + b

print(add(2, 3))

STEP 04

看看 Git 看到了什么

...bash

git status

Git 会告诉你：「我看到一个新文件 calculator.py，但我还没开始追踪它。它是未追踪的。」

STEP 05

暂存文件

...bash

git add calculator.py

# 或一次性添加所有文件：

git add .

STEP 06

提交

...bash

git commit -m "Add basic add function"

你保存了第一个检查点！-m 参数让你写一条信息描述这次提交。

STEP 07

在 GitHub 上创建仓库

1. 打开 github.com → 点击 + 图标 → New repository

2. 命名为 python-calculator，设为 Public

3. 不要勾选 Initialize with README（本地已有代码）

4. 点击 Create repository，会显示类似 https://github.com/你的用户名/python-calculator.git

STEP 08

连接本地仓库到 GitHub

...bash

git remote add origin https://github.com/你的用户名/python-calculator.git

STEP 09

推送代码

...bash

git push -u origin main

这会把提交发送到 GitHub。-u origin main 设置了默认关联，以后只输 git push 就行。刷新页面——代码出现了！

STEP 10

修改代码并再次推送

给 calculator.py 加一个减法函数——

...python

def subtract(a, b):

　　return a - b

...bash

git add .

git commit -m "Add subtract function"

git push

完成。GitHub 现在显示更新后的代码了。

06

PART

最常用的 Git 命令

COMMON COMMANDS

现在你理解了基本概念，来看看实际每天会用到的命令。Git 不需要全部背下来——大多数开发者翻来覆去用的就是同一小套。

git init —— 把文件夹变成仓库

作用：把当前文件夹变成 Git 仓库。通常是开始新项目时的一次性操作。新手常错：在错误的文件夹里运行，一定先 cd my-project 再 init。

...bash

git init

git status —— Git 的「现在什么情况？」按钮

作用：显示当前仓库状态——哪些文件被改了、已暂存、还没追踪。随时随地都能跑，提交前、推送前、搞不清状况时都跑一下。

git add . —— 暂存所有改动

作用：暂存当前目录下所有被改动的文件。. 表示「全部加进来」。新手常错：不小心暂存了 API 密钥、密码文件，提交前一定先 git status 检查。

git commit -m “信息” —— 创建检查点

作用：创建一个新的检查点。好的提交信息能让未来的你少掉头发——

❌ fix / stuff / update / changes

✅ Fix division by zero crash / Add login validation

git log —— 翻看历史

作用：显示所有提交的历史记录（提交 ID、信息、作者、日期）。小提示：按 q 退出日志界面。

分支相关：branch / checkout / switch / merge

...bash

git branch　　　　　　　# 列出所有分支

git branch feature-history　# 创建分支

git checkout feature-history # 切换分支

git switch main　　　　　 # 现代切换方式

git switch -c new-feature　# 创建并切换

git merge feature-history　# 合并到当前分支

git switch 是新版 Git 推荐的分支操作方式，比 checkout 更清晰。

clone / pull / push —— 和 GitHub 打交道

...bash

git clone https://github.com/user/repo.git　# 下载完整仓库

git pull　　　　　　　　　　　　　　　　# 拉取最新改动

git push　　　　　　　　　　　　　　　　# 上传本地提交

基础 Git 工作流

...bash

git status

git add .

git commit -m "Describe what changed"

git push

这就是你在成千上万次构建项目里会反复执行的核心流程。只有已提交的改动才能被推送——直接 git push 没用的。

07

PART

分支，讲清楚

BRANCHES

分支通常是初学者「好吧，Git 我懂了……等等，现在又懵了」的地方，这个概念其实很简单，把分支想象成你代码的独立游乐场。

为什么要有分支？

你做了一个计算器应用，一切完美运行，代码在 main 上。现在想加保存历史的功能。直接在 main 上改风险很大——万一功能要开发一周、不小心搞坏东西、代码只写了一半不能用，主项目就一直是坏的。与其直接改 main，不如开个新分支，随便实验、搞砸、重写都不碰稳定版本。

团队实际怎么用分支

main 是项目的官方版本，应该始终能工作、随时可发布，开发者一般不直接在它上面改。每个新功能都有自己的分支，例如 feature-login、bugfix-crash、hotfix-payment。开发完、测试好、才合并回 main，开发期间主分支保持稳定。

功能完成后怎么办？

一旦功能正常：① 分支被审阅 → ② 代码被测试 → ③ 分支被合并到 main → ④ 功能正式成为项目的一部分。

合并冲突

大多数初学者听到「合并冲突」以为出了天大的事，其实通常没那么严重。它发生在两个分支改了同一文件的同一处，Git 不知道该留哪个。比如你改了第 42 行，队友也改了第 42 行，Git 有同一行的两个版本，不会瞎猜，而是让你来定。

冲突长什么样？

...git conflict

<<<<<<< HEAD

result = a + b

=======

result = a + b + carry

>>>>>>> feature-carry

解决方式：直接编辑文件，删掉冲突标记（<<<<<<< HEAD 等），保留你想要的版本。合并冲突不是 Git 坏了，而是它不确定哪个代码是对的，所以拒绝替你做决定——第一次看到吓人，但通常远没名字听起来可怕。

08

PART

团队怎么用 GitHub 协作

TEAMWORK

Git 真正的威力体现在多人协作时。下面是典型团队的工作流（9 步）：

1

有人创建仓库（中心副本，所有人从这里出发）。

2

每个人克隆仓库到本地：git clone。

3

为自己的工作创建分支（不直接在 main 上改）。

4

修改代码并提交：git add . → git commit。

5

推送分支到 GitHub：git push。

6

开一个 Pull Request（PR），请人审阅。

7

代码审查（批准 / 提问题 / 要求修改）。

8

合并 PR，功能正式集成到项目。

9

每个人更新本地副本：git pull。

整个工作流一图看懂

...workflow

创建仓库

　　↓

克隆

　　↓

创建分支 → 写代码 → 提交 → 推送

　　↓

开 Pull Request → 代码审查 → 合并

　　↓

git pull

这就是开源项目、创业公司、大科技公司都在用的基本工作流。核心理念一样：分支开发、审查代码、合并批准、通过 Git 和 GitHub 保持同步。

09

PART

初学者的常见问题

FAQ

❓ 有了 GitHub 为什么还要 Git？

因为干的完全是两码事。Git 追踪变更、创建提交、管理分支、保存历史；GitHub 只是把那些历史存到线上。没有 Git，GitHub 就是个文件托管网站，没有提交、分支、版本历史。

❓ 为什么不能直接上传 ZIP 文件？

ZIP 只包含当前版本，不会告诉你改了什么、什么时候、谁改的、怎么回老版本。Git 仓库包含所有这些信息——ZIP 是一张照片，Git 是整部电影。

❓ origin 是什么？

就是远程仓库地址的别名，省得每次输一长串。你甚至可以取别的名字——比如 git remote add banana ...，大家用 origin 只是约定俗成。

❓ HEAD 是什么？

Git 记录你当前所在位置的方式。把历史想成时间线，HEAD 就是「你在这里」标记，切换分支、跳到别的提交它都跟着动。

❓ 为什么提交这么重要？

因为提交是你的安全网。删了函数、引入 bug、搞崩项目——只要最近提交过，恢复通常很简单。有经验的开发者会频繁提交。

❓ 删了 GitHub 仓库会怎样？

情况一：本地还有一份，重新建一个推上去就行。情况二：GitHub 是唯一一份，那就麻烦了。所以开发者会定期提交、推送、留多份备份。

❓ fork 是什么？

别人仓库的一份你的个人副本。Fork → 修改 → 推送 → 开 PR，项目所有者决定是否合并。大量开源软件就是这么开发的。

❓ 为什么会有合并冲突？

因为 Git 不会读心术。同一段代码两个版本，该留哪个它不知道——停下来让你决定。多数情况下你只是编辑一个文本文件，选正确的代码而已。

10

PART

新手常犯的错误

COMMON MISTAKES

！踩坑提示 🕳

1. 不小心提交了 API 密钥和敏感信息。 机器人会持续扫描公开仓库找密钥，几分钟内就可能被滥用。正确做法：密钥存环境变量、用 .env、把它加进 .gitignore。

2. 提交不够频繁。几天才提交一次，Git 更像备份而非版本控制。尽量在完成有意义的工作单元后就提交——小提交更容易恢复、调试、撤销。

3. 直接在 main 上工作。这对团队项目是个坏习惯——bug 可能立即被引入、半成品出现在生产环境。安全做法：开分支 → 开发 → 测试 → 合并回 main。

4. 忽略 .gitignore。没有它，你会提交 venv/、__pycache__/、node_modules/ 等，让仓库臃肿、泄露信息。配置它应该是最早做的事之一。

5. 不理解为啥就复制粘贴命令。这是最危险的习惯。git push --force 会覆盖历史，git reset --hard 会永久删除未提交改动。不确定就先跑 git status。

11

PART

理解 .gitignore

GITIGNORE

.gitignore 是你应该在几乎所有项目里最早添加的文件之一。它告诉 Git：忽略这些文件和文件夹，别追踪、别提交。

常见应该忽略的内容

虚拟环境：venv/、env/（可重建，含成千上万文件）

Python 缓存：__pycache__/、*.pyc、*.pyo

密钥文件：.env、config.json、secrets.json（绝不能提交）

系统垃圾：.DS_Store、Thumbs.db

编辑器设置：.vscode/、.idea/（个人化，不需分享）

一个基础的 Python .gitignore

....gitignore

# 虚拟环境

venv/

env/

.env

# Python 缓存

__pycache__/

*.pyc

# IDE 设置

.vscode/

# 操作系统文件

.DS_Store

一个小坑：.gitignore 只影响还没被追踪的文件。如果已提交过，再加进去不会让它消失，需要手动停止追踪。省事儿的办法：GitHub 创建仓库时可选现成模板（Python 直接选 Python 即可）。

12

PART

Git 速查表

CHEAT SHEET

...bash · git cheat sheet

# 设置

git init　　　　　　　　　# 开始追踪当前文件夹

git clone <地址>　　　　　# 从 GitHub 下载仓库

# 状态 & 历史

git status　　　　　　　　# 查看哪些文件变了

git log　　　　　　　　　# 查看所有提交

git log --oneline　　　　# 简洁版提交历史

# 暂存 & 提交

git add .　　　　　　　　# 暂存所有改动

git add <文件名>　　　　# 暂存指定文件

git commit -m "信息"　　# 保存检查点

# 远程

git remote add origin <地址>　# 连接 GitHub

git push -u origin main　# 第一次推送

git push　　　　　　　　　# 之后的推送

git pull　　　　　　　　　# 下载最新改动

# 分支

git branch　　　　　　　　# 列出所有分支

git switch -c <分支名>　# 创建 + 切换新分支

git switch <分支名>　　# 切换分支

git merge <分支名>　　# 合并分支到当前分支

# 撤销（小心使用）

git restore <文件名>　　　# 丢弃未提交的改动

git restore --staged <文件名>　# 取消暂存文件

///

LAST

结语

CLOSING

Git 是你代码的一条时间线，GitHub 只是它的云存储

Git 不神秘。一旦你理解了它真正在做什么，就会发现它并不复杂。Git 是你代码的一条时间线，每次提交都是时间线上的一个点。你可以往回走、分叉出去、把时间线合并、把时间线分享给别人。

GitHub 只是那条时间线的云存储，让你的作品可见、可分享、有备份。

你一定会感到困惑，这很正常。每个开发者，包括工作很多年的，也许都刚刚搜过「怎么撤销上次 git 提交」。Git 就是那种你学会了 10% ，然后用那 10% 应付 90% 工作的工具。

如果这篇教程对你有帮助，请记得一键三连，让更多的朋友也看到。

我是开源先驱，平时爱在 GitHub 上淘那些被低估的宝藏工具，把好用的分享给你。如果你也在用 Git 或打算上手，这篇零基础教程值得先翻一遍。