Git 零基础入门篇：从底层逻辑到实战避坑#

1.1 版本控制的本质#

在没有版本控制系统时，我们通常会遇到以下三大痛点：

• 版本混乱：文件夹里充斥着 代码_v1、代码_v2_最终版、代码_v3_绝对不改版，完全记不清每个版本改了什么。
• 误删无法回退：不小心删除了核心代码，又按了保存，只能对着屏幕崩溃。
• 多人协作打架：团队成员同时修改同一个文件，互相覆盖对方的工作成果。

版本控制系统就是为了彻底解决这些问题而诞生的，它就像是代码的“时光机”与“协调员”。

1.2 集中式 vs 分布式：Git 的优势在哪#

传统的版本控制系统（如 SVN）是集中式的，所有的版本历史都存放在中央服务器上。一旦断网，开发者就无法提交代码或查看历史；如果中央服务器宕机，整个项目的历史记录就可能丢失。

而 Git 是分布式的，每个开发者的电脑上都有一个完整的本地仓库副本，包含了所有的提交历史。

Git 的核心优势

• 离线可用：绝大多数操作（提交、查看历史、分支切换）都在本地完成，无需网络。
• 极致安全：即使中央服务器（如 GitHub）宕机，任何一个开发者的本地仓库都能用来恢复完整项目。
• 分支极速：Git 的分支非常轻量级，创建和切换分支几乎是瞬间完成的。

1.3 学习 Git 的现实价值#

• 求职必备技能：如今几乎所有的互联网公司都在使用 Git，它是写在招聘要求里的基操。
• 开源项目入场券：无论是 GitHub 还是 Gitee，全球绝大多数开源项目都依赖 Git 进行协作。
• 团队协作通用语言：掌握 Git 意味着你能与团队顺畅对接，而不会成为那个“经常覆盖别人代码”的定时炸弹。

2.1 三区模型：每一步发生了什么#

Git 的本地工作流主要围绕三个核心区域展开：

1. 工作区（Working Directory）：你平时写代码、编辑文件的那个普通文件夹。
2. 暂存区（Staging Area/Index）：一个虚拟的缓冲地带，用于存放你“打算提交”的文件列表。
3. 本地仓库（Local Repository）：真正安全存放所有版本历史的地方。

工作流转

写代码（工作区） $\xrightarrow{\text{git add}}$ 放入暂存区 $\xrightarrow{\text{git commit}}$ 永久存入本地仓库。

2.2 文件的 4 种状态#

在 Git 的视界中，你的文件始终处于以下 4 种状态之一：

• 未跟踪（Untracked）：新创建的文件，Git 还没开始管理它。
• 已修改（Modified）：Git 正在管理的文件被你修改了，但还没放到暂存区。
• 已暂存（Staged）：修改后的文件被放入了暂存区，准备下次提交。
• 已提交（Committed）：文件已经被安全地保存在了本地仓库中。

2.3 快照而非差异：为什么又快又安全#

很多版本控制系统存储的是“每次文件改动了哪些行（差异）”。而 Git 的核心理念是快照（Snapshot）。

每次提交时，Git 会对所有文件当前的状态拍一张“照片”，并计算出一个独一无二的 SHA-1 哈希值（一串 40 位的字符）。如果文件没变化，Git 就只存一个指向之前快照的链接。这种机制让 Git 的分支和回退操作快如闪电。

2.4 远程仓库的定位#

新手常有的一个误区：“Git 就是 GitHub”。

概念澄清

Git 是一款本地运行的版本控制软件。 GitHub / Gitee / GitLab 是提供 Git 仓库托管服务的在线平台。 它们的关系就像是“本地视频播放器”与“B站/优酷”的关系。

3.1 三大系统安装步骤#

• Windows：访问 Git 官网，下载 .exe 安装包，一路“下一步”即可。
• macOS：推荐使用 Homebrew 安装。

  1
  brew install git
  

• Linux (Ubuntu/Debian)：

  1
  sudo apt update
  2
  sudo apt install git
  

3.2 首次必做配置：用户名与邮箱#

安装完成后，第一件事就是告诉 Git 你是谁。这个信息会附带在你的每一次提交记录中。

1
git config --global user.name "你的英文名或昵称"
2
git config --global user.email "你的常用邮箱@example.com"

--global 参数表示这台电脑上的所有 Git 仓库都会默认使用这个配置。

3.3 SSH 密钥配置（免密登录）#

为了避免每次向 GitHub/Gitee 推送代码时都要输入密码，我们需要配置 SSH 密钥。

1
# 一路回车即可，无需设置额外密码
2
ssh-keygen -t rsa -C "你的常用邮箱@example.com"
3

4
# 查看公钥内容（以 Windows/Linux 为例）
5
cat ~/.ssh/id_rsa.pub

将打印出的一长串公钥内容复制，前往 GitHub 的 Settings -> SSH and GPG keys -> New SSH key 中粘贴保存。

3.4 验证安装与配置#

1
# 检查版本
2
git --version
3

4
# 查看所有配置
5
git config --list

4.1 初始化仓库 (git init)#

要让 Git 开始管理代码，必须先初始化。

场景 1：全新项目从零开始 创建一个空文件夹，进入后执行：

1
mkdir my-project
2
cd my-project
3
git init

场景 2：已有项目纳入版本管理 直接进入已有代码的文件夹，执行 git init 即可。Git 会在当前目录下生成一个隐藏的 .git 文件夹，这是 Git 的“核心引擎”，千万不要手动修改里面的内容。

4.2 查看状态与差异#

1
git status

1
# 查看工作区与暂存区的差异
2
git diff
3

4
# 查看已暂存的内容与上次提交的差异
5
git diff --staged

4.3 暂存与提交#

1
# 暂存单个文件
2
git add index.html
3

4
# 暂存多个文件
5
git add index.html style.css
6

7
# 暂存当前目录下所有修改和新增的文件（高频使用）
8
git add .

1
git commit -m "feat: 添加用户登录页面的前端布局"

4.4 查看提交历史#

1
# 基础用法
2
git log
3

4
# 高频参数：单行精简显示
5
git log --oneline
6

7
# 高频参数：图形化展示分支演进
8
git log --graph --oneline

4.5 基础撤销操作#

写错代码了，或者不小心 add 了不该提交的文件怎么办？

1
# 撤销工作区的修改（让文件回到上次提交时的状态，极其危险，谨慎使用！）
2
git restore <文件名>
3

4
# 把文件从暂存区撤回工作区（取消暂存，不会丢失代码）
5
git restore --staged <文件名>

5.1 远程仓库创建#

1. 登录 GitHub，点击右上角 + -> New repository。
2. 填写仓库名（如 my-project）。
3. 不要勾选初始化 README 或 .gitignore（保持仓库完全为空）。
4. 点击 Create repository。

5.2 本地关联远程仓库#

在本地终端中，将本地仓库与刚才创建的 GitHub 远程仓库绑定：

1
# origin 是远程仓库的默认代号，后面跟的是你的仓库地址
2
git remote add origin git@github.com:你的用户名/my-project.git

5.3 首次推送代码#

1
git push -u origin main

-u 参数的作用：将本地的 main 分支与远程的 origin/main 分支绑定。以后再推送时，只需要敲 git push 即可。

5.4 克隆与拉取#

1
git clone git@github.com:vuejs/vue.git

1
git pull

坑 1：没有 .gitignore 文件#

很多新手会把编译生成的 dist 目录、node_modules 依赖包、甚至 IDE 的配置（如 .vscode）全都提交上去。这不仅让仓库变得巨大，还会导致严重的冲突。 对策：在项目根目录创建 .gitignore 文件，写明需要忽略的路径。

1
node_modules/
2
dist/
3
.env
4
.DS_Store

坑 2：直接提交密码、密钥等敏感信息#

一旦你把数据库密码、云服务器密钥提交到了公开的 GitHub 仓库，几分钟内就会有爬虫扫描到并利用，造成不可挽回的损失。 对策：敏感信息必须放在环境变量文件（如 .env）中，并将该文件加入 .gitignore。

坑 3：在错误的目录执行 git init#

如果在你的电脑用户根目录（如 C:\Users\张三）不小心敲了 git init，你的整个电脑文档都会被 Git 追踪，导致系统卡顿。 对策：确保进入了具体的项目文件夹再执行 git init。如果不小心建错了，找到并删除那个多出来的隐藏 .git 文件夹即可。

坑 4：提交信息太随意#

满屏的 update、fix、123，等项目出了 bug 需要回溯时，你根本不知道哪次提交改了什么。 对策：严格遵守 [动词]: [具体修改了什么] 的格式。

坑 5：盲目强制推送 (git push -f)#

新手遇到推送报错，一怒之下上网搜到了 git push -f，结果把团队其他人的代码全部覆盖了。 对策：除非你百分之百确定你在干什么，且这是你个人的独立分支，否则永远不要在主分支上使用强制推送。遇到冲突，乖乖 git pull 解决冲突。

入门核心命令速查表#

掌握了这些，你已经可以应付 80% 的个人日常开发了。但是在真实的团队协作中，我们不可避免地需要同时开发多个功能、修复线上紧急 Bug，这时候就需要引入 Git 的杀手锏——分支（Branch）。

在《Git 零基础入门篇（下）》中，我们将深入探讨分支的高阶玩法、冲突解决的底层逻辑，以及企业级的 Git Flow 协作流。敬请期待！