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

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

这时候，你就需要一个版本控制程序来帮你防止“硬盘毁灭”带来的血泪教训。

鬼？

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

• 多人协作困难同事改了 A 文件。你改了 B 文件，最终怎么合并？用 U 盘拷来拷去太原始了。
• 单机版本问题代码只存在自己电脑上。硬盘一坏，啥都没了，
• 不够工程化没有清晰的版本记录，改了什么全靠回忆。

而 Git 正是为了解决这些痛点而生。它是分布式版本控制程序——每个人电脑上都有一个完整的仓库，还能配合一个中央仓库实现代码同步。

主要概念：团队里每个人的机器都是节点，中央仓库只是大家约好的“同步点”。这就是“分布式”的含义——既不是单机，也不是完全依赖单台服务器。

再看第一步先，让普通文件夹变成 Git 仓库

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

打开终端（Windows 推荐使用 Git Bash)：

cd ysw_ai
git init

执行后目录下会多出一个隐藏的 .git/ 文件夹。千万别随意修改里面的内容,那是 Git 的主要数据库。从现在起，这个目录已经升级为拥有版本控制能力的仓库。

You can verify it with:

ls -al

第一次提交的观点是。把文件交给 Git 保管

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

# 查看当前状态：

git status

`git status` 会告诉你哪些文件是 untracked,也就是 Git 还没管着的。

# 把 readme.md 加入暂存区：

git add readme.md

`git add` 把文件放进暂存区. 暂存区像候车厅。你可以一次性 `add` 多个文件，等准备好再“一起发车”提交。

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

A: 分两步可以让你在一次提交中只包含完整、相关的改动。例如正在开发「登录功能」时你改了 `login.html`、`login.css`、`login.js` 三个文件。把它们一起 `add` 再一次 `commit`，记录就是「登录功能完成」；如果中途想撤回某个文件，只需在暂存区撤掉，不会污染历史记录。

# 提交并写说明：

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

`-m` 后面的文字是本次提交的说明，一定要认真写！以后 Leader 看记录、同事查 bug 都靠这段文字。

`git status` 运行后会显示工作区干净，没有待提交内容。

一个日常开发的标准流程

假设接下来要写首页功能。涉及 `index.html`、`common.css`、`common.js`：

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

`add` 与 `commit` 之间，你随时可以敲 git status 查看哪些文件已在暂存区。如果误加了无关文件，可用

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

文件状态的简单

• untracked：
• staged：# git add 放入暂存区，等待提交。按理说，
• committed：# git commit 安全保存在本地仓库中。说起来，

Your workflow should be:

1. 完成一个独立的小功能 → # git add
2. 立即写好清晰的提交说明 → # git commit -m "说明"

# git clone 就能把所有历史记录完整恢复。

最终说两句

• 多做 # git status 心里不慌。
• 提交说明要认真写，那是给未来自己和队友看的「求生教程」。