前言
刚开始学开发的时候，我的项目目录长这样：
项目/
项目-v1/
项目-v2-最终版/
项目-v2-真的最终版/
项目-v3-打死不改版/
项目-v3-又改了/
我相信很多人都有类似的经历。直到接触了 Git，才发现之前的自己有多原始。
这篇文章从一个新手的视角，聊聊 Git 到底解决了什么问题，以及最核心的几条命令。
一、不用 Git 会怎样？
在聊 Git 是什么之前，先看看没有版本控制的日子到底哪里难受。
1. 无法多人协作
代码只存在自己电脑上，同事想看你的代码？U 盘拷过去。两个人都改了同一个文件？手动比对，一行一行合，合到怀疑人生。
Git 的解决思路是引入一个中央仓库（Remote），托管在 GitHub / Gitee / GitLab 上：
┌──────────┐
│ 中央仓库 │
└────┬─────┘
┌───────┼───────┐
┌──┴──┐ ┌──┴──┐ ┌──┴──┐
│ 张三 │ │ 李四 │ │ 你 │
└─────┘ └─────┘ └─────┘
团队成员各自在本地（Local）克隆仓库，写完代码推到中央仓库，其他人拉下来就能看到。这就是分布式协作——每个人本地都有一份完整的仓库副本，通过中央仓库来同步。
2. 文件损坏无法回溯
改了一段代码，两周后发现不对劲，但完全想不起来原来是怎么写的。更惨的是，硬盘坏了或者被误删，代码直接没了。
Git 的做法是：每次提交（commit）保存一个快照，形成一条版本链：
v1.0 ──→ v1.1 ──→ v1.2 ──→ v2.0
↑
随时可以回来
任何时候都可以回退到历史的任意版本。不是 Ctrl+Z 那种只能撤销几步的级别，而是跨越几个月甚至几年的回退。
3. 不够工程化
一个正经的工程项目，至少需要回答三个问题：
- 谁改的？
- 什么时候改的？
- 改了什么？
没有版本控制，这些问题全靠记忆和自觉。Git 把每一次提交都记录得清清楚楚：作者、时间、改动内容，附带提交说明。
二、Git 的核心工作流
Git 的命令很多，但日常 90% 的场景只用到下面几条。理解了它们之间的关系，Git 就不难。
1.git init — 初始化仓库
把普通项目目录升级为带版本控制的 Git 仓库：
git init
执行后目录下多了一个 .git 隐藏文件夹。它是 Git 的"数据库"，所有版本历史都存里面。
重要原则： .git 目录不能手动修改，一切操作通过 Git 命令完成。
2.工作区、暂存区、仓库
理解 Git，关键是理解这三个区域：
工作目录 暂存区 仓库
(Working (Stage/ (Repository)
Directory) Index)
git add git commit
文件 ────────→ 文件 ─────────→ 文件
例如： 改代码 挑西瓜 装袋
- 工作目录：你正在编辑的文件，随意修改。
- 暂存区：一个"购物车"，把要提交的修改放进去。
- 仓库：最终存档，一旦提交就永久记录在历史里。
3.git add — 添加到暂存区
git add 文件名
把修改放进暂存区。可以理解为：在菜市场挑了一个西瓜，放进购物车。这时候还没付钱，随时可以放回去。
4.git commit — 提交到仓库
git commit -m '提交说明'
把暂存区里的内容一次性打包存入仓库。相当于购物车结账——这次买了什么，发票上写得清清楚楚。
-m 后面的提交说明不能乱写，因为这是给团队看的。一个合格的提交说明应该能回答："这次提交做了什么？" 比如 首页页面功能、修复登录按钮样式。
为什么分两步？
这是 Git 设计里最精妙的地方。一个功能往往涉及多个文件：
git add index.html
git add common.css
git add common.js
git commit -m '首页页面功能'
多次 add，一次 commit。好处是：
- 原子性：相关修改打包在一起，回退时一起回退，不会落下哪个文件。
- 灵活性：改了 5 个文件但只提交其中 3 个（另外两个是实验性改动，暂时不想交）。
- 后悔药：add 之后、commit 之前，随时可以把暂存区的东西撤回来。
三、文件状态的三个面孔
Git 里的文件始终处于以下三种状态之一：
| 状态 | 含义 | 怎么来的 |
|---|---|---|
| untracked | 新文件，Git 还没管它 | 新建的文件 |
| staged | 在暂存区，等提交 | git add 后 |
| committed | 已入库 | git commit 后 |
任何时候想看当前状态，输入：
git status
这条命令有多常用？可以说任何关键时刻，先敲 git status 就对了。它会告诉你：哪些文件改了、哪些在暂存区、哪些还没被跟踪。
一个好习惯是保持仓库"干净"：每次 git status 都不应该有让人意外的文件悬在外面。
四、关联远程仓库
本地仓库搞定了，接下来推送到远程平台（GitHub / Gitee / GitLab），让团队成员都能访问：
git remote add origin <仓库地址>
git push -u origin master
origin 是远程仓库的别名（约定俗成的叫法），推送之后，本地代码就同步到了中央仓库。
五、一个完整的日常流程
总结一下，从零开始做一个项目的标配操作：
1. 初始化（只做一次）
git init
2. 写代码，然后随时 git status 看看状态
git status
3. 把改好的文件加入暂存区
git add .
4. 提交，写清楚做了什么
git commit -m '完成了注册页面的布局'
5. 关联远程仓库（只做一次）
git remote add origin https://gitee.com/你的用户名/仓库名.git
6. 推送
git push -u origin master
之后日常开发就是在第 2-4-6 步之间循环：写代码 → add → commit → push。
文章结尾：一个小白的git的初步学习
Git 的上手曲线确实有点陡，因为它在概念上比你想象的多了一层（暂存区）。但一旦理解了这个设计，就会发现它很合理。
用一句话可以总结 Git 的核心价值：让你的代码不仅有现在，还有过去；不仅属于你，还属于整个团队。
通过学习Git，不是为了让简历多一行技能，而是可以让我们从一个人的战斗，变成能和团队协同作战。
本文是一个 Git 新手的学习笔记整理，如有纰漏欢迎指正。
