手把手教你用 Git 管理代码：从单机到分布式，再也不怕硬盘坏了

适合刚接触版本控制的新手，也欢迎老手复习

你可能遇到过这种情况：写了一个星期的功能，突然电脑蓝屏，重启后项目文件损坏了......或者想找回昨天写的某个段落，却发现 Ctrl+Z 已经不够用了。

这时候，你就需要一个版本控制系统。

其实这是我练习时建的一个项目目录。但在实际开发中，一个项目目录远不止"放代码"这么简单。它有几个明显的痛点：

而 Git 就是来解决这些问题的。它是分布式 版本控制系统------每个人电脑上都有一个完整的仓库，同时还可以有一个中央仓库（比如 GitHub、Gitee、GitLab）让大家同步代码。

简单理解：团队里每个人的机器都是节点，中央仓库只是大家约好的"同步点" 。这就是"分布式"的含义，不是单机，也不是完全依赖一台服务器。

假设你有一个项目目录叫 ysw_ai，里面已经写了 readme.md。现在想用 Git 来管理它。

打开终端（Windows 推荐用 Git Bash，因为它提供了最精简的 Linux 环境，命令和团队里其他人保持一致）。

bash

bash 复制代码

cd ysw_ai
git init

执行后，目录下会多出一个 .git 的隐藏文件夹。千万别乱动里面的东西，那是 Git 的核心数据库。你只需要知道，从现在开始，这个目录已经升级为带有版本控制能力的仓库了。

你可以用 ls -al 看看它是不是存在。

一般我们不会一次性把整个目录全交出去，而是按"功能"或"任务"来逐步提交。这时候就需要理解 Git 的暂存区（stage） 。

先用 git status 看看当前状态：

bash

lua 复制代码

git status

它会告诉你哪些文件是 untracked（未跟踪），也就是 Git 还没管着的。

假设我们想把 readme.md 交给 Git：

bash

csharp 复制代码

git add readme.md

这条命令把文件放进了暂存区 。暂存区就像一个临时的候车厅，你可以反复 add 多个文件，等所有准备工作都做好了，再一起"发车"提交。

为什么要分两步？直接 git commit 不行吗？

好处很明显：假如你正在开发一个"登录功能"，改了 login.html、login.css、login.js 三个文件，你可以在暂存区把它们都加起来，然后一次性提交一个完整的"登录功能完成"版本。如果中间突然想反悔改某个文件，还可以从暂存区撤回来，不会污染仓库历史。

继续提交：

bash

sql 复制代码

git commit -m "初始化项目，添加 readme 说明"

-m 后面是本次提交的说明，一定要认真写，以后你们 leader 看记录主要就看这个。比如 "修复了用户登录超时的 bug" 就比 "改了点东西" 强一万倍。

提交完成后，git status 又会告诉你：没有要提交的内容，工作区是干净的。

假设你接下来要写一个首页功能，涉及 index.html、common.css、common.js：

bash

sql 复制代码

git add index.html
git add common.css
git add common.js
git commit -m "完成首页页面功能"

在 add 之后、commit 之前，你可以随时 git status 查看哪些文件在暂存区。如果发现多加了某个文件，还可以用 git reset 把它移出来。

任何时候不确定状态，先敲 git status 准没错。 这是新手和老手的共同习惯。

你的目标是：完成一个独立的小功能 → add 相关文件 → commit 并写好说明 → 重复。

这样，即使你的硬盘突然坏掉，只要之前提交过，Git 仓库里就有一份"快照"。换个硬盘 git clone 回来，你所有的修改记录、版本都能找回。

上面讲的只是 Git 最基础的"单机用法"，但你已经比不用 Git 的人前进了一大步。后面还有分支管理、远程仓库、多人协作冲突解决等更有趣的内容。

记住两条：