前言：为什么需要版本控制？
在没有版本控制的时代，开发者管理代码的方式往往是"项目文件夹备份v1"、"项目文件夹备份v2"、"项目文件夹最终版"、"项目文件夹最终版真的不改了"......这种方式带来的问题显而易见：
一是无法多人协作。 每个人的代码都在自己电脑上，合并时只能手动复制粘贴，稍有不慎就会覆盖他人的工作。于是诞生了中央仓库（如 GitHub、Gitee、GitLab）的概念------一个团队共享的远程代码托管平台，所有人都从同一个地方拉取和推送代码。
二是没有版本概念。 硬盘随时可能损坏，代码改崩了无法回退。Git 的核心理念正是"快照"------每一次提交（commit）都会生成一份完整的文件快照，你可以随时回到历史上的任意一个版本。
三是不够工程化。 改了什么、谁改的、什么时候改的、为什么改的------这些信息在裸文件夹中毫无记录。而 Git 将这一切纳入了规范的工程流程中。
Git 是分布式版本控制系统（DVCS），"分布式"意味着每个开发者的电脑上都有一份完整的仓库副本，不依赖中央服务器也能独立工作。这与传统的集中式版本控制（CVCS，如 SVN）有本质区别：集中式架构下，所有历史记录仅存在于唯一一台服务器上，服务器宕机则历史丢失；而分布式架构下，任意一个本地仓库都可以作为备份恢复全部数据。像 GitHub、Gitee、GitLab 这样的平台，扮演的是"团队协作枢纽"的角色，而非唯一的数据存储中心。
git init：初始化仓库
bash
git init这条命令将当前普通目录升级为具有版本控制能力的 Git 仓库 。执行后，目录下会多出一个 .git 隐藏文件夹（在 Git Bash 下用 ls -a 可以查看）。
.git 目录是 Git 仓库的心脏。 它存储了所有提交历史、暂存区信息、分支与标签、以及仓库级别的配置。需要特别强调的是：绝对不要手动修改 .git 目录中的任何内容。 Git 内部使用 SHA-1 哈希算法组织数据，手动干预极易导致仓库损坏。所有操作都必须通过 Git 命令来完成。
关于 Shell 环境：Windows 和 Linux/Mac 的 Shell 脚本语法不同。Windows 用户建议在项目目录下右键打开 Git Bash------它提供了一个最精简的 Linux Shell 环境，确保所有 Git 命令能正常运行。
文件状态：三个阶段的流转
Git 中的文件从创建到入库，经历三种核心状态：
Untracked（未跟踪）： 新创建的文件默认处于此状态。Git 能感知到它们的存在，但不会主动管理。执行 git status 时，未跟踪文件会以红色显示。
Staged（已暂存）： 执行 git add 后，文件进入暂存区。这个状态表示"下次提交时，把当前的文件内容保存为快照"。
Committed（已提交）： 执行 git commit 后，暂存区中的所有内容被永久保存到仓库中。此时文件状态变为"干净"。
之后每次修改文件，文件会重新进入 Modified 状态，等待下一轮 add 和 commit。
git add 与 git commit：为什么要分两步？
这是初学者最常见的疑问：把文件提交到仓库，为什么需要两条命令？
答案在于 Git 的**暂存区（Staging Area）**设计。暂存区是工作目录和仓库之间的缓冲区。
假设你正在开发首页功能，涉及三个文件：
bash
git add index.html # 第1次add
git add common.css # 第2次add
git add common.js # 第3次add
git commit -m "完成首页页面功能" # 一次性提交你可以多次 add，分批次将文件放入暂存区，这个过程不会产生版本记录 。直到 commit 的那一刻，暂存区中所有文件才被打包成一个快照写入仓库。
这种设计带来了几个关键好处：
第一，精细控制提交粒度。 一个 commit 对应一个完整的功能或任务，而不是零散的单个文件修改。Leader 在审查代码时，看到的是意图明确、边界清晰的功能提交，而非碎片化的文件变更。-m 后面的提交说明也因此尤为重要------它不能乱写，因为这是 Leader 和同事了解你工作内容的第一入口。
第二，提供"后悔"机制。 在 commit 之前，你可以随时用 git status 检查暂存区内容，发现不对可以用 git reset 把文件撤出暂存区。这给了你一个安全的中途休息和检查窗口------add 相当于"这件做完了先暂存一下"，commit 才是"最终确认入库"。
第三，保持工作流灵活。 你可能改着首页的 HTML，突然被叫去修一个紧急 bug------此时未暂存的修改可以先放一边，暂存区的完整性不受影响。
git status：你的状态指南针
bash
git status在任何关键时刻，先执行 git status。 这句话值得成为肌肉记忆。
git status 会告诉你：当前所在分支、工作区有哪些文件被修改但未暂存、暂存区有哪些文件等待提交、工作区是否干净。
使用时机：开始工作前确认状态干净，add 之后确认暂存区内容正确，commit 之前做最后检查。保持仓库干净是 Git 使用的基本素养------一个干净的仓库意味着所有修改要么已提交，要么已明确丢弃，不存在"不知道怎么处理就先放着"的中间状态。
远程仓库：连接团队
Git 是分布式的，但团队协作需要数据交换，远程仓库（remote）就是连接每个开发者的桥梁。
bash
git remote add origin <仓库URL>这条命令将本地仓库与远程仓库关联，origin 是远程仓库的默认别名。关联后，通过 git push 将本地提交推送到远程，通过 git pull 拉取他人的最新代码。
常用的远程仓库平台包括 GitHub（全球最大开源社区）、Gitee（国内访问快，中文友好）、GitLab（支持私有化部署的企业级 DevOps 平台）。
日常工作流
bash
git status # 1. 开工前确认状态
git add <文件名> # 2. 将改完的文件加入暂存
git status # 3. 确认暂存区
git commit -m "功能描述" # 4. 提交到本地仓库
git push origin main # 5. 推送到远程
git pull origin main # 6. 拉取同事最新代码核心原则：add 可以多次，commit 成一次任务；任何关键时刻先 status；保持仓库干净。
总结
| 概念 | 一句话解释 |
|---|---|
| .git | 仓库心脏，存储全部版本数据，不可手改 |
| init | 将普通目录升级为 Git 仓库 |
| add | 文件进入暂存区，等待提交 |
| commit | 暂存区内容永久保存为版本快照 |
| status | 查看当前仓库状态，最常用的命令 |
| 暂存区 | add 与 commit 之间的缓冲区 |
| 分布式 | 人人都有完整仓库副本，不依赖中央服务器 |
| 远程仓库 | 团队协作枢纽（GitHub / Gitee / GitLab） |
Git 的核心理念并不复杂：用快照记录变化，用暂存区组织提交，用远程仓库连接团队。 掌握这些基础，反复练习，让每个关键动作都带上 git status，Git 就会成为你最可靠的开发伙伴。